Design & UX
By Aaron T. Grogg

Moving Beyond the Responsive Web to the Adaptive Web

By Aaron T. Grogg
Popup superhero book

Photo:Hope For Gorilla

Let’s get started with responsive web design.

No web developer today should be unfamiliar with the concept of responsive web design (RWD). Since the term was coined by Ethan Marcotte in May of 2010, the concept has been accepted as a best practice, the process has matured, and multiple options and implementations have emerged.


This has helped us refit the web for the devices that our users have today, and positioned it to work just fine no matter what new devices are dreamt up in the future.

However, as hugely successful as RWD has proven to be, it is not without its shortcomings.

Responsive imagery has proven to be one of the more complicated challenges to overcome, though we are finally getting closer to resolving this challenge with native browser implementations of srcset and the picture element.

The video and audio tags solve their media-specific problems by providing for multiple source elements and letting the browsers pick the one it likes best. However, this does come with the price of a lot of extraneous mark-up — even at the times when we know that only one source element is ever going to be used on a given device.

Responsive Web Design for Desktop

Both of these issues are part of a far larger challenge — the challenge of content and context. The mobile context is a world of potential limitations — including bandwidth, screen-sizes and CPU power. Irrespective of the device your user is using, as developers we should always be endeavouring to send them only the assets that they actually use.

Clearly for each of these examples outlines above, we are sending everything that they might need, and then letting the browser sort it out.

Beyond these large issues, we also have smaller issues like device capabilities, which we have mostly used JavaScript to solve on the front-end, after the entire page has been downloaded. But this puts even more onus on JavaScript, piles on more code for the user to download, and often causes at least some unsettling repaint as the solution is applied to the page.

What is Adaptive Web Design?

This all leads us to what I believe is the next growth phase in web development: Adaptive Web Design (AWD).

This concept has sometimes been called RESS, but regardless of labels, it involves making decisions on the server that determine what should and shouldn’t be sent to the user, so that nothing is sent that will not be used.

A few of the benefits of AWD are:

  • Reduced bandwidth – Because you can send something like this for each video on your site:
<video src="…"></video>

..instead of something like this:

 <source src="...mp4" type="video/mp4">
 <source src="...webm" type="video/webm">
 <object type="application/x-shockwave-flash" data="...swf">
 <param name="allowfullscreen" value="true">
 <param name="allowscriptaccess" value="always">
 <param name="flashvars" value="file=...mp4">
 <!--[if IE]><param name="movie" value="...swf"><![endif]-->
 <p>Your browser can't play HTML5 video. <a href="...webm"> Download it</a> instead.</p>
  • Context-aware modules – So you can send the “Call Us” module only to call-capable devices, the “Camera” module only to devices with cameras, etc.
  • Server speed for rendering – Servers are typically still quite a bit faster than any front-end device, so why not let the server do the hard work, and simply deliver the render-ready content to the device.
  • Caching modules on server – And once that hard work is done on the server, cache it there so it doesn’t need to be re-processed for each page load?
  • Faster page loads – By building and caching these modules on the server and delivering them with the rest of the page, you avoid the delay and additional HTTP Request that would be required if JavaScript had to determine what is needed and then request it via Ajax.
  • Choice of programming language – If it’s in the browser, it’s JavaScript. Your server, however, can use anything, as long as it outputs something the browser can render.

Of course, the concept of device detection is nothing new. It has been happening since the very early days of mobile (typically to redirect the user to a completely different site and/or URL), and it goes back even further, back to the bad old days, where JavaScript was used to browser sniff User-Agent strings to decide how our spaghetti-code would function.

We later learned that feature-detection was a more reliable and scalable approach, but this requires access to the browser, which means it has to happen on the front-end.

So, how can a server identify which device is making the request?

Ironically, we revert back to User-Agent sniffing — but from the server this time — and look at the User-Agent string that comes with the initial request header.

It would look something like this in Chrome’s DevTools:

Devtools user-agent

The AWD server code would look at this, compare it with values in a database, and return information regarding this device.

Easy, right?

Except for that little “values in a database” part…

Note that there is nothing in that User-Agent string that explicitly says “desktop” or anything else even remotely that obvious.

This means that human action is required, in the form of collecting and categorizing User-Agent strings and their correlating device categories. Which is why anyone that follows this path will more than likely want to use some form of service that does all that collection and correlation work for them (more about that shortly).

This seems like a good time to mention a few of the weaknesses of AWD:

  • Detection library maintenance – The moment a device detection library is updated, it is out of date, because new devices, and new browsers, and new browser versions, are being launched every day, seemingly every nanosecond…
  • Possible delays during server detection – Depending on how your device detection library works, it might cause a slight delay as the server determines your device and begins rendering your pages.
  • “Different site” on different devices – Some users could find it unsettling to find some site module or content when viewing on one device, but then can’t find that component on some other device (although this might be avoided by always offering a link to any varying versions of your sites).

So AWD is not necessary for all sites. If your site does not need all this varying content for varying contexts, or doesn’t use a lot of images, or audio, or video, you may be able to get by with just RWD.

And that would be great!

Any well-designed and well-constructed fluid website should work properly across any screen size, and as long as you aren’t clogging the tubes with redundant code to make things work properly, then your users should love you, and will hopefully love surfing your site.

Still here?

If you’re still reading this, then you’re probably still interested. Good. Then let’s get down to business!

Full disclosure is pertinent here, because I work for Netbiscuits, and they do offer a device detection service. However, there are several options out there, and they all differ in what they offer and what they cost, so it is up to you to do a little homework and decide which service or product best fills your needs and your budget.

Regardless of the solution you choose, you will eventually end-up with something like this in your server templates:

if (device.type === 'mobile phone') {
// insert a module that will only go to mobile phones

} else if (device.type === 'tablet') {
// insert a module that will only go to tablets

} else {
// insert a module that will go to all other devices


if ( === 'mp4') {
// this device supports "mp4" so only send a <video> tag for that codec
echo '</video><video src="...mp4" type="video/mp4"></video>';

} else if ( === 'webm') {
// this device does not support "mp4", but does support "webm", so only send a <video> tag for that codec
echo '</video><video src="...webm" type="video/webm"></video>';

} else if ( === 'swf') {
// this device does not support either of the above, but does support "swf", so only send that code
echo '<object type="application/x-shockwave-flash" data="...swf">';
echo ' <param name="allowfullscreen" value="true"/>';
echo ' <param name="allowscriptaccess" value="always"/>';
echo ' <param name="flashvars" value="file=...mp4"/>';
echo ' <!--[if IE]><param name="movie" value="...swf"/>< ![endif]--> ';
echo '</object>';

} else {
// this device is pretty weak, so send the user a link and let them fend for themselves…
echo '<p>Your browser can't video. <a href="...webm">Download it</a> instead.</p>';


The power you gain and savings you provide to your users depends solely on the service you choose to use and how greatly you take advantage of it.

On the Netbiscuits website, for example, we use our Device Detection service to choose which CSS file we send to the user, which dictates, among other things, whether icons are served as SVG data-URIs, PNG data-URIs, PNG URLs, or PNG URLs served via an IE-only filter to allow for transparency.

We also have access to the device OS, OS version, browser name, and browser version, all planted as data-attributes to the html tag, so we can add device-specific CSS for those pesky devices that just don’t want to behave.

Here are two examples:

AWD Tablet

AWD iPhone

And since these values are planted at the server, before anything is delivered to the device, there is no jarring visual experience or repaint required when the correct values are determined by JavaScript on the front-end.

So, whether you need an adaptive web design solution now, or you can make do with just a responsive web design site, hopefully you have a better understanding of AWD and the possibilities that are out there for you and your users.

I’ll be looking at both concepts in more detail in my future blogs and it would be great to hear any questions or ideas you would like me to cover.

  • JohnFAllsopp

    It do happens when I wrote A Dao of Web Design, I used the term “adaptive” rather than “responsive”. I’m glad we’ve got the term up our sleeve, as we do need our designs to adapt to far more than just screen size and resolution. An area I’m particularly interested in is deigns which adapt based on a user’s context, as determined by gyroscopes, accelerometers, light levels and GPS (among other sensors).

    nice work

    • Alex Walker

      I remember a demo a few years ago that had button targets scale up when it detected you were moving, but I’ve never seen anyone actually usefully implement it yet.

      In fact, I went running on Tuesday, got back and realized I apparently hadn’t hit the ‘Start run’ button on Runkeeper properly — and so hadn’t *officially* run at all. Which is more disheartening than it really should be.

      There’s no reason RunKeeper shouldn’t be smart enough to iblackout the screen — saving power — while it detects I’m actually running BUT also knows to light the screen and scale up the ‘Pause run’ button when I lift it up to my face. Haven’t seen many try anything like that though.

      • A bigger problem for me is not having touch work properly when my fingers are sweaty. Guess I need a digit-al upgrade. :-)

  • I was totally confused reading this… Adaptive web design has been around a while, but failed for the exact weaknesses described in the article. But the confusion cleared up when I read the disclosure of working for a company that offers the service of device detection! :-)

    The article would have less bias if it gave a paragraph to describe what RESS is. Many web developers see that as a much better solution because it blends the advantages of AWD with the strengths of RWD. But by far, the best solution is for mobile browsers to get smart and only download content that’s appropriate to them, using something like srcset.

    • Alex Walker

      I dont know. SRCSET — even if the browser doesn’t download the image content — is still a lot of pretty clunky code to send.

      • I agree that srcset is not ideal, but I think it’s better than device sniffing and programming everything server-side. It also keeps presentation in the HTML instead of moving it to the back-end. There are many different solutions offered in different frameworks, but they all seem too technical right now and require a lot of effort to make them work.

        • Alex Walker

          Good discussion. Can’t say I’ve actually ever used a device detection approach to this stuff, so this is purely talk theory.

          But to me, the idea of the content being composed with a single internal reference to a linked image resource is the ideal. SRCSET locks in a set of if/then questions that are part of the current browser landscape that this piece of content is venturing into at this moment in time. I don’t love that idea.

          As a tangent: Most of us talk differently to our kids than, say, our partner — even when the core message is identical — because we get a better response.

          It may be that the alternative to a SRCSET-like approach — i.e. crafting an ideal response on a device-specific basis — is either just too resource-intensive or unreliable or both to work in the real world — that seemed to be the case in the past — but personally if it worked I’d have no qualms using it.

          • Yes, we talk differently based on the audience. Eddie Haskell on Leave It to Beaver (flash-back) was a perfect example of that. But that doesn’t always work well when it comes to the web, and was one of the problems with Adaptive Web Design years ago. (Can also be a problem with Responsive.) Designers made the false assumption that user context was determined by device and rendered different content to different devices. Bad move.

            Several years ago I needed a piece of information I had found earlier on Microsoft’s website, so I pulled up on my phone. The website was nothing like the desktop version! There were a few marketing photos but nothing else. Nothing! Not even a link for the “full site.” Microsoft had determined that people visiting their website on a phone didn’t come for the same reason than desktop people did. Sometimes that’s correct, depending on the website/application, but it certainly wasn’t the case during my visit. That was device detection gone wrong. That may be an extreme example, but it does happen–even at large companies with lots of money to spend on websites.

            Images are usually the #1 problem for responsive/adaptive sites, and there are plenty of solutions available ( ). They all have problems. I think the ideal solution is to include some extra info in the request headers, like bandwidth, device resolution, etc. Then we won’t be dependent on JavaScript for that–it would be in the headers. Device orientation could still be a problem.

            Some day we’ll get it all figured out…

    • Hey, Ty.

      The purpose of the article was to highlight the benefits of picking and choosing what content the user has to download. To me this is what AWD / RESS is all about: make decisions on the server to decide what to send to the user.

      Even beyond being able to reduce bulky , , , tags to single elements, and getting more into modules, as mentioned in the article, like “Call Us” links in browsers without phone capabilities or “Find the Nearest…” modules if the browser doesn’t have GPS, etc.

      Sorry if my working for a tech company bothered you, it is not the reason that I write about technology in general, nor why I wrote this article.



  • Sp4cecat

    Welcome to the dark era of pre-iPhone mobile devices, where WAP and WURFL ( were king.

    ‘Course, back then, we didn’t have none o’ yer fancy HTML and JavaScript. Your 8-bit screen had up to 100-odd pixels across, with a palette of 256 colours for your gifs, and you had to know whether you should serve up the 90-pixel wide image or the 120-pixel wide image.

    You kids these days have it too easy ..

  • Working for a tech company didn’t bother me–I just thought it should have been disclosed up front instead of buried in the article. I’d much rather read an article by someone in a tech company who is actively involved in what they’re writing!

    It seems that poor site architecture and poor design choices create many of the problems we have today. But I totally agree with the “benefits of picking and choosing what content the user has to download.” It’s just that you skipped over RESS, which I think is a very good blend of AWD and RWD.

  • I’m glad those days are behind us!

  • Phil

    I wrote this about RESS last year:

    In my view it’s certainly the way to go as we see an increasingly varied range of devices for consuming digital content.

    • I read this article, and the one mentioned just above by Phil, and I still have only the briefest, 2-sentence definition of RESS, but thanks for that. It sheds a modicum of light but I hope that someone who wants to impart new information helpful to developers will write a how-to or explain why it is a better solution. Why does no one mention what I think of as the industry standard, modernizr?

      • Hi, lori. Modernizr is great, and certainly has a place in all of this multi-device-universe, but all of the decisions it can make have to happen on the front-end. This means that A) all assets must be sent to all devices, then Modernizr can be used to make the decision there, or B) only the bare essentials are sent to all devices, then Modernizr can be used to make Ajax calls.

        Option A is bad because because every device gets everything, “just in case”. Option B is bad because, especially on mobile devices, connectivity is always in question, so Ajax requests may or may not work.

        No one is recommending you “ONLY do this” or “ONLY do that”; our world is growing more complex everyday, and we need to know about all the possible solutions and make decisions on each use case individually.


        • Option A is certainly bad, but I don’t think Option B is bad if you’re using a mobile-first approach to web design. The mobile device will have everything it needs, while desktop devices may require additional requests for resources (images, AJAX, etc.) and they tend to have faster and more reliable connections.

  • Jason Purdy

    It’d be great if a browser’s capabilities and properties (viewport dimensions) were part of the HTTP request.

  • Alp

    The code examples in this article can already be done with WordPress sites and the Mobble-Plugin

  • Childe

    Hmm…User-Agent strings are all great, but what about proxy-servers and caching proxy-servers?

  • Toby Bettridge

    Why not use feature detection on the first time a device with a browser agent string connects to determine what subsequent browsers with that user-agent get?

    The first browser gets a slightly slower performance on its first hit but from then on it gets what it deserves. You’d have to make allowances for spoofing but it means you aren’t reliant on a third-party database and you can keep things up to date.

    Heck, you could store the browser capabilities in memcache for speed and to save hitting your database.

    • Hey, Toby. It really depends on how deeply you need to go in “what can each device do.” If all you’re looking for is phone||tablet||desktop, you can get pretty close, but what about “can this device handle inline SVG?” or “can this device handle HTML5 video, and if so, which format(s)?”?

      If you consider how many different User-Agents there are, this gets really complex, really quickly.

      At any rate, nothing is the right solution everywhere, this is simply one option for making our sites work the best they can for our users, regardless of where they and how they’re accessing them.


  • Very nice article. Came across Adaptive Web this week in another article and it realy made me thinking. People act different on mobiles, iPads and the oldskool computer and wants to read different content as well. As such some content should be included or excluded on the various devices. Believe it makes the experience of a website more interesting as well.

    • Be careful what content you exclude for mobile.

      There is a growing number of people who access the Internet primarily with mobile devices, and the way consume content on a mobile device isn’t that different than on a desktop. (Keep in mind that iPads fall in the “mobile” category.) We can definitely tailor the experience to the device being used, but it gets dangerous when we start changing content based on device.

  • Nested ifs to deliver a single asset might be effective today, but the idea feel archaic, yes? I mean, it’s 2015 (almost) and we’re still working with different sized lumber from different lumber yards, some bolts are metric and other not. WTF? In any other industry such a mish-mash would be unacceptable.

    Can’t we all just get along? Somehow? Kinda?

    • LOL… Your bolts example proves that other industries tolerate quite a bit of mish-mash and move very slowly toward unified standards. The Web will get there eventually…and then everything will change and we’ll have new challenges. :-)

  • cfc

    Sounds like a lot of micro-optimization of server side code for very little return. Browsers don’t download video files they don’t support, so we’re really only talking about extra HTML here. After compression, I seriously doubt a couple lines of HTML to offer different video formats is really significant, especially since that results in a static file that can easily be cached and potentially delivered to the client with zero server preprocessing. Building different versions on the server side based on what you think each browser can do requires you to cache a ton of different versions of every file — more likely, most implementations will end up not caching every possible version, which means in many cases users will be waiting while the server builds a new version and compresses it.

    As for the example of a “Call Us” link, there is software and plugins that allow users to make calls from their desktops. Also, how accurately can you determine the difference between phones and tablets, which frequently run the same operating systems at similar resolutions? It’s not reliable to make assumptions about a user’s calling ability based on their user agent string. Even if you don’t care about edge cases, removing one link is only going to save, say, probably less than 20 bytes after gzipping. I mean, we’re talking about shaving off maybe 0.07 ms — and that’s via 3G, probably the slowest connection in widespread usage today. (Of course, the people on a connection that slow will generally be using phones, so you’ll be sending them that extra link anyway. Most desktop users are going to be on cable modems, so in practice removing that link will typically have even less effect.)

    And that’s just for basic feature support, which you can probably rely on not to change during a browsing session. Not so for images. In order to handle the effects of device rotation and window resizing, even with a server side approach you still need to send code for multiple image sizes. That’s not even limited to images. It applies to all content displayed based on viewport size.

    You can’t get around the fundamental problem with old-fashioned browser sniffing. Using a database of information — that you admit in your article will always be out of date — to make assumptions about what a browser is most likely to support will never yield the same accuracy as a modern client-side responsive approach where the browser decides what content it needs based on what it actually supports. There will always be a vast difference between guesswork and reality.

    Bottom line, I just can’t see the wisdom in putting much effort into setting up dynamic micro-optimizations based on guesswork and assumptions. As others have pointed out, there’s a reason responsive web design has won out over browser sniffing. The small amount of overhead added in file size is outweighed by being more reliable, more flexible and more cache friendly.

    • Yes, I’m sure over 80% of websites don’t get any value from all the micro-optimizations. The really big sites might see significant results though. (A small percentage of a really big number tends to be pretty big still.)

      What you’ve described is exactly why I recommend that most clients NOT host their own video, but let a pro like YouTube or Vimeo do it. They’ve done all those micro-optimizations for video to provide the best possible experience, so why try to reinvent the wheel?

  • cfc

    In theory, you shouldn’t need to specify format in a tag at all — the browser should request the resource with an accurate Accepts header, and the server should automatically provide the video in an accepted format if available. The problem with this is that, at least in the past, the Accepts header has been so badly mis-implemented in every major browser.

    I don’t know if this has been improved in more recent browser versions, but if not, correcting usage of this header needs to be the first step. After that, it may be worthwhile to explore baking more in-depth feature detection into the HTTP protocol — though, since the stateless design would require adding that payload to every single request, that may not be the best way of implementing it.

    Regardless of exactly how it’s implemented, I do agree it would be great to have a reliable protocol for the browser to communicate its feature support to the server, at which point a server side approach to content negotiation could go a lot further. I think it’s important to remember, though, that it will never be a magic bullet. Server side approaches have limited applicability to viewport-size dependent content, so client-side responsive design techniques will always be an important piece of the puzzle.

  • And paranoid users who modify or remove their user-agent data.

  • Gring

    I’ve always be tempted to do that, but wouldn’t Google detect that as a cheat and punish your website by dereferencing it ?

  • jjjefff

    Adaptive or responsive? Meh – it’s a superfluous rebranding of the idea of “creating experiences that work everywhere”.

    The last adjective of any true significance was the “Redacted Web”, wherein Apple censored Flash from the Internet, the beginning of the end for the web as a rich, immersive, monetizable experience platform (YouTube, Pandora, FB Games, …). Now it’s all about the App Store.

    Hopefully the web can make a comeback, but the consistency and reliability (of tech like CSS3/webgl) still isn’t there.

  • James Edwards

    I don’t think there’s a future in the approach you’re describing — an approach which is (with respect) rather old-fashioned in its methodology, even if not in its intentions. Server-side browser detection is fundamentally unreliable, and absolutely the worst way of content-negotiating markup. It’s necessary now, I accept, but not as necessary as it used to be, nor as it will be.

    Are we seriously worried about “clunky” markup, about having to write some extra HTML in order to cater for different devices? Seriously? The benefit we’re looking for is to avoid having mobile devices downloading large amounts of stylesheets, scripts and images that they’re not going to use. It really doesn’t matter if we have to write a lot more HTML to achieve that, what matters is that we reduce the bandwidth requirement for mobile sites, and the size HTML is an insignificant factor in that.

    This will be achieved through semantic, browser-based technologies such as “srcset” and the SOURCE element — using markup that defines all the choices and the cases they’re intended for, and then leaving the browser to decide which one(s) it will actually download and use.

  • Adaptive webdesign provides all the benefits of responsive design without the drawbacks and this approach is widely consider a new concept but it is rapidly gaining acceptance.

Get the latest in Design, once a week, for free.