In an age where the internet gives us access to seemingly unlimited information within a second’s notice, nobody likes staring at a loading screen for too long.

A slow load time will affect your conversion rates and it will ultimately affect your bottom line. Kissmetrics have created a fairly illuminating infographic on this topic that shows the extent to which users are prepared to wait for a page to wait. The majority of users (30%) would wait between 6-10 seconds before abandoning their wait for a page to load. Meanwhile, a single second increase to page delay can lead to a fallout of 7% in conversion rates. As with any form or customer service, the user doesn’t like to be kept waiting. If your website takes too long to load you are potentially harming the image of your brand in the minds of your intended customers.

The time it takes for a page to load is one of the big factors affecting your onsite SEO, your overall ranking and user engagement. Google essentially looks to support pages that provide a high quality user experience. The speed in which it takes a page to load is a decent qualifier of how usable your website is. The faster it is, the more responsive it is; and the quicker it helps the user navigate to the information they seek.

This all began in 2010, when Matt Cutts announced that site speed would inform how well your site ranks in google results entry. In an era where mobile is becoming the dominant platform for web interaction, the endeavour of keeping site speed as quick as possible has become hugely important. This is one of the reasons as to why responsive web design has become so popular as a fundamental approach to web design, since it offers a standard interface across all devices.

You can run a quick test of your website by typing in your URL into the Pingdom Website Speed Test. The tool will give you a mark out of 100, based on how big the size of your web page is and how long it takes to load. From there you can, gain more in-depth analysis into the individual factors affecting your site speed.

As a quick test, let’s see how the Google homepage performs.

Screen Shot 2014-05-19 at 11.17.34

As you can see, it loads within one second, largely thanks to its small page size and gains a high grade as a result. By contrast, here is how our own website performed.

Screen Shot 2014-05-19 at 11.15.08

This isn’t too bad for the most part. Our homepage has to contain several functions and visual features that add to its size. To provide a full breakdown of all the elements that factor into the loading time:
Screen Shot 2014-05-19 at 12.01.43

Let us go through the individual elements, to provide a sense of just what is going on and how it may be possible to remedy their effects to improve overall site efficiency.

Leverage browser caching

Your website and its individual templates are basically built up of lots of different elements, some of which are repeated across pages. This can include uniform headers and footers, images, such as your logo and the CSS files. When loading, the browser fetches all of these individual elements which can extend the loading process. To make it easier browsing from page to page, the browser will remember recurring elements so it doesn’t have to go fetch them time and time again. These elements are cached by the browser. This is why it is considered good web practice to use a clear uniform layout of templates as the backbone of your website.

Minimise Redirects

A page redirect essentially functions by ‘redirecting’ the browser to another resource should the one being navigated be inaccessible. Typically these are either 301 or 302 redirects – the former referring to a permanent redirect, the latter referring to a temporary redirect. Redirects are necessary when changes are actively been made to a website, or documentation is in flux. Obviously, employing a redirect can take additional time during loading, Google would hope you exclude their existence from your site if possible.

Remove Query Strings from Static Resources

A query string refers to the process in which a plugin transfers content values and version detail. This is usually the method whereby updates are installed. Static resources are obviously quite simplistic in their layout, so do not require any query strings that may prolong the reading process.

Specify a Vary: Accept-Encoding header

When browsers make a request they utilise HTTP headers to provide information to the server on what to send back. This is usually something that is held at the server management level.

Specify a cache validator

A cache validator is used to check whether a cached response is still good and hasn’t been pulled or taken away. Specifying a cache validator usually involves embedding either a Last-Modified or an ETag to the coding. This will inevitably make it easier for the page to load.

Avoid bad requests

Sometimes the website will be pulling links or images from another source. If these resources are taken away and therefore no longer present, this can cause the browser to go in circles when requesting the information. This of course is a waste of time and can prolong loading sequences.

Minimize request size

As a rule, you should ensure that you cookie and request headers should be no bigger than a single packet.

Serve static content from a cookieless domain

Static content refers an item that are fixed and cannot be changed. Typically they are easy to transfer, but to ensure that page loading isn’t extended, they are ideally pulled from a cookieless domain.


There are also a number of other smaller changes you can make which will generally lighten the load of your website or just make the loading process a lot faster.

Combine scripts

Many JavaScript and CSS files are often loaded in by various plugins, and are added to over time. Each additional file that is added to the list requires an additional round trip request from the users browser to the server; combining these files into one (one CSS & one JS in best case scenario) limits this considerably.

Compress/minify scripts

Scripts that contain unnecessary whitespace and comments take longer to download than their compressed counterparts. Scripts, once combined, can be ‘minified’ and can save in excess of 50% of their file sizes in some cases.

Enable Apache compression

Utilise Apache technology to reduce the server’s response file size can reduce the amount of data transferred by over 50%. It will require either mod_gzip or mod_deflate to be installed on the Apache server, which most will have as standard. mod_deflate is widely seen as an easier method, but moz_gzip has additional features. Either would achieve the desired effect, and can be configured by adding to the .htaccess file.

Enable browser caching

Browser caching can be enabled via .htaccess files for hosts that have the mod_expires configuration enabled. Setting expiry dates far into the future for regularly used elements mean these do not require client PCs to download as often.

Audit files and resources

Remove references to files that are not used or do not exist. This prevents the server sending and receiving bad requests, all of which take time. This will improve search engine crawler’s effectiveness of their time on your website also.

Move to a faster server

If possible, and not currently set up, switch to a host that offers solid state drives – this increases the entire website load speed. The server is already hosted in the UK.

Sprite images

Each individual image requires an individual request to the server. Image sprites reduce total file size and limit the number of server requests.

Compress images

Images include a host of non-visible information, known as meta/EXIF data. This is not required, but adds to file sizes. We ran Yahoo’s Smush.It service on your logo file, and achieved a lossless compression of 22.22%.

Make use of a CDN

Content delivery networks cache content around the globe so that local users get served local content and are saved the pain of waiting for the information to travel around the world. As the server is already in the UK, this may not be an entirely valid point as the data is already local, but CDN’s can have a small impact when used locally too, as the requests aren’t all sent to the one server, and the CDN’s often have load balancers and additional architecture in place that smaller web hosting packages do not.

Correctly insert code into the webpage

Some CSS loaded into the body of the HTML can cause rendering issues. Consider auditing this orphaned code and move it to within the document’s style sheet. JavaScript can also be moved to the document footer to speed up rendering time (in some cases).

Load asynchronously

Many third party scripts load content following the page load – i.e. Universal Analytics, Facebook, Twitter. Consider any other non-important content to be loaded into the page once the page has ‘loaded’ to speed up the page load time and rendering, without compromising on usability.

Obviously, you want to maintain a balance between the time taken to load a page and the functions and features you want to effectively illustrate your brand. Often all that is required is a developer go through the code of your website and streamline it. The simpler it is to read, the simpler a browser will read it.

This post may have been written by a past member of the Impression team, or be a collaboration of us all. We hope you like it!

2 thoughts on “Page Loading and Site Speed

  1. AvatarJAR897 says:

    Nice article summing up many of the different factors that affect page load times.

    I found that with W3 Total Cache minimizing JS and/or CSS files created additional load which actually made load speed worse than unminimized, despite Google’s Page Insights score being slightly better when minimized. Suspect it’s unique to each site/server.

    1. aarondicksaarondicks says:

      Thanks John – useful information. Suspect you’re right there – perhaps the caching had an issue. One extra tip we often do it configure the .htaccess file with a few other file header/expiry bits too, to ensure files are cached for a while after each visit.