google linked-in facebook office phone mail facebook_r twitter_r google_r instaram_r github_r linkedin_r downloads notifications star sign

Django Site Speedup (DSS): Why website speed matters

by Vitaliy Podoba
Vitaliy Podoba avatar

Over the last year at SoftFormance, our team has been busy working to optimize performance on a few Python/Django projects. We found that the more features we added to our clients’ websites the more conversion suffered—users were making fewer purchases and even clicking away to escape slow processing times. It became clear that page speed is not just a nice feature but an essential website requirement.

We want to share our experience with Django performance optimization with you. That’s why we’re starting a new series here on our blog: Django Site Speedup, or DSS. But before we get into the details of how you can optimize your Django site, it’s important to first establish why speed is so crucial to website performance. In today’s article we’ll discuss:

  • Why site speed matters
  • The anatomy of page speed
  • What we’re going to cover over the course of our DSS series, and
  • Who can benefit from our step-by-step guide to DSS

Why site speed matters

In 2010 Google released a short video that breaks down how site speed increases conversions. A response to Google’s introduction of site speed as a new signal in their search ranking algorithms, the video offers tips to speed up websites even on a low budget. 2010 thereby became the year that webmasters could no longer afford to ignore the importance of page speed.

Around the same time, Google also introduced Site Speed metrics as part of its Webmaster Tools (later this tool was moved to Google Analytics). There webmasters could check their website speed on a daily and even hourly basis and compare their site speed with the average across other websites online (although it seems that the “average site speed on the internet” metric is no longer available).

Clearly, webmasters now have the tools and the motivation to check the speed of their websites. So what are the consequences if website performance is poor?

First of all, Google says that slower websites won’t be crawled by their robot as often as faster sites. Any html response that takes two seconds or more would be ignored by the robot. So with a slow site, your pages won’t be up to date in the Google search index and some may be missing entirely.

The second consequence of poor site performance is a weaker ranking in Google’s search results. Google’s search algorithms use 200+ signals, one of which is page speed. While page speed is not as important as content quality, it still plays a role in overall website ranking.

But the most important thing about page speed is how it affects your website’s users, visitors, and customers. Google and Microsoft performed tests where they deliberately decreased page speed and the results were telling:

  • A 500-ms (half a second) delay decreases user satisfaction by almost 1%
  • A 2-second delay lowers user satisfaction by almost 4%

Page Speed Experiment

Even more revealing are the stats based on the feedback of 1,048 online shoppers surveyed by Forrester Consulting:

  • 47% of consumers expect a web page to load in two seconds or less
  • 40% of consumers will wait no more than three seconds for a web page to render before abandoning the site
  • 52% of online shoppers stated that quick page loading is important to their site loyalty
  • Shoppers often become distracted when made to wait for a page to load: 14% will begin shopping at another site and 23% will stop shopping or walk away from their computer
  • Retail and travel sites that underperform lead to lost sales
  • 79% of online shoppers who experience a dissatisfying visit are less likely to buy from that site again and 64% would simply purchase from another online store

And KissMetrics has created a really interesting infographic to help us understand how page speed and user satisfaction intersect:

KissMetrics: Loading Time

Clearly, when it comes to site performance, every second counts. A one-second delay (or three seconds of waiting) decreases customer satisfaction by 16% and can result in a 7% reduction in conversion. Another really useful observation is that most visitors would wait no more than six to ten seconds before they abandon pages.

Finally, site speed is important because it can have a real, long-term effect on how much traffic you can draw to your site. Google and Microsoft showed that after  conducting their site slowdown experiments for seven weeks in 2010, their online visitors not only showed a decrease in user satisfaction in the short term, but proved less likely to return to their  sites in the long term. A full 11 weeks following the experiments, the volume of visitors had not recovered.

So be pro-active: it’s better to prevent new features from slowing your website down than trying to fix a problem and suffer long-lasting consequences.


I hope you now agree that keeping your website fast is a good investment of your time and money to:

  • Grow conversions
  • Increase page views
  • Maximize user time spent on your site
  • Lower bounce rates, and
  • Reduce operating costs by decreasing server and traffic load

Now we’re ready to answer the next question: what page speed should we aim for?

Defining optimal page speed

The easiest and most obvious answer would be the faster the better. But let’s be realistic. Making websites fast is usually a time-consuming and costly process, so we need to maintain balance between speed and costs and find what works best for the specific situations of each site.

Different visitors require different page speeds. E-commerce websites should usually be a bit faster than blogs as e-shoppers do not like to wait for even one to two seconds. IT geeks do not like to wait at all, while lawyers, being representatives of a bit more conservative profession, are willing to wait a bit longer.

Some websites may also not be as simple as a personal blog, and thus would never be as fast as a Google search page with a single search form.

In all these situations the easiest solution to know what page speed you need to achieve is to check your competitors’ websites, paste their URLs into and find out how well they perform. Make sure your website is on par with the fastest sites among your competition.

But still, we’d like to go one step further and generalize on average page speed recommendations.

In the next section we’ll talk about the anatomy of page speed in order to understand what makes pages fast or slow. But for the moment we’ll talk about page speed in terms of the seconds it take before a user can start using page, even when it is not 100% loaded. So, with this in mind, let’s go on to generalize page speed averages.

At Google, developers usually try to keep their website speed as fast as 0.5 seconds after which a visitor can use a page. For e-commerce, Google recommends maintaining load times within 2 seconds.

Different page optimization and page monitoring services (e.g. mark pages with speed under 4 seconds inclusively with the color green, which indicates that page speed is good. Everything between 4 and 16 seconds is marked by the color yellow, which means the site speed status is tolerable. All pages that take more than 16 seconds are coded Red and are marked as a frustration for your visitors.

Now, trending website performance articles state that desktop users expect a site to load within a second or two in 2016. Mobile users are a little more patient, for now.

Most experts on the internet agree that on average if your website loads within 4 seconds, it’s fine. And mobile users would like to have your mobile version work as fast as your desktop site. So, usually, you need to make mobile versions much more simple to aim for the same speed.

In any case, even if you can not get to 1-2-3-4 seconds page speed on you website, you still need to make it at least 1 second faster. Every second in speedup improves your conversion by 7%!

So let’s review:

  • Are you within 2 seconds load time? Great! You’re almost as fast as Google public resources! In this case drop me an email and share your secrets 😉
  • Are you within 4 seconds load time? No worries, you’re still doing great! Though there is still room for improvement, and now you know that every second of improvement can give you a 7% increase in conversion!
  • Does your site take longer than 4-6 seconds to load? You definitely need to take care of your page performance! You’re missing out on a lot of opportunities and a good part of your visitors are not happy with your service
  • Do you provide a mobile version? No? You should! Yes? – Make sure it’s of the same speed as the desktop version
  • Want to be more precise in page speed for your specific niche visitors? Check your competition’s websites and make sure you’re the fastest among them

Now you’ve got your target for your website page speed. If you’re within 2 seconds, you can safely ignore this article series. Otherwise, let’s move on and find out what page speed is and how it is calculated. We need to know this before we can dive in and tweak it.

You can check your website speed at or within your Google Analytics account.

The anatomy of  page speed

For us to understand how to optimize page speed we need to understand two things:

  1. What is a web page and what components does it include?
  2. What is an HTTP request and what steps does it consists of?

Web page components

Web pages rely on a text-based code called HTML (Hyper-Text Markup Language) that contains specific instructions for browsers on how to format, position, and display that text on a page. This HTML code includes other types of resources: images, Javascript, and CSS code inclusions.

Javascript is a programming language that runs on the browser side and makes web pages dynamic. CSS (Cascading Style Sheets) language allows web designers to make web pages look and feel according to the tenets of website design.

All of these web page components–HTML, images, javascript, and CSS–can and should be optimized to be smaller, consume less traffic and load faster. Some of these components can even freeze a page if not optimized.

Modern web pages consist of multiple images, Javascript, and CSS inclusions. Quite often these resources can fetch even more resources on a page.

Page Components Breakdown

Screenshots taken with from our website at the time of writing this article. Click to enlarge. Page components breakdown by size and number of files.

Every component type is involved in page rendering procedures at a specific time. Under some circumstances components must be loaded in sequence: some cannot be loaded before others. This process can be adjusted by developers, but we’ll return to this later.

From the pie charts above you can see that images, Javascript, and CSS code takes most of the traffic and requests. Later we’ll discuss how to make pages faster by working on these three types of resources, but for now, let’s check how we do on this web page.

HTTP request/response flow

Between 10 and 20 steps are involved after a user clicks a link or enters a URL in a browser address bar before they can see the page they requested completely and ready for use.

HTTP Request-Response Flow

HTTP Request-Response Flow

The transfer between a user’s browser and the server side is done over HTTP protocol. The steps between making a request and accessing a ready-to-use web page are:

  1. HTTP request initiation: the process is initiated by a user clicking a link on a web page or entering a URL in browser address bar
  2. DNS resolution: the browser tries to find the server IP from the website’s domain name
  3. TCP connection start: the browser establishes a TCP connection that will be used to transfer data in both direction
  4. Send request: the browser sends data (e.g. data from posted form) to the server
  5. Wait for response: the server accepts, processes the request and prepares a response; the time the server takes to return a response and starts sending data is what we call “First Bite time”; this is a really important metric to identify whether or not our server is fast enough
  6. Download response: data is transferred from the server to the browser
  7. Parse response: the browser parses received data converting HTML code into DOM (Document Object Model) and starts rendering the page
  8. Request sub-resources: upon finding any HTML/CSS/Image resources, the browser executes the next request to fetch it; these requests are called sub-resources requests
  9. Execute Javascript and apply CSS:  the browser then executes any found and fetched Javascript code while also fetching CSS styles and applying it to page elements, so everything goes into the proper place and looks nice
  10. Compose layout and final render: after HTML, Javascript, CSS, fonts and images are on a page, the browser finalizes the page composition

There are a lot of sub-steps involved in each of the above steps. But for now we’ll detail only one of them: Wait for response. This time is taken for the server to accept and process a request, and then prepare and start sending a response to browser:

  • The front-end server accepts the request from the browser
  • the front-end server forwards it to cache-proxy or request balancer (if any is configured)
  • the request then goes to the actual application code (in our case, to the Django web framework)
  • Django generates and returns an HTML response with Headers to the front-end server

Even within the Django framework, tons of things are happening. But more on this in the next article of our DSS series.

Most of the above steps can be reviewed separately when attempting to review speed, and we can optimize almost every aspect. So what are the most important steps we focus on as low-hanging fruit in the optimization process?

What to optimize

We can check and optimize almost every step in the process explained above, but there are three main parts to focus on:

  • The front-end side: making HTML, CSS, Javascript, CSS, and image resources smaller and of less quantity, etc
  • The server side: making the web application code and database fast, applying cache and web accelerators
  • Network: making the DNS lookup and data transfer between browser and server faster

We’ll discuss each of these  points in detail in the upcoming articles of our DSS series.

If you’re interested, here’s an extensive list of terms relevant to our discussion of page speed. At this point, however, you only need to remember two:

  • First Byte Time: if it’s too big then your server logic/network will be too slow, you need to focus on it
  • Load Time: usually we’ll take this metric as the main component by which to judge page speed

Now we’re completely ready for the next article in our DSS series and have only two things left to finalize in this article:

  • Is these series for you?, and
  • What topics will we consider in our DSS articles?

Next up in the DSS series

After reading today’s article you know why website performance matter and what components page speed consists of. Next in the series, we’ll release an article a week that will consider:

  • How to find the weakest points in page speed components
  • What a website accelerator and caching proxy tools are and how to use them
  • Database optimization
  • Python language and Django web framework performance bottlenecks
  • Website front-end optimization and available speedup services
  • How network, DNS, CND and other terms influence Page Speed
  • Mobile and tablet websites hacks, and
  • How to make clean, simple websites and know when to cut down your features

This series will equip you with the tools you need to make your website fast and effective or to find the right consultant or company to do it for you. Subscribe to our DSS series updates at the bottom of this article to avoid missing out.

Who benefits from this series

Website owners

If you own an active website you need to know how fast is it and whether you need to improve it. Not all web designers know just how important page speed is and so won’t be able to initiate a discussion on the subject.

If that’s the case, you need to learn some high-level stuff regarding page speed in order to know when to optimize your site performance, how to hire a proper professional for the job and how to evaluate the quality of the results.


An integrator is a professional that puts websites together using existing CMS (Content Management System), plugins, themes and add-ons, usually without deep skills in programming or web-design.

Similarly to website owners, integrators needs to know when a website is slow and suggest that his/her clients reflect on this.

In these series integrator will find a lot of useful techniques on website speedup that could be applied without deep programming or web-design skills. In other words, quick wins with little effort.

Web designers

We’ll have a dedicated article for web designers on front-end site optimization where we’ll consider must-have techniques for HTML, CSS, and Javascript code. We’ll also review front-end performance optimization services (like MaxCDN, CloudFlare, etc.) available on the market and explain how they work and what they do.

You’ll be able to speed up your clients’ websites with this knowledge by 50-80%. No need to be a Linux Administrator, Database Manager or Server Side programmer.

Python/Django developers

Expect a lot of usefulness in this series if you specialize in Python and/or Django. At SoftFormance our main specialization is web development with Python and Django. We’re eager to share our performance optimization secrets gathered over 6 years of developing high-load Django websites, and we’ll dedicate two articles to this topic.

We’ll  also talk about databases, front-end servers, and caching proxy performance and will be tied to Django architecture where required.


Finally, we’ll consider database optimization and network/DNS tune-up and front-end server and caching proxies speed-up techniques. So if you’re an administrator working with any of these tools, you’ll find our next DSS articles extremely useful!

Your programming buddies will respect you if you can help them make their website faster without them needing to tweak potentially slow custom code.


Now we’re ready to move on to the next article in our DSS series. Subscribe below and you won’t miss a single one. Happy tuning!

Do you have anything to add on page speed anatomy or why it matters? Please, comment below!


  1. ryndin

    very useful information

  2. pythoner

    very helpful, thank you!

    • Vitaliy Podoba

      glad it helps! 🙂


Submit a Comment

Your email address will not be published. Required fields are marked *