Adaptive vs. Responsive Design & Development

When it comes to the web, there are a lot of different ways and a lot of different devices used to surf. Back in the Netscape era and the early years of the dot com boom, as developers or designers we really only had to worry about how a website would work on bulky CRT ‑ desktop ‑ monitors. There also wasn't any real issue when it came to feature support across browsers because at the time there wasn't a wide choice of browsers, and amongst them, those browsers only supported an extremely small set of the features we take for granted today.

In 2021, it's a different story. There are so many browsers to choose from, and so many devices to browse on ‑ even an iPhone user might not be using the version of Safari their device shipped with, they could be visiting using Google Chrome, Firefox, Brave, or any number of other systems, all with their own nuances and feature subsets. Aside from the conspicuous smartphone visitor who now makes up over 50% of global internet traffic, there are smartwatches, cars, cameras, TVs, and tablets; even the humble fridge has been connected to the Internet of Things and is now online.

How do designers, or we as developers, cope with this new unwieldy range of resolutions, browsers, and devices, each with its own capabilities and features? There are a few approaches.

Responsive Web Development

Responsive web development is a very popular approach to web development, and it is fair to say that the majority of modern websites you visit today will incorporate responsive techniques. With responsive development, the page that a user is visiting has the same markup no matter what device they are viewed upon. The DOM is structured the same, and the same CSS and JavaScript files are called and loaded.

However, the page looks different. Responsive development is about ensuring that the layout of the page flows between different resolutions and sizes, normally through the use of CSS media queries. If you're browsing a responsive site on mobile, you'll see the same HTML skeleton underneath, but the site will have had a mobile‑friendly facelift.

Adaptive Web Development

Conversely, adaptive web development is an approach that involves serving altogether different code to different devices. If you visit an adaptive site on a mobile, the idea is that the site will detect that you're using a mobile and then respond accordingly by serving you different HTML markup, with CSS specifically designed for a smaller and more appropriate breakpoint than the desktop version.

You may even find that the site has different functionality such as touch‑capable sliders not showing arrows, or an ever‑present search bar allowing for fast, specific navigation of the site. This is where it draws comparisons to Progressive Enhancement and Graceful Degradation, approaches to development that have been gaining popularity over the last decade due to the spread of browser capabilities.

Adaptive techniques were particularly pervasive during the couple of years following early smartphone adoption where mobile visitors were redirected automatically to an entirely different ‑mobile optimised ‑ version of the site, often an m. or mobile. subdomain. eBay for example would redirect early iPhone users to m.ebay.co.uk where they were presented with a significantly slimmed‑down and less functional version of the marketplace intended for slower network speeds, smaller screens, and lower‑powered devices.

Of course, today that particular practice is all but gone: the eBay link just takes you to the normal site now because the site now assimilates both feature detection and a responsive interface.

What are the Pros and Cons of Each?

The Upsides of Responsive Web Development

Following the mid‑2010s flood of mobile (subsequently chased up by tablet) traffic, Google introduced changes to its search algorithm to penalise sites that don't work on mobile and across different resolutions. Google explicitly recommends the use of responsive web design as a way to handle more resolutions and build more inclusive web apps and websites.

Having your website work across as many resolutions as possible through a fluid layout is a clear benefit; more devices mean more visitors and more visitors mean more potential customers seeing your site every day.

In terms of how it fares against adaptive web development, the responsive approach means maintaining a single codebase ‑ a huge benefit over maintaining the multiple separate templates and stylesheets that comes with the adaptive approach.

Another benefit of responsive web development is that you can potentially save design resources by simply designing one layout, whether that's a mobile‑first layout or not, and then allowing the developers to decide how it should change and adapt at various breakpoints.

It can also be relatively quick to achieve a simple level of responsiveness across a wide range of resolutions ‑ a definite bonus if you're on a tight turnaround.

The Drawbacks of Responsive Web Development

However, responsive design does come with drawbacks ‑ and some of them are pretty substantial.

For starters, because you're serving the exact same code regardless of what the user will actually see or be able to interact with, you're going to be serving unnecessary code: all the CSS that is needed to display on a massive desktop screen will still be transmitted to smaller devices. This means you're going to be increasing your visitor's load times without seeing the benefits, and when research suggests that users drop off exponentially as the time it takes your site to load increases over one second, that's something you really don't want.

You should also consider your visitors' data plans or situations. If you're serving code intended for a full HD resolution and a stable high‑speed internet connection, how is that going to function on a smartphone with a spotty 3 or 4G connection? That super‑high resolution hero image you've got in your masthead might look amazing on a 4k monitor, but how much of your users' data plans are you going to eat up by loading it in on a small screen? That ties into ethical web development (something that I've written about previously in such detail that it fell over two articles here and here), and it's important to bear it in mind.

One of the biggest drawbacks specifically for the developers working on responsive sites is that it can get complicated very quickly. If you've developed a complex layout, it can get messy when you're trying to let it flow from resolutions that work on the ancient (but still surprisingly common) iPhone 5 at a measly 320px wide, all the way up to HD monitors and their beefier iMac cousins, with retina displays capable of stretching your website out to a whopping 6016px wide.

You're going to end up with mountains of media queries very quickly, and they can turn your stylesheets into a real mess if you're not careful. If you're not using a preprocessor like Sass, it can get confusing and difficult to maintain pretty fast ‑ and when you get one of those all‑too‑familiar last‑minute (4.52pm on a Friday) changes from a client, it is easy to see the inevitable spaghetti code looming.

It's also unlikely that a user will need to see the site flowing across multiple breakpoints; they're far more likely to browse your site in whatever the size of their window was when they reached it. This means that you're serving bloated CSS files that are full of media queries that aren't being activated by your users, and even if you split the responsive work into its own stylesheet, you're adding a new HTTP request full of potentially unused or unnecessary code.

Finally, there are bits and pieces to remember when working responsively. One of the biggest gotchas that I find trips up even seasoned developers is the inclusion of the meta name="viewport" tag. Without setting the initial scale using this meta tag, non‑standard resolution screens (like Apple's retina displays) can act up and your media queries don't apply as you'd expect.

The Benefits of Adaptive Web Development

So, it seems like responsive web development might be the way to go, given the endorsement from Google and its popularity. That might be true, but there's definitely more than meets the eye when it comes to adaptive web development.

For one thing, check your analytics. If you're seeing groups of resolutions that your visitors cluster at (for instance, you notice a significant amount of visitors to your site are viewing it at 1366 x 768px: a common laptop resolution, and you notice another cluster at 768 x 1024px: iPad resolution), then it makes a lot of sense to develop specifically for those two breakpoints. This ensures that you deliver an intentional, well‑crafted, and well‑researched user experience at breakpoints critical to your website while saving resources by not focusing too much on the interim stages.

One of the biggest benefits of AWD though is based on functionality. Detecting if the device your visitor is viewing your site on has touchscreen functionality, and opting to hide carousel arrows if so (whilst perhaps introducing swipe‑type interactions), is a nifty trick that has wider ramifications. This sort of AWD is often compared to Progressive Enhancement, and for pretty clear reasons.

Detecting device locale to show or hide region‑specific content (or translated text), or displaying a more easily accessible search bar for mobile users to allow for quick and specific site navigation are all tangible improvements that can really make a difference to the success of your site.

What are the Downsides of Adaptive Web Development?

The biggest downside of AWD is related to its accuracy. The more accurate feature‑detection libraries ‑ like Modernizr ‑ are fairly weighty, and calling them adds to your load time. If you go for something more lightweight but less tried and true, you might find that you're getting false positives for certain devices or browser capabilities.

AWD also often relies at times on user agent string sniffing, a long‑discouraged and imprecise practice that involves reading the UA string that the browser sends to your server and using that to guess which browser is in use. This is not a reliable nor accurate way of doing things, as those strings can be manipulated (and over the years even the official strings used by browsers have become a bit of a convoluted mess themselves).

Adaptive web development also just doesn't work in every situation. With browsers and resolutions updating and changing as time goes on, it is easy to become out of date whilst assuming device capabilities. You'll also be missing out on Google's ranking benefits for responsive websites, too ‑ something that can't be overlooked.

In more tangible project terms, AWD has some issues. For one, it's more expensive; there are multiple designs and essentially multiple sites to develop. There are also more DevOps‑oriented aspects to consider on top of that, such as configuration and setup, that take a bit more know‑how and more time to put in place.

It's also harder to maintain an adaptive development setup, as you have to maintain multiple versions of the website instead of just tweaking a single codebase.

The Wrap‑Up

Whether adaptive or responsive design is the right for you depends entirely on your needs, as well as your budget, design and developer resources, and the complexity of your design. However ‑ the most ideal approach is a combination of both responsive and adaptive design.

Designing adaptively (i.e producing designs for different breakpoints, such as one for mobile and one for desktop) to outline what your breakpoints should look like at key points gives you the benefits of a specific and considered design, but developing responsively means your site also works outside of those breakpoints and caters to a wider and ever‑changing audience.

There are also handy tricks you can take from adaptive web development, such as detecting mobile users and displaying a phone icon, or detecting location and adding international calling codes for users outside of the UK ‑ something I was very pleased to include in my previous version of this site!