Top 5 Tips for Making Fast RWD Sites

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:

  1. Avoid downloading hidden images by using a JavaScript-based or CSS-based image loading technique. Responsive websites primarily use style rules to hide images that don’t fit on the screen, by setting their style to “display:none”. However, hiding an image in this fashion does not prevent the browser from downloading it, resulting in a wasteful download of an image that won’t be shown. Since most responsive websites show significantly fewer images on smaller screens, this issue is the primary reason for the excessive page weight of responsive websites on mobile.
  1. 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.
  1. Conditionally load JavaScript, and especially 3rd party JavaScript. Responsive websites often include JavaScript components that are not actually used on a small screen. Examples include Twitter streams, location maps, live agent widgets and many more. Like the image examples above, hiding the output of those images using styles does not prevent the browser from downloading and executing the scripts. While smaller in payload, scripts have a much bigger byte-for-byte impact on page load time, and 3rd party scripts can each be a single point of failure on a page.

    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.
  1. Use RESSREsponsive + 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.

    For such issues, the only real solution is to introduce a server side component that identifies known and popular clients, and tunes the HTML accordingly for those clients alone. Other clients will get the responsive website, which should still work, even if it is not as fast. A good example of this is to trim the biggest “large screen only” portions of your HTML when identifying that a client is a known smartphone, often eliminating in the same stroke references to JavaScript and CSS files that won’t be needed.
  1. 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.

Posted on November 26th, 2013
  • Andre

    Can not agree more. I am doing the same thing at the moment.

  • http://love2dev.com/ Chris Love

    Great points, too often overlooked by the masses.

  • Bojan Bjelić

    Good points, some of these are a part of what’s called “adaptive” web design these days.

  • http://mpulp.mobi/ Jon Arne Sæterås

    In many cases I see 4 as a solution to 1,2 and 3.