For the average website, 80% of the potential speed improvement is in the front-end, only 20% in the back-end.
Web applications tend to rely more on back-end calls than websites and you can expect around 50-60% front-end speed potential for the average web application.
So the front-end area continues to be the single most important speed optimization area for websites and web applications.
With a limited effort it is perfectly possible to gain substantial speed improvements, that will reflect directly in increased conversions and business value.
In this article, we aim to give you enough insight into front-end optimization to enable you to make educated decisions about where to start and what to optimize:
In this article we will look at front-end optimization only, basically meaning optimization of everything except the HTML document.
The potential benefits, state of website speed and tools for testing website speed are covered in the Speed optimization primer. If you have not already read this article, we suggest you start there.
Let's start with the Usual Suspects, a handful of typical obstacles for good front-end performance found in most websites. It is a good place to search for the biggest bottlenecks:
Going through the Usual Suspects one by one for our example.dk website:
From Yslow we get following content breakdown of example.dk:
There are 67 First View requests in all. This is not an alarmingly high number of requests, but it certainly can be reduced. Things to look into here:
In total we would be able to reduce the number of requests to around 30, down from 67. The speed gain from reducing the number of requests is hard to measure up front, but it will probably reduce the Document Complete timing by 0.5-0.6 seconds.
To get a clear indication what we can expect of speed improvement by merging the JS files and load JS files deferred, see the following table:
The numbers are from webpagetest.org where JS files are blocked (removed from the download) in the test. With the removed JS files we get page load times in the 1.7 second region, quite a dramatic change from the baseline.
Add to that the speed improvement that can be found by merging the CSS files and reducing the CSS file size. Keep in mind though, that we need 1 CSS file, which by nature will be blocking.
If we can succeed in loading most of the JS files deferred or at least asyncronous, the savings in Document Loaded and Speed Index recorded in the table is not that far off.
All in all, we can expect an additional reduction in Document Complete of around 0.7-0.9 seconds by removing the blocking behavior of the CSS/JS files.
"The fastest request is the one not made" someone once said.
Most if not all of the static content on a regular website should have far future Cache-Control max-age or Expire settings (or both) in the HTTP headers. This will tell the browsers to cache the objects locally instead of repeatedly downloading the objects.
Correct cache settings will speed up things significantly for Repeat Views for visitors with primed browser cache. For various reasons we cannot count on all repeat page views to have a primed browser cache, but correct cache settings still benefits the majority.
To find the speed potential for correct cache settings for the example.dk site, have a look again at the baseline timings:
Check the Repeat View column. If all objects except the main HTML document was cached, we would reduce the Repeat View values to something close to 0.7 seconds.
As some static content cannot be cached (or we can't control the cache setting for 3rd party objects), like for example tracking pixels/beacons for web analytics software, we cannot count on all static objects to be cached - but most.
The waterfall diagram below shows Repeat View objects on example.dk. There are 8 static objects, some of them are in the critical path.
Setting proper max-age or Expire settings for those objects, will reduce the Repeat View Document Complete with around 0.8 seconds.
The number and file size of the images used on the average website is one of the more serious speed bottlenecks:
Images are used in 2 ways on an average website: as normal content images and as CSS background images.
To see how much speed potential there is in optimizing the images and the delivery of images on example.dk, we use again webpagetest.org.
Running a test where we first block the content images (and Flash files as they really should be converted to images), then running a test where we block the CSS images, gives us these timings:
Not surpricingly, the biggest speed impact is from the content images. There is little we can do to reduce the number of content images, but as it turns out, a lot can be done to reduce the file size of them.
In this case, we can cut the combined file size of the content images around 100 KB (around 25%) by picture optimization alone. Additionally we can use progressive JPGs, giving the visitors the perception that pictures are loaded faster.
For the content images, we can expect around 0.3-0.4 second faster Document Complete from the content image optimization.
The CSS images can also be optimized. Their file size is close to negligible, but we can cut a lot on the number of requests. As mentioned in "Too many HTTP requests" we can combine most of the CSS images into 1 or 2 CSS Sprites. This alone will reduce the Document Loaded timing by around 0.2-0.3 seconds.
All in all we are looking at 0.4-0.5 seconds reduced Document Loaded from image optimization.
Less file size transmitted over the Internet connection translates to faster page load speed. Some file types can be compressed on the web server and all modern browsers will then decompress the files after downloading them.
This compression/decompressions process takes time and computation resources, but the benefits in download speed from the reduced file sizes outweighs the compression/decompression process by far in most situations.
The example.dk web page contains 20 objects that should be compressed with GZIP. Mostly JS files, but also some CSS files and the HTML document itself. The total file size saving would be 300 KB with proper GZIP compression applied.
This reduction in file size from GZIP compression will give us around 0.2-0.3 seconds reduced Document Loaded speed. And it is easy to set up GZIP compressions on most webservers.
Summing-up the optimization results from each of The Usual Suspects:Adding the numbers up we get around 1.8-2.3 sec faster Document Complete timing for first view. We should err on the low side here, as there are overlaps in the optimization areas. For repeat views we get around 0.8 sec faster Document Complete timing.
Looking at the before/after timings:In total we get around 50% faster page load timings. More importantly we are getting close to the goal of 1 second page load speed, just from optimizing "The Usual Suspects".
Before finding the front-end bottlenecks it is a good idea to establish your current page load speed baseline. With that baseline it will be clear what potential for improvement you have and you will be able to follow and report your optimization progress.
What you will need is First View and Repeat View timings for:
We will use again our example.dk site, an anonymous Danish ministry website. The tool www.webpagetest.org give us these numbers from the measuring point in Stockholm, using a mainstream 5/1 Mbit Internet connection on the Chromer browser.
As we found earlier, back-end speed potential for the example.dk website is limited to around 200-250 ms, so the bulk of the speed potential is in the front-end.
The numbers are averaged over 5 runs:
We now have our baseline performance. Following is clear from the numbers:
Now on to find the biggest front-end bottlenecks.
The Usual Suspects, typical bottlenecks for front-end performance
Amongst the 100's of things affecting front-end performance, there exist a handful of typical bottlenecks. Let's call them The Usual Suspects:
Sorting these 5 areas will significantly speed up most web applications and websites. Maybe even enough to dip below the 1 second page load time mark.
In the "Example: Finding the front-end bottlenecks" later in this article we will dig a bit into the 5 areas. But first a method to figure out roughly how much speed improvement you can expect from your optimization efforts.
One of the Usual Suspects for front-end performance bottlenecks is images with too big file sizes. A couple of reasons to highlight this area in particular:
If you want to go one step further and automize the image optimization, Kraken.io and others offer an API so you can integrate the optimization process in your CMS.
It would help your speed optimization effort to know what result to expect, wouldn't it? Not much fun in using 40 work hours optimizing a particular area, just to find that the page load improvement was only 0.1 seconds. So how do we figure out where to focus our efforts for best results?
Experienced speed optimizers can look at a waterfall diagram of a webpage, spot bottlenecks and give a rough idea what the speed impact will be from removing the bottlenecks.
Comparing speed tests with and without these blocking patterns willl reveal the speed impact of optimizing the various areas. We can test the impact of for example images, CSS images, CSS files and Flash files or measure the speed impact of any single object.
This technique allows you to make an informed decision about where to focus your optimization efforts.
Perception is reality, some might argue. In the website speed area slow page load times does not have to be perceived slow by users. The reason is that web pages can be made to visually appear ready to use long before they are actually loaded completely.
There are different techniques to accomplish this:
The perceived speed versus Document Loaded speed means that you might not have to make the complete page finish loading in under 1 second to achieve good performance. It might be enough that the perceived page load time is below 1 second.
Webpagetest.org operates with a term called "Speed Index" which is when 80% of the visual area of the webpage is rendered in the browser. This metric is not perfect, but it is enough to give a good indication for when the page is perceived ready by users.
This means we can allow ourselves to adjust our speed optimization goal: Either we get the Document Loaded event below 1 second or we at least get the Speed Index below 1 second.
It would be nice if the CMS's and platforms out there would be able to produce fast loading pages out of the box. Or at least not put hard obstacles for speed in front of us.
The reality is that very few CMS and platforms is able to do that - or they will require big investments in platform optimization and CMS development to get there.
Luckily there are ways to get around these problems, so you don't have to replace your CMS or platform in order to achieve good performance. Two approaches:
Both methods introduce more complexity in the application delivery stack, but it might be a more feasible way than trying to get the CMS and platform to perform.
If you are in the market for a new CMS and platform anyway, you might want to add following requirements to your list:
The challenge from Mobile Devices
Users of mobile devices like smartphones and tablets are - compared to desktop computers - challenged with higher latency, less browser cache, week CPU, often poor bandwidth and the burden of traffic cost.
Mobile devices now make up for more than 50% of the devices used on the Internet, and that percentage is expected to increase over the coming years.
Add to that the fact that users of mobile devices are still expecting sub-second page load times. Research have shown that users of mobile devices actually tend to be more impatient than desktop users.
So not only will you have to get below 1 second page load times (or perceived page load times), you will have to get there on all devices, including mobile devices.
The problem has increased further with the Responsive Web Design (RWD) technology which has understandably been gaining traction fast in recent time. As a technique to seamlessly render web pages on any device with the same HTML, most RWD implementations unfortunatly results in very poor page load speeds, as pictures, scripts, CSS etc. in RWD are needlessly big for mobile devices.
To meet the goal of sub-second page load times on all devices, you will likely need to do more than just basic speed optimization.
Developers might also use a combination of RWD and device/feature detection to serve device dependant HTML and thus device dependant CSS, images and scripts.
You should never rely on speed measurements done from your high bandwidth and low latency connection, as the majority of your users are likely to use slower connections with higher latency.
You can use speed measurements from your own connection to follow your optimization progress and spot relative speed differences. Just be aware that your users speed experience is what counts, not yours.
Speed tools like webpagetest.org are good for exactly this purpose: Measuring speed as the bulk of your user base will experience it.
Use your web analytics reports to tell you the device, Internet connection and geolocation of the bulk of your users. Then use similar connection speed and geolocation in the speed test tool, and use that as your speed metric.
Related articles at Solido:
Relevant reading elsewhere: