Inspired by posts from Tim Kadlec and Dave Rupert countering the perception that "responsive design is bad for performance" I outline the implementation choices taken to make this site both responsive and load as fast as possible.
- This is how I define my terms.
- The data given for this page were correct at the time of publication. You may get different results as I use user agent profiling to adapt content. I also use this site as a development lab for new techniques so it will change over time.
Whilst load speed is one of the most important items to measure it depends heavily on network connections and other factors that are not reliably reproducible.
However, I collect RUM data so it is possible to obtain data for how long it actually takes for pages to load for my users. Average times for the site as a whole vary but the time to load event is typically 1.5-2 seconds with the DOM ready event typically being under 0.5 seconds. The spot measurement by WebPageTest of 0.6s for the load event and 0.3s for DOM ready supports this.
Note: The fully loaded time as recorded by WebPageTest is 2.2s but this includes analytics and RUM measurement that are only initialised after the load event and are invisible to the user.
Page Speed Score
Even though Page Speed seems to have little correlation with load time it's still a good check list of performance techniques and it's best to score as high as possible.
The page speed score for this page is 99 and there is one recommendation: minify HTML. Whilst the bulk of the page content is minified I have chosen to leave sections of the source unminifed so that it shows how the page is built.
As each HTTP request comes with an overhead limiting the number of requests is good for performance.
This page needs 10 requests to reach document complete and 13 to fully loaded which puts it in the top 5% of pages tracked by the HTTP archive.
The amount of data transferred has an obvious effect on performance: the more data you need to transfer the longer it will take. The average total data transferred for a site as tracked by the HTTP archive is currently climbing towards 2000kB.
This page requires 130KB to be transferred which puts it in the top 5% of pages tracked by the HTTP archive.
The total amount of CSS data transferred is less significant for performance than the way in which it is delivered. Using
<link> in the
<head> of the page creates a blocking request. By inlining baseline CSS into the
<head> of the page with a
<style> element and delivering enhanced CSS asynchronously I have removed CSS from the critical path.
This page uses a minimal amount of images but they are optimised and have cache headers set. The logo uses SVG where supported. Some articles feature a number of content images, whilst I've not switched to using
I don't use web fonts but if I were to add them I'd use a web font loader to remove them from the critical path.
Speed index is a measure of how fast the visual elements of a page appear. Of all the metrics this is the one that best represents how fast a page appears to users.
As this page is both responsive and loads very fast there can be nothing inherent to responsive design that degrades performance.
I'll be the first to admit this site is not going to win any awards for visual appeal but I'm happy with it and it supports my primary goals:
- Deliver content in an easy to read format
- It should be accessible to any user on any device
- It should be as fast and reliable as possible
Your primary goals will probably differ from mine and you may well decide that to support them you need to place performance lower in your order of priorities. If you decide to place visual appeal and complex interactive interface elements above performance there is nothing wrong with that decision but you must be prepared to accept the consequent loss of performance is a result of your decision.
The fastest web page is an empty web page. Everything you add to that slows it down and everything you add is your decision.