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.
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. This can be achieved using srcset, a new standard that already gained good browser support. Alternatively, it can be done using less widely supported standards, for instance the picture element, aided by JavaScript polyfills. Resizing images on the server means the payload sent to the small screen is smaller and the page is faster. Note that for best agility, only store the “best” image on the server, and use proxy image transcoding services, such as Akamai’s Image Converter, to resize the image just before it’s delivered to the client.
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.
Conditionally load JavaScript
This is especially true for third 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 chats 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 third party scripts can also introduce reliability failure points to 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 are actually needed, avoiding 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.
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 it often leads to bloat and excessive downloads. Some of this can be handled using smart loading, but other types – like excessive HTML and CSS – are much harder to deal with on the client. 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 less performant. 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.
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
You are in: Home » Guest Comment » GUEST COMMENT The top five tips for ensuring responsive web design performance
GUEST COMMENT The top five tips for ensuring responsive web design performance
Guy Podjarny
This is an archived article - we have removed images and other assets but have left the text unchanged for your reference
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.
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. This can be achieved using srcset, a new standard that already gained good browser support. Alternatively, it can be done using less widely supported standards, for instance the picture element, aided by JavaScript polyfills. Resizing images on the server means the payload sent to the small screen is smaller and the page is faster. Note that for best agility, only store the “best” image on the server, and use proxy image transcoding services, such as Akamai’s Image Converter, to resize the image just before it’s delivered to the client.
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.
Conditionally load JavaScript
This is especially true for third 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 chats 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 third party scripts can also introduce reliability failure points to 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 are actually needed, avoiding 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.
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 it often leads to bloat and excessive downloads. Some of this can be handled using smart loading, but other types – like excessive HTML and CSS – are much harder to deal with on the client. 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 less performant. 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.
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
Read More
You may also like
Subscribe to our email community