Error getting theme layout

Performance Considerations of Adaptive Design: Part 2

Posted @ 2:26 pm by Amadeo Donofrio | Category: Creative Design, Strategy, User Experience | 0 Comments

As discussed in part 1 of this article, media queries are so easy to use that we can now deliver three completely different layouts to a browser, yet only display the one that’s particularly relevant. That means in some cases we are literally sending the same data three times when we only need it once! A better way would be to only deliver the content we need for a given device.

Responsive Images

Let’s consider images. It would be really nice if modern web browsers were smart enough to modify a GET request for an appropriately sized image for you, but they unfortunately don’t do this (yet). When it comes to background images, we can easily enough use media queries to download only the relevant image. That’s a good practice, but for inline images it’s trickier. Let’s examine three different approaches to solve this now.

Client Side Responsive Image with <noscript>

At the time of this writing, I’ve found no clear winner for a purely client-side solution to download inline images contextually. Although there are many techniques to consider all have their shortcomings. One method I do like leverages the <noscript> tag to print a default image tag. If JavaScript is enabled, children of the <noscript> tag are not added to the DOM, so the default image won’t download initially. After the DOM is loaded, you know the viewport size and you can replace the <noscript> tag with an image of the appropriate context programmatically using JavaScript. Here’s what the image declaration looks like. Note that alternate sources are included in HTML5 data-attributes.

It’s a simple bit of JavaScript to parse this mess out after the DOM loads. If by chance the user doesn’t have JavaScript enabled, then the default image is downloaded, which you can then resize appropriately with CSS. The obvious drawbacks to this method are that you must wrap all your images in extra markup, and then parse the entire DOM to programmatically load the correct image.

Server Side Component

All phones are not created equal. Some devices with slower processors still choke on JavaScript. If you like, you can move the conditional logic to the server. Consider implementing a device description repository like Wireless Universal Resource FiLe, better known as WURFL to determine the user agent string from the HTTP header. With a known device, we can serve images accordingly. Either your designer produces multiple versions of each image and stores them on a server, or you can implement a library like ImageMagick to generate scaled images on the fly. The down side to these adaptive approaches is that they cost more to both develop and maintain, and it’s critically dependent on the server’s ability to accurately identify a device.

Responsive Design + Server Side Components (RESS)

Still many advocate for methods that use the best of both worlds, a methodology commonly referred to as Responsive Design + Server Side Components, or RESS. One example of a RESS solution sets a JavaScript cookie with your viewport context in the header of your page, so you can use server rewrite rules to return context appropriate images. You can append alternate URLs to the query string of the source attribute. Something like this:

In this example, the default image is spaceship-desktop.jpg. With that cookie we previously set, and some simple rewrite rules in .htaccess, the query string can be parsed to serve the correct image. The con argument to this approach is that when in use with a content delivery network, you may run into caching issues where either assets with query strings are ignored (not cached thus served up slowly from the disk), or where only the query string is ignored so the default image is cached and served for every request. If you aren’t using a CDN, this method could be considered viable.

Responsive Content

Images are the biggest offender to performance in the responsive discussion, but they’re not the only issue. One of my clients decided that they didn’t want to display an entire column of content to mobile phone users. This is a prime example of when it’d be better to load content only for desktop and tablet users. Using a simple JavaScript evaluation like this can go a long way:

In the above example the loadContent function will only execute is the viewport is greater than 400. Of course this approach assumes that your web application can serve individual content modules ‘a la carte’. Your content also might ‘pop in’ the page gradually on slower connections, although some of this can be mitigated with CSS.


There is no “one size fits all” solution that builds a user interface both flexible and optimal. Responsive design is all the rage today and any front end developer worth their salary knows the basics. Performance optimization however is both art and science; doing it correctly takes both a sophisticated team and a smart match between available techniques and client needs. Depending on your users and your architecture, you may choose to optimize your adaptive UI on the client side, the server side, or both. Before you can make the right decision you’ll need to take a good look at your business needs and decide where your efforts will be most impactful.
Author: Amadeo Donofrio is a Front End Technologist, working with SolutionSet since 2006. He leads the User Interface Engineering team for the Social Business Practice.

Leave a reply

Error getting theme layout