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:

Statistical summary from WebPagetest
Statistical summary from WebPagetest
Waterfall view from WebPagetest
Waterfall view from WebPagetest
Content breakdown from WebPagetest
Content breakdown from WebPagetest

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
experience score
Desktop score
RT1 75 96 93 92
RT2 73 99 85 84
RT3 79 97 91 89
RT4 64 100 81 78
RT5 69 99 81 83
RT6 76 98 87 80
RT7 68 59 * 80 92
RT8 64 99 86 96
RT9 68 99 85 87
RT10 73 88 84 80
C1 64 91 79 62
C2 64 60 69 59
C3 72 11 12 15
C4 57 57 66 71
C5 64 90 69 80
C6 71 98 80 96

[* 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.]

Actionable information

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.

Content breakdown from WebPagetest
Summary assessment from WebPagetest

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.

Speedy Drupal

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