I was recently asked to provide a list of 5 tips for making Responsive websites fast. I’m usually not a fan of such “top 5” lists, feeling they over-simplify concepts that are quite complex (I definitely spend a good chunk of my time talking about this topic). However, as I wrote the tips it actually felt like 5 was the perfect number for the tips I had in mind, and that they did manage to paint a complete picture.
And so, I figured it’s worthwhile sharing these tips on this blog as well. The tips are roughly in order of priority, based on my assessment of their criticality, except for the last one, which is really a wildcard.
Without further ado, here are the top 5 tips for making your RWD (Responsive Web Design) site FAST:
Download images appropriately sized to the relevant screen, a technique known as “Responsive Images“. Responsive websites usually display the same image file across all display sizes (assuming the image is not hidden). The display size of the image, however, is defined using a percentage, and thus smoothly adapts to the size of the screen. This technique, known as “Fluid Images“, is great visually, but once again creates waste in the amount of downloaded data.
A better solution is to create several versions of each image, resized on the server to the appropriate size, and download the one closest to the current display’s capabilities. Doing so will again require using a smarter image loader, like the one discussed in tip #1. Resizing the image on the server means the payload sent to the small screen is lighter, and thus the page is faster. Note that an alternate approach is to only store the “best” image on the server, but use services like Akamai’s Image Converter to resize it (on the Edge) in real-time.
Therefore, it’s best to wrap those scripts with a small, inline script that checks the device properties and only adds the scripts to the page if they will actually be needed, thus avoiding the unnecessary slow down and reliability risks. It’s important to do so with care, to avoid slowing down the large screen version of the site. For instance, where possible prefer dynamically adding elements to the Document Object Model (DOM) over using the “document.write()” function. Note that Conditional Loading can be applied to CSS as well, though doing so in a performant manner is harder to do.
Use RESS – REsponsive + Server Side – to optimize your site for known clients. Responsive design is a great tool for supporting many types of clients without even being aware of its existence, but – as demonstrated in the previous tips – it often leads to bloat and excessive downloads. Some of this bloat can be handled using smart loading, but other types – like excessive HTML – are much harder to deal with on the client.
Introduce performance testing into your QA or build process. At the end of the day, you can’t optimize what you can’t measure. If you want to become fast and stay fast, it’s important to introduce a performance test into your regular testing and quality assurance processes, and to do so as early as possible in the flow. Tools such as WebPageTest and many others make it very easy to add a simple performance test of key pages on your application, and run those tests from browsers resized to different viewport sizes and simulating different device pixel ratio (“Retina”) properties.
One simple starting point is to measure the performance of a given page on your site today 20 or 30 times, mark the median page load time as a baseline, and note the standard deviation. Now introduce the same performance measurement into your build process, and if the new median page load time in more than one standard deviation higher than the baseline, mark the build as broken. This will help you prevent your performance from degrading over time, and will now let you focus on making that baseline smaller.
That’s it. Clearly there’s a lot more to elaborate on for each one of these bullets, but hopefully these tips can help you put a strategy in place for making sure going responsive doesn’t mean going slow.