In Part 1 we covered the basics of what Page Load Time refers to, and one potential way of tracking it.  In this post I’ll describe some potential solutions and some other considerations

How can I make my site perform better?

There are a huge number of potential problems that can impact page load speed, here is an in-exhaustive list along with some suggestions as to how they can be improved.

A llooonngggg TTFB

Every page on your site should be targeting 500ms for a TTFB.  Anything more than this and its unlikely the browser will have time to render anything before the user becomes frustrated with the experience.

Although the TTFB includes things such as network latency and SSL negotiation (your site is running over HTTPS, right?), the most likely culprit is that the web server is taking its time to render the HTML to return to the user.  Depending on the underlying application, there could be a multitude of reasons for this.

If you are using a CMS such as Sitecore, Drupal, WordPress, Umbraco etc, it’s less likely to be the actual CMS, but rather the custom code sitting on top of it.  Each of these tools have profiling tools that can help to identify individual components that are causing the slow down.  Once identified the code can be optimized by whatever means necessary (use an index rather than going to the database, improve the data architecture within the CMS to reduce lookups etc).

If your site is completely custom, using a tool such as Application insight (from Microsoft Azure) or New Relic’s APM tool can provide stunning insights into your application without additional instrumentation (you can extend what gets tracked with custom code).

Whichever implementation you have, after optimizing the code as far as you can (without getting into silly micro-optimization theater world) you should cache individual components or datasets where appropriate.  There is little point in spending precious CPU cycles re-generating the same HTML time after time (I’m looking at you, Header and Footer)

One of my tracking scripts is blocking the page loading

This is a tough one to solve, but what I’ve seen happen time and time again is that marketing teams request a tracking script to be added to a page (or a site), get the data they need then move on.  This is rarely a malicious act, but a side effect of not having good governance over tags being injected into pages.  This is becoming more prevalent with tools such as Google Tag Manager, or Tealium that act as injectors for tags onto a page.

Often these tracking tags require being near the top of the page to track data accurately, and so when they do not load they block the rest of the page.

I’d recommend two solutions to this problem;

1. Do an audit of active tags on your site and validate which ones are still required, and which ones can be removed.  Removing old tags has a positive impact on the performance of the page anyway, as it reduces the requests needed as well as minimizes the amount of JavaScript to be run
2. If possible, mark the tags with async or defer attributes to allow the browser to move passed the request and pull the asset down at a more appropriate time.  This is not always going to be possible, so it is best to check with the tag vendor.

Images are taking up the bulk of the request

There will be a tension between performance minded folks (hello!) and UI/UX/Designers who want the best quality imagery possible.  What can be an important first step is to run the page through Google’s Page Speed Insights tool, which will give hints on specific parts of the page to optimize, but most importantly will provide a download optimized images.  These can be used as a case to show how images can be reduced in file quality without degrading the impact of the image to the user.

Another option, if your CMS or custom application supports it, is to provide the imagery in a next gen format such as JPEG XR or WebP.  Contrary to the universal support of JPEG, PNG and GIF formats, different browsers support different next gen formats.  Although each of these new formats are competing against each other, each of them provide benefits over the old school formats, so if you’re able to serve your Chrome users a WebP image, they’ll spend less time waiting for the image to load and have a better experience!

I have a lot of repeated requests on subsequent page loads

By default, every asset referenced from the page, including the page itself, will be downloaded from the server every time.  This is generally an undesirable effect as the data for those assets is very often completely unchanged from one page load to the next.  What we can do to mitigate this problem is instruct the browser to cache the results of those requests so that they’re not made again, and the data is taken from the users browser, not over the network.

This does come with some potential issues – how do you instruct the browser to get a new copy of the file, for example?  When telling the browser to cache something, you also dictate how long to cache it for, and when that time has expired, the browser will request it from the server again.  If that isn’t sufficient, the ‘key’ to an entry in the browsers cache is the URL, including the query string.  If you need to force a new version to be downloaded right now, you can append or amend a query string parameter to effectively give the asset a new URL, which won’t exist in the browser’s cache, and it will be re-downloaded.

What else?

These are the common factors that will probably fix 90% of page load issues, however sometimes even that isn’t enough!

Edge Caching

If you have a high throughput site with some fairly static content (i.e. you’re not running A/B tests, or personalizing the content etc) you may want to look at some ‘edge caching’ tools such as Akamai, Cloudfare or Varnish (the latter being a roll-your-own product).  These tools can cache whole pages, or parts of a page, and offload processing from your web server, meaning CPU cycles are spent on the important parts of the page, and lowers the overall TTFB.

Content Delivery Networks

If your site is used over a wide geographic area, a Content Delivery Network (CDN) can work to serve your content from a server nearer your user (similar in many ways to an Edge Caching service).

This also works for serving common libraries, such as jQuery or Bootstrap, to your user from a super-localized server.  Given the shorter distances required for the data to travel, some assets on the page will be delivered faster, which will lead to faster load times.  If you user has previously used that specific version of the library from another website, there is a good chance it will be cached locally to their machine, meaning there is no network time included at all.

The time it takes to load a web page has been shown to have a dramatic impact on user experience, extending to conversion rates for sales as well as overall traffic engagement and retention.  So whether you have an e-commerce site or a marketing/brochure-ware site, delivering a fast experience to your user is hugely important.  Studies have shown that in the ‘information now’ age, attention spans are diminishing which is leading directly to the results of the studies above.  According to a study by SOASTA, users expect pages to load in similar times across all their devices; 1.8 seconds on a desktop compared to 2.7 seconds on a mobile device – the latter being something quite difficult to achieve!

What does “page load time” mean?

One of the problems with a metric such as “page load time” is that it can mean different things to different people.  For the average user it may mean “once the page has loaded and I can do something”, for a developer is may mean “once the first byte of data has reached the browser”.  If you’re approaching the problem of slow page load times – or even just optimizing what you have – it is important to level set on what the true metric is.  However, even taking the average user’s definition has some nuances – do they care if items are downloading in the background if the part of the page they want to interact with is usable?  For example, a streaming video banner may continue to download in the background after the initial state of the page has loaded, but doesn’t have a negative impact to the user.  If items outside the initial visible window are download after the visible portion is loaded, do they care?

Metrics to care about and how to track them

This is only my consideration at this moment, but I believe there are 3 important metrics to focus on (these are terms used by the webpagetest.org tool);

• Time to First Byte (TTFB) – This is the amount of time it takes for the request to leave the users browser, reach the web server and have HTML processed, and the first byte to be received back by the browser.
• Start Render – this is the time, including TTFB, that it takes the browser to start to apply visuals to the user’s browser
• First Interactive – this is the time it takes for the browser to process all required styles and scripts and for the user to interact with the page (I personally believe this is the “page load time” that the average user cares about)
• Page load – All assets have been downloaded from the server and the user can navigation around the page.

As alluded to above, one of the best tools around to monitor page load times is www.webpagetest.org.  On the testing side, it allows you to simulate the browser, location and in many cases the device used for the test.  This means you can check to see how your site fares on a desktop browser with a cable connection from Chrome, as well as a Galaxy S5 running Opera Mini on a slow 3G connection.  There are a slew of other settings that can be applied, such as custom headers, basic HTTP authentication, or even pointing to external domains to fake a failure to see how your site reacts.

On the results side, there is everything from the Executive Dashboard style A-F rating for 6 categories, down to the exact waterfall chart that was the result of the request.  

Using this data it is possible to identify which individual requests are slowing down your page – this could be an unoptimized image, too many assets being downloaded or even a third party site being unavailable and blocking your page.