top image

Front-end Optimization

Front-end optimization of websites and web applications

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.

Easy to get substantial speed improvements 

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:

  • Finding the biggest bottlenecks
  • The usual suspects, typical high impact areas
  • Depth of the rabbit hole, advanced front-end optimization
  • Perceived speed versus page load speed
  • What to do if the CMS or platform won't play nice

Browser Window With Stopwatch

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.

Example: Finding the front-end bottlenecks

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:

  • Too many HTTP requests 
  • Blocking CSS and JavaScripts
  • Missing or wrong Expire settings
  • Excessive pictures, both in file size and in picture count
  • Missing GZIP compression

Going through the Usual Suspects one by one for our example.dk website:

Too many HTTP requests

From Yslow we get following content breakdown of example.dk:

Front End Optimization Too Many Http Requests

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:

  • CSS images
    10 CSS images could probably be reduced to 1 or 2 by using CSS Sprites (link)
     
  • Images
    1 of the 15 images could be converted to CSS background image (the logo). Another is a duplicate with a different name, which should be fixed.

  • JavaScript files
    The 28 JS files could probably be reduced to 6-8 by merging or by getting rid of those that might not really be needed. In the process it is worth considering serving some of the 3rd party JS files from example.dk - or a sub-domain of example.dk - instead.

  • Flash files
    5 Flash files are used to facilitate a slider on the example.dk website. 3 of the Flash files are used for pictures. Converting the Flash slider to HTML/CSS would save 2 requests and reduce the close to 1 MB total Flash files size to around 120 KB in the process.

  • CSS files
    5 CSS files are used in total. These should be merged to 1 CSS file only. 

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.

Blocking CSS and JavaScripts

CSS files is most often in the Critical Path (link), blocking rendering of the page until they are downloaded. JavaScript files can also block rendering of the page, and they typically do.

In the diagram below you will see the CSS file and JavaScript files only. Notice how only 6 of the 32 objects are loaded after the Document Complete event (the blue vertical line). The rest of the objects are blocking Document Complete, impacting page load speed in a bad way.

Waterfall Diagram Front End Optimization Css And Js Files Only

Merging the CSS files will help a bit, so will reducing the CSS file size. But the biggest impact here is to make the JavaScript files load asyncronous. Or even better, have them load deferred, meaning after Document Loaded.

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:

Table Front End Optimization Removing Js Files

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.

Missing or wrong cache settings

"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:

Table Front End Optimization Baseline Speed

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.

Waterfall Diagram Front End Optimization Repeat View

Setting proper max-age or Expire settings for those objects, will reduce the Repeat View Document Complete with around 0.8 seconds.

Excessive pictures, both in file size and in picture count

The number and file size of the images used on the average website is one of the more serious speed bottlenecks:

  • 75% have more than 20 images on a web page
  • 50% have more than 40 images on a web page
  • 60% transfer more than 400 KB of images from a web page
  • 40% transfer more than 800 KB of images from a web page

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:

Table Front End Optimization Removing Content Images

Table Front End Optimization Removing Css Images

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.

Missing GZIP compression of compressable content

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.

File types like JavaScript, CSS, some font types and the HTML document all benefit from GZIP compression. Even ICO files (favicon files) will benefit from GZIP compression. Some file types benefit more than others. Typical file size savings is in the region of 40-60% for text based files, some up to as much as 80-90%.

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.

Total results from the basic optimization

Summing-up the optimization results from each of The Usual Suspects:Table Speed Improvements TimingsAdding 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:Table Front End Optimization Total Speed ImprovementIn 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".

Establish your baseline for speed

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:

  • Document Loaded
    Document Loaded is when the browser have loaded the DOM and completed rendering the page. It means that the page is ready to use.

  • Document Complete
    Document Complete is when all objects on the page have loaded, included those objects that are not needed for rendering the page. Like for example asynchronous or deferred loaded JavaScripts.

  • Speed Index
    A term defined by webpagetest.org. Speed Index is the time it takes for the page to appear ready for use. Technically it is when 80% of the visual page area is rendered in the browser. 

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:

Table Front End Optimization Baseline Speed

We now have our baseline performance. Following is clear from the numbers:

  • Document Loaded and Speed Index is too high for good usability, both for First View and for Repeat view. Should be less than 2 seconds, preferably less than 1 second.
  • Repeat View is noticably faster than First View, indicating that caching is at work to some extend

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:

  • Too many HTTP requests
  • Blocking CSS and JavaScripts
  • Missing or wrong Expire settings
  • Excessive pictures- file size and picture count
  • Missing GZIP compression

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.

A word about image optimization

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:

  • Images account for around 50% file size of the average web page
  • Images are easy to optimize with significant results
  • Images can be optimized with little or no loss in quality

Services like Kraken.io or Smush.it offers easy image optimization with little or no loss in quality. The average file size savings is around 30-50%.

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. 

Technique for finding the biggest bottlenecks

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.

The rest of us mortals can use a technique made available with the speed measuring tool webpagetest.org. The tool allows us to block patterns of objects or single objects from being loaded in the speed test. Notice the tab "Blocking" in the screenshot below, where we have blocked all JavaScript files from loading:

Webpagetest Configuration Setup

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. 

Perceived page load speed versus Document Loaded 

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:

  • JavaScripts can be loaded deferred (after Document Loaded event)
  • HTML/CSS above the fold can be made to render first
  • Pictures below the fold can be loaded on request when the user scrolls down

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.

What to do if the CMS, application or platform won’t play nice?

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:

  • Introduce cache servers like Varnish Cache or Nginx + facilities in the CMS to merge CSS/JS files and control the loading order of JS files
  • Use a 3rd party service to dynamically rewrite your webpages, like the Google Page Speed Service

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:

  • Ability to store different image versions with different dimensions
  • Ability to merge CSS and JS files
  • Ability to control the loading order of JS
  • Ability to pre-render webpages to avoid time consuming DB lookups and computations

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.

Cunning developers can use techniques for serving different image versions depending on device. Features like this is on the way in HTML5 (the scrset feature), but still not supported widely by browsers. Until we get there, some clever JavaScript can be adopted.

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.

Common mistake: Measuring page speed from high bandwidth and low latency connections

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. 

Further reading

Related articles at Solido:

Relevant reading elsewhere: