The speed with which a web page loads is a major factor in how well your business will perform on-line. People don’t have time to hang around and wait, so all avenues for reducing page load time are ones that must be explored.
April 9th 2010 was the date when this officially also became a matter of SEO because that was the date when Google announced that site speed would be a new signal in their search ranking algorithms. If you’re web designer isn’t on top of this, you might be missing out.
Site speed factors
The main factors that contribute to your site’s speed are:
- server response time,
- cache configuration,
- code optimisation,
- HTML, CSS and JS file size,
- the aggregation and compression of these,
- and image file size.
Measuring site speed
At the moment, I use two freely available websites to help give me some insight into how my projects are shaping up:
Google PageSpeed Insights gives a score out of 100 for each of Mobile Speed, Mobile User Experience and Desktop Speed. For each of these it displays the results of a brief analysis that covers the placement of JS and CSS, browser caching, image optimisation, code minification, size tap targets, page-to-viewport scaling, font size legibility and server response time.
WebPagetest gives a single score out of 100 and an absolutely eye-popping analysis of statistics presented in both tabular and graphical form.
Both sites are excellent. Used comparatively - that’s to say repeatedly across a range of sites - they yield a massive amount of very helpful information. Much of it is actionable, some easily, some not at all so.
Here’s some of the WebPagetest analysis of this site’s home page at the time of writing:
Some page speed test examples
For comparative purposes, it’s worth seeing some real-world results of these two tests. (Keep in mind that both sets of tests need to be run for average scores to cater for variables in server behaviour).
Here are the results for the home pages of various websites (at the time of writing). RT1 is this one. RT2 - RT10 are other Drupal sites I’ve developed since April 2010. C1 - C6 are the home page’s of some of my competitors’ websites, some of which are also Drupal websites. (Feel free to email me for details.)
|Site||Google PageSpeed Insights||WebPageTest|
|Mobile speed||Mobile user |
[* RT7 was not designed for mobile and very deliberately had a hefty image slideshow on the home page, something which impacted substantially on the site’s speed.]
The first thing that stems from this is that this sort of information is actionable. You can do something about it. You have a much clearer idea of what action to take to speed up page-load.
The sort of summary information shown above is immediately understandable. By clicking any of these individual grade icons on the WebPagetest results output, astonishingly fine-grained information is displayed in each of these categories.
The second thing that shows clearly is that Drupal websites are not inherently slow. It is probably true that a plain HTML + CSS + Images website would probably finish loading before the same page wrapped in Drupal would - all other things being equal. But who doesn’t want a content-management system these days? And why wouldn’t you want the power of a Drupal one now that we’ve demonstrated that it doesn’t have site speed implications?
Site speeed summary
Because Google measures site speed and adds this to its ranking algorithm, I build websites with speed in mind. Maybe this is one of the reasons why so many of the sites I build seem to be favoured by Google.
… and next?
Two areas to explore in detail:
- the difference between optimised and progressive JPEG images
- CDNs: content-delivery networks