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
Compared to todays normal broadband speed of 8000k, the early days of the web so access speeds around 30k. As a result, in the late 90’s through to the mid 00’s is was best practice to keep page sizes under 100k and landing pages under 30k. It was a lovely idea but the narrow pipe restricted the provision of lots of digital services so as the adoption and speed of broadband went up so the old 100k limit went out of the window.
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.
If you take a look at the table to the right you will see a selection of our recent web-sites and their relative response times. The range of response times is very wide and it’s easy to see which ones are in special measures! Anything consistently over 1 sec response time will receive our attention and we have 1 urgent ones (1,646ms) and one on the watch list (1060ms). The site running at 2,000ms is a special case as it’s a login, subscription site and inside it’s agreed response time (it’s very weighty!).
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.
- 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?
Serve static content from a cookieless domain
Are there any disadvantages to doing this? Regards David