Responsive vs Adaptive Web Delivery

Interchangeable terminology plagues the web development industry; Responsive (RWD) & Adaptive (AWD) are two very different approaches…

5 minute read


What is Mobile Responsive?

This means nothing, someone started using it and it now appears everywhere.

It’s called…

Responsive Web Design” and “Adaptive Web Delivery.”

These concepts work independently, but also together, to achieve very different types of mobile friendly/optimised web experiences.

Responsive Web Design (RWD)

Appeared properly in about 2012, it’s the idea that a website “works” on a mobile device, or more accurately, is optimally presented on devices with different size screens. The name “responsive” is attributed to the notion of the website “responding” to the environment in which it is presented, i.e. Portrait / landscape, mobile, tablet, small laptop.

Websites work on mobile devices usually anyway as you can zoom in and navigate around the full site, just on a tiny screen. With true responsive design, the interface appears more like a mobile app with vertically stacked content, proper mobile-style navigations (with hamburgers!) and content generally presented in a logical readable fashion.

The fundamental principle of responsive design is a fluid layout, which works whatever the screen size. Content is shown/hidden/modified (font sizes, long descriptions) based on how best to present the information given the screen size and other limitations of mobile browsing.

RWD is handled entirely by “the client,” i.e the browser on the computer or device and affects only the presentation. There is no involvement from the server, the content sent to the requesting device is the same no matter what device it is. Developer-written JavaScript and CSS are then at play controlling which content is shown/hidden and how so. RWD, by principle, has no author control capabilities, i.e. The website administrator/author cannot make decisions as to how the website behaves responsively, this is coded by the developer.

Adaptive Web Delivery (AWD)

So what’s this… Adaptive web delivery used to be believed to be the idea that a website has 2 or 3 “breakpoints” in the presentation, i.e. Desktop and mobile, or desktop/mobile/tablet. There would two or three ways in which to present the content for each viewport width and anywhere in between was a best effort.

This is not what adaptive web delivery is….

Adaptive web delivery is when content sent to the site from the server or CMS is explicitly altered, different or non-existent because the site is being viewed from a mobile device or tablet. In fact, the rules can be applied to any device via user agent string evaluation. Additionally, the principle of adaptive web delivery is the same for personalised content delivery, different content based on some rules. One of the main advantages of AWD if it is built properly, is that it should be built so that the CMS content author can configure the rules defining which content shows on which devices; this can be exceptionally powerful (this website can do that!)

Reasons for using adaptive web delivery can be for performance/efficiency, enhanced user journeys, progressive enhancement etc.

A real use-case for progressive enhancement could be:

“I am visiting from a device with a high pixel density screen, show me images sampled at double resolution.”

Or, for the performance/efficiency case:

“I am visiting a site that has many images from a mobile device, only serve me some of the images so as not to slow down my experience.”


The underlying principle - different content for different devices, not just presentation alterations.

In summary

Usually, adaptive web delivery is used in conjunction with responsive web delivery to comprise the overal mobile experience. Combined, these two can have great impact on the user experience for mobile visitors.

Neither RWD or AWD are limited to just mobile/tablet differentiation for their effectiveness, there are many other conditions which can be applied to alter the experience for users. For example, feature and browser detection can be used to give different messages to users based on their browser, or only serve content which they can effectively use or interact with (example within an example - some browsers don’t support HTML5 video, so users would have either a different format video, or a fallback image).

There are some classic examples of where the two overlap, including application of img srcset technology.

Which one do I need?

The question should more be about what are the functional requirements. If there is a solid business case for providing different content to users based on their device (maybe you have 80% mobile traffic as your audience) then the effort involved in implementing AWD could pay off. In all cases, if you’re having a website built for the future, RWD should be part of it, with no exceptions.

If in doubt, ask a web development professional for advice and to explain the benefits; in most cases, AWD is overkill but can open the door to some really powerful possibilities for websites with heavy traffic and high commerical value.

How do I get it?

Responsive web design is commonplace, adaptive web delivery usually goes beyond what simple or basic websites are capable of. If you’re having a website built and responsive design hasn’t been mentioned, then questions should be asked of the developer.

Enterprise level CMS’ such as Sitecore, Adobe etc. come with a level of adaptive web delivery built in, but these websites require an implementation partner to build a bespoke front end, which will have to be done with RWD. These enterprise CMS’ can also be extended to support advanced adaptive capabilities. (This website is built on Umbraco with vast extensions and now supports administrator configurable AWD :-) )

Amateur-night CMS’ like Wordpress or Wix will come with responsive themes, but no adaptive web delivery capability, yet. They are also fickle and typically built with hacky code which effectively counters any of the performance gains of RWD/AWD.

  • User Experience
  • Digital Marketing
  • Automation
  • Product Development

Leave a comment