Responsive Web Design is the current buzz word going around the Internet right now. But, despite it already having been around more than two years, it’s still in many ways 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.
Here are some top tips to consider when embarking on responsive web design which will help to better navigate the hazards and help ensure performance, optimisation, and data usage for organisations’ website:
1. Avoid Downloading Hidden Images
Responsive websites primarily 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 is the primary reason for the excessive page weight of responsive websites loaded on a single page.
2. Download Images Sized To The Relevant Screen
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 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 display’s capabilities using a smarter image loader like the one discussed in tip #1. Resizing it on the server means the payload sent to the small screen is smaller, 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 (still on the server) in realtime.
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 by dynamically adding elements to the Document Object Model (DOM) wherever possible instead of using the “document.write()” function.
4. Use RESS To Optimise 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 and CSS – 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.
5. Introduce Performance Testing
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 various such 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 is 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.