Benefits, finding bottlenecks and tools for speed optimization
Optimizing websites and web applications for high speed and fast page load times has never been more important than now.
There is a huge and increasing gap between what users need in terms of speed and what the average websites and web applications are giving them. That gap represents big business opportunities and big potential savings in hosting equipment.
In this article you will get an overview of:
In the article front-end optimization you will get more specifics for harvesting your speed potential.
Like it is common practice in the speed optimizing community, we will use following definition:
Back-end is First Byte, the time it takes from the user started navigating to the page, until the first data from the server arrives at the user. Front-end is everything else.
In this definition, back-end includes DNS lookup and initial connection time, even if those have nothing to do with back-end servers.
In other words, back-end time is close to the time it takes for the browser to receive the main HTML document, except the actual content download of the main HTML document is considered to be front-end.
The waterfall diagram below is generated from www.webpagetest.org. It shows a subset of the requests on the home page of LinkedIn.
Around 780 ms is in the back-end and includes DNS lookup, initial connection and SSL negotiation, as LinkedIn runs on HTTPS. The rest of the 3.5 second page load time, only partly visible here, is in the front-end.
The back-end/front-end time distribution for linkedin.com is close to the typical 20/80%, which is the reason it is often in the front-end that most improvements can be harvested:
Finding the areas with the biggest bottlenecks
To figure out where to begin and what areas holds back the speed of your web application, we recommend that you record following 3 metrics on first-view from webpagetest.org using your typical users Internet connection speed and distance from the web servers:
Now have a look at those 3 values to see what is worth optimizing first:
As an example we will use a large Danish ministry website which will remain anonymous, let's call it example.dk. This website is neither better nor worse than most big websites out there. It just serves as an example of what can be done in terms of speed optimization.
For example.dk, the speed test tool webpagetest.org give us these numbers from the measuring point in Stockholm, using a mainstream 5/1 Mbit Internet connection on the Chrome browser and taking the average of 5 runs:
Page Load Time: 3.27 seconds
First Byte: 0.44 seconds
TTFB (Time To First Byte): 0.39 seconds
From these example numbers it is clear what to focus on:
A Page Load Time of above 3 seconds is far too high. There is plenty of room for improvements here, as the goal is 1.0 second page load time.
DNS/connectivity seems ok, as the difference between First Byte and TTFB is low.
Clearly the most gains in this example are to be had in the front-end, but the back-end could also do with some optimization, where we are looking at a 200-250 ms speed improvement potential.
There are many tools for speed testing. We recommend following tools for testing page load speed:
Be aware how you use the tools and how you test speed. To get speed testing results in usable absolute numbers, comparable to what your users experience, use webpagetest.org. To find and analyze speed issues and to record relative progress, use Firebug, Yslow and PageSpeed.
Speed optimization is not hard, but it does of course require some basic knowledge. A technical- or development minded person will be able to understand and use for example the basic front-end optimization principles in less than an hour. The many finer details that make up the last 20% potential will take a while longer to master, but it is still far from rocket-science.
The most important obstacle in making faster websites is not that it is hard to understand the optimization principles or hard to implement them, but the fact that speed is not even a topic for most companies, their developers or their managers.
In stark contrast we have the millions of daily visitors for whom the speed of the websites they are visiting – or the low speed rather – is very much a topic, and a reason for frustration and abandonment.
So why is speed optimization not popular among companies? There are probably many reasons. To list a few of them:
Consider approaching speed optimization as a way of doing things, a mindset, not a project in itself. Just like writing semantically correct and validating HTML code, just like writing structured object-oriented CSS code and just like applying good usability practices in UX.
Following good speed optimization practices will for example mean that some solutions and functionality in your web application should be re-written, implemented in a different way or that other solutions need to be found. Just like in many other areas of application development.
Consider also to adopt speed optimization in QA to make sure your speed efforts remain on track.
Many different tests have shown that slow responding websites is a reason for users abandoning websites.
A research conducted by Forrester Consulting and published by Akamai in 2009 highligted following for visitors to Ecommerce sites:
Now take a look at the page load times of the Top 100 Ecommerce websites in the world plotted in the diagram below. 96% of them are slower than 1.0 second, 60% are slower than 2.0 seconds, and 17% are slower than 3.0 seconds .
So if you have an Ecommerce site with a page load speed slower than 2.0 seconds, you disappoint 47% of your visitors. If your page load speed is slower than 3.0 seconds, 40% of your visitors will leave your site.
This also means that Ecommerce sites with 3.0+ seconds page load times have an additional sales potential of 40%, just by reducing page load speed.
Similar patterns exist for blogs, but with even more improvement potential. Below is page load times for the Top 100 Blogs in the world. All are slower than 1.0 second, 97% are slower than 2.0 seconds, and 79% are slower than 3.0 seconds.
It follows that 79% of the blogs out there, maybe (likely even) yours also, have a conversion improvement potential of 40%. Not bad getting 40% more subscribers, followers or whatever your main blog conversion is, just by reducing page load speed, is it?
On top of the business potential from fulfilling user needs, speed optimized websites and web application have the added benefit of:
For the human interaction with systems like websites and web applications, usability expert Jacob Nielsen highlighted in 1993 a set of time limits when optimizing for speed.
These time limits has since been recognized throughout the usability community to be universally applicable:
Others have been suggesting 2.0, 3.0 and 4.0 second limits and shown how many users will leave the application around those limits. The fact remains that above 1.0 seconds, some users' focus will start to drift away, some will reach the limit of their patience, and some will leave.
It is perfectly possible to optimize web pages to load in less than 1.0 second. Some highly optimized websites even have page load times below 0.1 second. Most websites and web applications however have page load times in the 1.0 – 10 second range, yours probably also. So there is plenty of room for improvement.
The question is how much business value you will get from improving speed of your website or web application. And the next, what speed goals would be sensible to aim for.
Following are business results from speed improvements reported by some of the bigger brands out there:
If you need more solid facts than these, there are methods to find out what a speed improvement of your website or web application will give you in terms of business value:
Armed with facts about the business benefits of speed, you can now hold them against the needed investments for making your web application faster.
The recommended end-goal is fascinating clear: Get below 1.0 second page load speed for the bulk of your user base.
You might want to set intermediate goals like 2.0 seconds page load time, if you are challenged by restrictive systems and platforms.