Research by Akamai and Forrester suggests that page load speed has a dramatic impact on on your user experience, as almost:

• 50% of users expect a website to load within two seconds
• 50% of users will abandon a site that doesn’t load within three seconds
• 44% of users will tell their friends about a poor online shopping experience

Kissmetrics reports that effect is even more pronounced on mobile devices, with 73% of users saying they have experienced websites that were too slow to load. The same research also found that a massive 79% of users who were dissatisfied with a website’s performance were unlikely to visit again.

Faster site, fuller basket

Loading time also has a profound effect on your customer conversions.

Both Walmart and Amazon found that they increased their revenue by 1% for every 100 milliseconds decrease in loading time. That’s 10% more spend per second improvement. In fact, Amazon estimated that a slowdown of just one second could amount to as much as $1.6 billion in lost sales per year.

What’s an extra second worth?

• $1.6 billion in lost sales per year (Amazon)
• 2 million lost searches (Google)

Even if you’re not looking for a direct sale, speed counts. Google found that slowing its results by 0.4 seconds would lose them 800,000 searches a day. Similarly, Yahoo found that a 0.4 second speed increase increased its traffic by 9%.

Ultimately, page speed is something no business can afford to ignore. Google’s latest search algorithm rewards faster sites and punishes those that lag behind, meaning only the fastest sites can ascend to the top of their results listings and enjoy the increased traffic and conversions that page-one visibility brings. After all, according to moz.com over 70% of all click-throughs happen on the first page of any search, and there’s even evidence that it improves your customers’ brand recall, quality perceptions and purchase confidence. Speeding up your site has become an essential way to strengthen your brand’s reputation and attract more business.

Online, it seems, time really is money. So what can you do about it?

Find out if your website is fast enough

In recent years there has been an increased focus on the speed and efficiency of the web. This has been driven by increasing average page weights, thanks to more sophisticated interaction, styling and imagery, combined with the growing reliance on mobile access. A relatively easy (and free) way to see how your site performs is the ‘Google PageSpeed Insights’ online tool.

In the past a website’s page speed was primarily managed and assessed simply by it’s server speed, but not anymore. Modern websites rely more heavily on the user’s browser rather than the server to process customer-facing and interactive elements means that optimisation needs to be done across the board to help them load quickly and efficiently.

The Google PageSpeed tool enables you to easily assess a wide range of potential problem areas - on both mobile devices and desktops - including server response time, caching implementation, minification and usability. The tool offers an easy grading system divided into three sections, with scores out of a hundred and a simple Red, Amber, Green traffic lights system to tell you what passed, what failed and what could be improved.

At Stickyeyes speed optimisation is an integral part of our development process. There are lots of useful plugins you can use to help streamline your own website development and speed up your load times (for some of our favourites see our recent blog post), but even these are no guarantee of green lights and 100% scores. Often this can come down to the type of website you have. Is it a static page or a CMS? Is it all custom built or using third-party plugins? Are you using a low or high-end hosting package? All of these factors can have an impact on the rating of a site that hasn’t been optimised for purpose.

PageSpeed tool results

To get the most out of this whitepaper run your site through the online Google PageSpeed tool and come back – what follows is a step by step walkthrough of the results – but if that’s too scary give Stickyeyes a call we’re lovely

Once you have run your page through the Insights tool you will be presented with your results. This can be quite alarming at first, as you will likely see a lot more red and orange warning signs than green passes, but don’t panic - the tool also provides explanations and suggests solutions.

In an ideal world you would implement all the findings to optimise as much as possible, but to get the best value you should tackle them in order of priority

Highest impact issues

What is image optimization?

Image files can be enormous and take a long time to load which, in turn, makes your website take a long time to load. Luckily, there are lots of ways to reduce even big images to a much smaller file size – often without losing any image quality at all.

With the current trend for large-scale, high-resolution imagery and retina screens, photography is making a bigger impact on page weight than ever before. Knowing this you should be asking yourself, is that image necessary? The first step in image optimisation should be assessing its necessity. This doesn’t mean that you should remove all imagery across your site as it is a key element of an effective website. What you should do however is balance the impact of each image upon the context of the page.

A great example of balancing impact of imagery is Amazon’s retail experience. When you visit the Amazon homepage you can’t help but notice that it is quite image heavy in comparison to its text content. Despite their negative impact on page weight, imagery is the most effective way to show the products on offer. A detailed text description just wouldn’t grab your attention like this.

Once imagery has been used to guide your journey through the retail process and you are into the checkout phase this is completely changed and nearly all imagery is removed from the page. This results in a huge reduction in page weight and requests, in the case of these examples the homepage had 259 image requests totalling 6.3MB all the way down to 21 requests totalling 58KB. This reduction in page weight is so important at this stage of the retail process as to increase page speed and reduce the chance of people dropping out before clicking that all important buy now button.

When imagery is used to reduce its page weight as much as possible you need to ensure the imagery that you are serving is fully optimised. This can be done in a few ways:

• Compress your images Even correctly-sized images can be reduced in file size without compromising on quality.
• File Formats There are a variety of file formats and each have their own pros and cons one of which is page weight. Do you have large non-transparent imagery as PNGs instead of JPGs? Or large vector icons as JPGs instead of SVG? Double check what you are using and if there are any better options.
• Size images correctly If you serve an image at 4x the size it appears, you are adding unnecessary weight. Save images at the maximum size they are to be displayed to reduce their impact.
• Responsive Imagery Modern techniques such as PICTURE and SRCSET responsive imagery is really starting to come into its own as a way of delivering the optimal version of an image based on that user’s device taking into account screen sizes and resolution. Although older browsers don’t support it this is something you should look into for real optimisation where possible.

What is CSS and JS minification?

Unlike a human, your browser doesn’t need lots of neat spaces between instructions to be able to read them. Since your browser is clever enough to skip the spaces when it reads the code for your website, you can do away with those spaces – along with the time needed for your browser to skip over them.

Another major offender for webpage weight is the code behind its styling and interactivity in the form of CSS and JavaScript. Despite improvements to approaches in both of these languages to make it easier to reduce their size by coding in modular, reusable ways (as well as the gradual fading out of older browser support), code can still be quite large. One way to help reduce this is through minification. There are many different tools out there to do this, but they all enable you to reduce your file size by removing whitespace. Some tools, such as CSS Nano and UglifyJS, go even further by removing duplications and comments, as well as shortening variable names where possible. In simple terms, the smaller the file is that your browser has to load the quicker it can achieve this and move on to the rest of the page.

What is concatenation?

Every time your browser needs a particular CSS file or JS file to complete loading a website, it makes a trip to that website’s server, asks for the file and downloads it before moving on to the next. ‘Asking’ for the file takes time, so the more ‘asks’ the more time it takes. Websites can speed up the process dramatically by simply combining files together, so the browser has to make fewer trips.

Another way to improve this is through concatenation, combining your multiple minified CSS and JS files into a single CSS and JS file. This is especially important on mobile, which as we know is an ever-growing proportion of most sites visitors. Google recommends a 1s page load time on mobile which as you can see actually only leaves you with a small section of that 1s to achieve what you need as you can see in the graphic below. Although concatenation won’t drastically reduce total file size as they are already ‘minified’ it will reduce the amount of trips that you will have to make stopping your browser from having to repeat this process over and over and making it quicker overall. It’s worth noting though that concatenation shouldn’t be a flat rule however, look at each of your files and look into the pros and cons of including it in a site wide concatenated file

Rendering a mobile page in 1 second

To use the example of the Amazon checkout page again where we discussed the need for every millisecond of reduced loading possible for maximum conversions (and therefore profit) there has already been a massive reduction in the amount of imagery included on page. With very minimal page styling when compared to the rest of the site there wouldn’t be much benefit to including the entire sites stylesheet into this page for the minimal amount of applicable styles. Instead you might keep the checkout styling un-concatenated and include only the drastically smaller Stylesheet into the page reducing the load times even further increasing the rewards.

What is render blocking JavaScript and CSS?

Traditionally, before your browser loaded or ‘rendered’ a page, it would read every single line of code or instructions in order until it reached the end. This meant instructions like loading a CSS file were effectively ‘blocking’ the page until it had finished. Now you can tell your browser to ignore unnecessary instructions, or to do several instructions at once, to help your page load in record time.

Although in the insights tool Javascript and CSS fall into the same category, they can be very different. As a lot of JavaScript used is for a layer of interactivity on top of a webpage, this can often be done with a lower impact and depending on the function of the JavaScript in your site may even go completely unnoticed.

JavaScript

Historically JavaScript-based solutions involving inline scripts would insert your desired external scripts into the page after it loaded, allowing scripts to be added without impact on initial page loading. Now it’s easier to do this by adding an ASYNC or DEFER attribute to your external script tag to control how the file is treated by supported browsers. Which one you use will depend on your specific situation, but essentially the differences come down to this:

• No ASYNC or DEFER attribute - HTML is parsed until the external script is reached. HTML parsing then stops until the script has been downloaded and executed before resuming.
• ASYNC attribute - HTML continues to be parsed while the script downloads and only pauses to execute the script, which is usually for a much shorter period of time.
• DEFER attribute - HTML continues to be parsed while the script downloads but will wait until HTML parsing has completed before being executed.

Which option you choose will depend on your specific needs, but you should use one of them. The browser support for these features is pretty substantial, although some older versions of IE and Mobile Opera for example will still block page rendering. For this reason you should include your scripts just before the closing body tag rather than within the head so you can still improve the experience on unsupported browsers. Of course there will always be exceptions and you will have to decide on a project by project basis, but wherever possible you should aim to do this.

CSS

Much like JavaScript blocking page rendering, external CSS stylesheets can have the same effect. If you have a very small stylesheet, you can avoid this by putting all your CSS in the head of your webpage. However, in most cases, your stylesheet will be too large for this to be practical. The solution is not quite as simple as adding an ASYNC or DEFER attribute to JavaScript, but Google has provided an easy method to achieve this, implementing something called ‘lazy loading’

One issue that can result from this is a ‘Flash of Un-styled Content’ (or FOUC for short), where the browser briefly loads the page before the stylesheets have downloaded. Although this is technically a good thing, it can be jarring to the user and result in a less than great looking page. This isn’t what people want from a website, which is one of the reasons many developers avoid using this method in the balance between user experience and PageSpeed score.

Medium impact issues

What is browser caching?

If your website has the same hi-res image on every page, whenever you move to the next page you have an unnecessary wait as that image is downloaded again. Browser caching saves time by telling your browser to simply use the identical image you already downloaded for the previous page.

Browser caching is the process of setting HTTP headers on certain files or file types so that the client’s web browser knows not to bother requesting those assets again for a certain length of time. This can easily be achieved in Apache by adding a few lines to your .htaccess file (or similar for nginx, IIS, etc.).

This is great for high resolution images and large JavaScript files which rarely (or never) change. However one “gotcha” is that there’s no easy way to tell the client to fetch a new version of that same file. A common work-around for this is to simply change the file name, or add a query string to the end of the file name (image. png becomes image.png?v=2) to make the browser believe it’s a different file. You should factor this workaround into your build process if you use HTTP headers for browser caching (here’s a Grunt plugin to help you do it: https://github.com/hollandben/grunt-cache-bust)

What is enabling compression?

Modern browsers can also ask for zipped up or compressed versions of certain files – if the website is set up to provide them – reducing the file size and the loading time.

Enabling compression is another HTTP header which can be set on certain files or file types. It is achieved in the same way as setting the browser caching headers, and simply compresses the assets before sending, minimising the file size during transmission. The file is then uncompressed by the browser. Unlike browser caching there is no discernible “gotcha” for this, so you should definitely do this for your HTML, CSS and JS files - your images should already be compressed.

What is prioritise visible content?

Visible content is the top part of your website that you see when it first loads (if you have to scroll down to see it – it’s not ‘visible content’). Simply loading the smaller visible part of your page first, rather than making the user wait for the entire page to be ready, can provide huge time savings.

Prioritising visible content is the logical next step from eliminating render blocking assets, and allows the browser to load the page in order of importance. There isn’t just one section of your site that you will need to focus on, all areas need to work together to achieve this to full effect.

HTML

Starting off with your HTML structure, you should think about what you want to prioritise. Is your sidebar before your main article content in your markup? Do you have third party banners placed above your navigation? There is a natural hierarchy to your page content and, although each page is different, you should be able to identify what is most important: main content, primary actions such as your header navigation, secondary actions and finally other content such as ads. Sometimes you will structure your HTML as per the page design, but that doesn’t always have to be the case. You can do a lot with CSS to make sure your key content comes first, especially with new techniques such as Flexbox, so start by thinking about what you can do with your markup.

JavaScript

JavaScript follows a very similar thought process. What is necessary immediately upon page load? More often than not there are processes that can be deferred until later. Assess the scripts that are being initialised, both your own and third party, then create a workflow triggering them in order of necessity after the most urgent function has been initialised.

An example of this could be:

1. Load in main content
2. Initialise hero slider
3. Initialise videos
4. Initialise social sharing

By prioritising the content and above the fold functionality over secondary features, you are allowing the browser to load a functional page quicker. This means the user is already engaging with the most important parts of your site whilst the rest of the page is loaded in the background. This is most easy to implement during the development of your site but can be retrofitted – just make sure to test thoroughly.

CSS

Prioritising visible content in CSS can be a little trickier to build and maintain but can deliver great results if implemented correctly in that you can simultaneously counteract the effects of removing render blocking CSS too at the same time. By pulling out a small amount of your CSS in the head to create a minimally styled webpage, such as a content area and sidebar structure with a solid background, whilst lazy loading the rest of the stylesheet you can minimise the effect of the flash of un-styled content. This creates a much less jarring experience for your user whilst still providing a faster loading webpage, the ideal balance between PageSpeed and user experience.

HTML Minification

Compared to CSS and JavaScript, HTML minification will deliver fewer savings in terms of file size, at best probably a few KB for an average HTML page. Unlike CSS and JavaScript which are usually static files which can be minified once whenever they are updated, an HTML page is quite often dynamically generated. If the page is dynamic it doesn’t mean you can’t take advantage of HTML minification - there is a solution out there for most situations if you do some searching. For static pages it’s even easier with many tools and plugins to help.

Further Considerations

What is a CDN?

A content delivery network or ‘CDN’ solves the problem of people accessing your site from the other side of the world by hosting your site on a number of different servers across the globe. Each user is then sent to the server that is geographically closer to them. Less distance to travel = quicker page loading.

By using a CDN, especially if you have an international audience, you are taking some of the PageSpeed Insights tools points to their maximum effectiveness. If minification aimed to reduce the size of the trip and concatenation the amount of trips a browser had to make then a CDN aims to reduce how far it will have to travel.

If your site is hosted in the United States and you get a visitor to your site from Australia then each request has to travel half way around the world and back to complete its trip. Now imagine that you have servers sat all over the world each with a copy of your files. Now whenever you get a visitor, no matter where in the world, the CDN will work out which is the closest server to them and deliver the assets from there, making the trip a shorter distance.

This can also have the added benefit of making it less likely for your site to slow down and/or crash. There are many great CDN services out there that will even take into account how busy a particular server is when making its choice and if one was unavailable move to the next. This is particularly important if your site is prone to sudden spikes in traffic and you still want to deliver the same fast site to everyone.

Single URL

You will have noticed when using the tool that you can only input a single URL and that is exactly what it will test - and no more. You will probably test your homepage first, but don’t forget to try other pages around your site, as quite often visitors will land directly on a page deeper within your site like a service page or a blog post.

You may notice when doing this that you get issues on other pages which don’t need to be there at all and can be an easy win to resolve. Do you have a thirdparty comment system that is included cross site but is only used on blog posts? Issues like that can be easily resolved but you may only notice when comparing multiple pages.

Other tools

Google’s PageSpeed Insights tool is an essential test to run when it comes to your website as this score is what will influence your site rankings. But when it comes to optimisation of your site there are a number of other useful tools and tests you might also want to consider.

YSlow

YSlow comes as a extension for most major browsers and is a real go-to test for a detailed look at the successes and failings of your site. A lot of the tested areas cover the same ground as the PageSpeed test however there are some others that are a nice prompt such as amount of DNS lookups and caching AJAX. Another nice touch to this tool in that rather than a pass fail approach it will grade you from A – F allowing you to prioritise the critical areas.

Pingdom

Pingdom provide a website speed test which although doesn’t provide any advice does provide you quite a bit of actionable information about server response time for your site. At the least you will get a score out of 100 and basic information like how many requests, total load time and page size. To get the most out of this tool though you need to look to the waterfall section, small disclaimer however as you may need a little bit of technical know-how to fully understand the results that it is giving you, if you want to have a chat and talk through any of it and what you could do to improve it feel free to get in touch with us.

Essentially though what this tool will give you is an independent view of how the browser is receiving your site, giving you a breakdown of each step of the process for each asset. With a timeline from DNS Lookup to receiving data from the server you can start to identify key problem areas in server response time for your site in a much more detailed way then you receive in the PageSpeed test.

Conclusion

There are a lot of different ways to optimise your website. We’ve covered a lot of points here and barely scratched the surface. Using the Google PageSpeed tool as part of your assessment process can help you spot red flags in your build, as well as suggest ways to fix them. It’s invaluable advice and if you follow it you will absolutely see improvements in your site speed.

That said, look at each suggestion critically and assess whether it’s possible for you. Some may not be practical, but it’s worth taking the time to find out. After all, any effort that you invest in optimising your site won’t be wasted.

The abundance of great content online means you can’t afford to take your visitors for granted. As the Kissmetrics study in the introduction revealed, a massive 79% of users said they were unlikely to return to a website whose performance was unsatisfactory, and no business can afford to lose that many people. In a world where convenience is key, speed will help you avoid driving people away from your site and towards your competition. As a further reward for this dedication to your users, Google counts your site speed when calculating your search ranking, so its win-win all round.

However, if you are really serious about your site optimisation, don’t limit yourself to the results on Google PageSpeed tool. There are numerous factors that it doesn’t cover, many of which can make a huge impact on the speed of your site. Even if you follow the steps described by Google to optimise your images, if you have 200 of them on your page it will still impact on your load speed and the visitors to your site.

Research has clearly shown that even the slightest loading delay can interrupt the user’s train of thought – and if that train of thought was heading to the checkout then your slow website is indeed costing you money.