Responsive web design (RWD) is the current buzzword but, despite it being around for more than two years, in many ways it’s still in its infancy. Designers are faced with a fragmented and ever-changing landscape of devices, code frameworks and browser capabilities – and, of course, the need to work in a new way with clients to manage the process of creating responsive websites.
More specifically, responsively designed pages are inherently more complex than the average dedicated mobile website page. Due to this complexity, RWD requires giving performance more dedicated attention if you wish to avoid degrading speed and increasing data usage for your users. As any of us who are frequent mobile users know, there can be nothing more frustrating than slow loading web pages and it can make or break the success of a business’ online channel as users who are made to wait too long will quickly move onto another site that works faster.
Practically every company I speak to, around the globe, is either going responsive, has gone responsive, or – at the very least – is giving it serious consideration. But this begs the question, with all this buzz, how many websites are actually responsive?
I recently ran a test on the top 10,000 websites (per Alexa), to check if they are responsive. This test was a repeat of at test I ran last year and relies primarily on the presence of a horizontal scrollbar when loading the page on a small screen. If the scrollbar is there, it indicates the website didn’t adjust its styling to the display, and thus is not responsive. What I found is that the percentage of responsive websites amongst the top 100, 1000 and 10,000 websites is quite substantial, reaching 18.7% adoption rate in the entire data set.
Clearly this is a trend that organisations are adopting, so it’s worth considering some of the top tips when embarking on responsive web design which will help to better navigate the hazards and help ensure performance, optimisation, and data usage for organisations’ websites:
Download images appropriately sized to the relevant screen
This technique is known as responsive images. Responsive websites usually display the same image across all display sizes (assuming the image is not hidden), but define the display size of the image using a percentile to make it smoothly adapt to the size of the screen. This technique, known as fluid images is great visually, but creates waste in the amount of downloaded data.
Avoid downloading hidden images by using smarter image loaders
In addition to making images fluid, Responsive websites use style rules to hide images 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. Since most responsive websites show significantly fewer images on smaller screens, this issue competes with #1 for being the primary reason for the excessive page weight of responsive websites loaded on a single page. Use the picture element and JS-based loaders, like those described in tip #1, to avoid downloading these hidden images.
Use RESS – REsponsive + Server Side to optimize your site for known clients
Introduce performance testing into your QA or build process
At the end of the day, you can’t optimise 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. Take a look at the list of WebPageTest scripting commands to see these manipulations, usually performed on the Chrome browser. 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.
Guy Podjarny is CTO web experience at Akamai Technologies