By Martin Dower
There are three main driving forces surround web-site speed optimisation.
- Google rewards faster load times
- The explosion of mobile = slower download rates (sometimes)
- The user experience
It is now generally accepted that the site should respond in loading it’s entire visible framework within 5 seconds and the server. (See the our site measured in the picture).
In todays digital-rich environment the challenges of delivering a high-quality user experience across all platforms has set the bar high. Most agree that the Internet suffers with an obesity problem, pages are too slow to load and this hurts the user experience which in turns damages the conversion rate. Sadly, many of these sites could easily lose a few pounds just with a few tweeks.
Measuring Website Performance
Measuring site load speed is actually harder than you think. So many components of a web-page become cached at various points during their journey that it is damn near impossible to measure the absolute speed. It’s better, then, to measure the relative speed of sites against a standard site or a clutch of others. When measuring performance, you’re looking for consistently better than average performance.
Speeding Up
There are a number of approaches to speeding up web-sites, including:
- Better server, more memory, fast processor. We use Amazon AWS servers so this is relatively easy to do, we take a snapshot, start a new instance and bingo, we’re off and running with zero downtime.
- Re-starting the server. Like people, they can get tired and over-burdened; sometimes doing an automated re-start overnight will give the web-site a new lease of life. This is not a terribly good solution as it normally indicates a deeper, underlying, problem but it’s a fix alright.
- Use a caching mechanism to serve frequently used content in a faster manner. This could be at the core of the web-site or at the edge using a CDN.
- Serve some web requests from a faster source. This could be using Google’s hyper-fast JQuery server or simply using a dedicated domain to serve static content.
- You can and should optimise images and content, there is no need to load a 400k GIF image when 30k JPG look identical.
- You might want to consider optimising the actual code on the web-site. This can reduce the load time by a few percent by has the drawback of making management and changes trickier to deploy.
- At the technical level you can look to Performance Best Practices to speed up some of the technical elements of the site including enabling compression on the server and defer-loading and minifying the Javascript (typically one of the huge payloads).
- Placing your servers close to your users. We operate a dual country web-site (US and UK) and run two different Amazon Instances, one in Ireland for Europe and one in Virginia for the USA.
The explosion of CMS platforms such as WordPress and Drupal have, to a certain extent, caused many of these solutions to fall off the radar. They are, after all, a little bit technical and not every marketing department knows or understands the role of load speed plays and how to work it to their advantage.
If you are not sure how your site stacks up then drop us an email and we’ll run a quick test and tell you where you are. If you’re happy to go hunting on the web there are lots of tools out there; just be careful not to compare the results from different tools, remember that the absolute numbers are meaningless. Look for good comparative sites to test and compare against those.
Finally, remember to test mobile first. Is your site is fine on a mobile device then it’s probably going to be okay on a desktop.
This post was inspired by a client question today: Got a question to ask us?
Hi Nicky, I have been doing quite a bit of reading since my meeting with @Martin and I have been looking into our site. Something keeps popping up as a suggestion from many tools and that is:Serve static content from a cookieless domain
Are there any disadvantages to doing this? Regards David