Adaptive design means building several fixed-width layouts ahead of time and serving whichever one fits the visitor’s device or screen width. A responsive layout stretches to fit. An adaptive site snaps to the closest layout somebody actually designed.
Teams reach for it when a phone and a desktop need genuinely different layouts or flows, not just the same page scaled down.
Google doesn’t care what the design is called. It sorts sites by what they serve. The same HTML on one URL counts as responsive design, and different HTML per device counts as dynamic serving or separate mobile URLs (Google Search Central, updated December 2025).
Only that second group needs the Vary: user-agent header, so a site’s indexing requirements come from how it delivers its layouts, not from what it calls them.
What Is Adaptive Design?
The layout never stretches to fit. It jumps from one designed size to the next, and that is the sharpest break from responsive design, where a single fluid layout runs across every width.
A small set of fixed layouts, usually one per device class, sits behind a detection step that picks the right one before the page renders. You get full design control inside each layout. You also get more templates to maintain, and that bill always arrives eventually.
IxDF notes that most adaptive designs are retrofits of existing sites, built so an older site works across several devices.
Clinical trial researchers use the same words for a method that modifies a study as data accumulates. That’s a separate subject and stays out of this article.
Adaptive Web Design as Progressive Enhancement
Aaron Gustafson published a book called Adaptive Web Design in 2011 (Easy! Designs), and it’s about something else.
In a 2012 UIE interview, Gustafson said he used the phrase as a synonym for progressive enhancement, a build method that starts from working markup and layers CSS and JavaScript on top.
So two meanings circulate. This article uses the one that UX glossaries and comparison guides use, which is layout switching.
How Adaptive Design Works
A request comes in, the site works out the device or its screen width, picks the closest pre-built layout and sends back that layout’s HTML and CSS.
Detection reads either the user agent or the viewport width, and where it runs decides most of the trade-offs.
Server-side and Client-side Detection
On the server, the User-Agent request header gets matched against a device database such as WURFL or DeviceAtlas. The URL stays the same while the HTML changes. Google Search Central calls this dynamic serving, and it relies on user-agent sniffing and the Vary: user-agent header. The weak spot is the database itself, which has to keep up as new devices ship (Redefine Web).
Client-side detection hands the job to JavaScript, which measures the screen width and applies a class for the matching layout. Restive.js, a jQuery plugin, works against declared breakpoint ranges and adds the class you declared for the matching range. In the project’s own example, a viewport between 241 and 320 px receives the 320-c class.
The catch is timing. A script has to run before the right layout appears, so a slow script delays it.
Why User-Agent Strings Alone No Longer Work
Chrome began shipping a reduced Android user agent with version 110 in February 2023. The Chromium project’s rollout log shows it reaching 100% of Android clients on version 110 and above on May 11, 2023.
The reduced string reports a fixed Android 10 and a device model of K, so the real model and Android version are gone (Chrome Privacy Sandbox documentation).
User-Agent Client Hints replace it. Sec-CH-UA-Mobile is a boolean (?1 for mobile, ?0 for not) and a low entropy hint, which means browsers send it by default. Model and form factor are high entropy hints, so the server has to request them through Accept-CH, per MDN.
MDN also marks Sec-CH-UA-Mobile as not Baseline, because it doesn’t work in some of the most widely used browsers. Google’s dynamic serving guidance still describes user-agent sniffing, yet the string Chrome sends no longer carries the device model.
Class-level checks still work. “Mobile or not” can be answered through the Mobile token and Sec-CH-UA-Mobile. Model-level targeting can’t.
So detect the device class from both signals, and fall back to a default layout when neither is conclusive.
Common Adaptive Design Breakpoints
No standard breakpoint set exists. Sources list anywhere from 3 to 6 layouts, and even the six-width sets disagree.
Matchbox Design Group uses 1600, 1200, 960, 760, 420 and 320 px. The Responsive-Web course notes on GitHub run 320, 480, 760, 960, 1200 and 1600 px, which swaps 420 for 480. UXPin (2026) goes with 320, 480, 768, 1024, 1200 and 1440 px. InVision keeps it to 3 layouts, one each for desktop, tablet and phone.
All three width sets include 320 and 1200. Everything else varies, so copying a list means inheriting someone else’s device mix.
Pick widths from your own analytics instead. InVision’s advice is to check whether traffic is dominated by a few devices or resolutions, because a long tail of screen sizes points toward a fluid layout.
Start with the narrowest layout, as mobile-first design recommends (Webflow), so the phone version doesn’t turn into an afterthought.
Between two breakpoints the layout does not change (Redefine Web), so a screen gets the nearest designed width.
Responsive frameworks publish breakpoints too. Bootstrap 5 documents 576, 768, 992, 1200 and 1400 px, but those mark where a fluid layout reflows, not where a separate template takes over.
Adaptive Design vs Responsive Design
Detection picks the layout in adaptive design, from a handful of fixed ones. A responsive site has one fluid layout, and the browser does the adjusting.
| Criterion | Adaptive design | Responsive design |
|---|---|---|
| Layout | Fixed layouts per device class | One fluid layout |
| Chosen by | Detection on the server or in a script | The browser, through a fluid grid and media queries |
| URLs | One URL, or separate mobile URLs | One URL |
| Upkeep | One template per layout, tested per version | One codebase |
| Unlisted screen sizes | Nearest designed layout, which may fit badly | Grid adjusts to any width |
Ethan Marcotte coined responsive web design in a May 25, 2010 article on A List Apart, defining it through a fluid grid system, flexible images and media queries.
The real boundary between the two is behavior between breakpoints, not tooling. A CSS-only layout that jumps at fixed pixel values through media queries counts as adaptive (BrowserStack), even with no server detection involved.
Most of the cost difference sits in the Upkeep row. Every added layout is one more template to design, test and keep in step with the rest.
Does Adaptive Design Load Faster?
It can, but the evidence is thin. Each device receives only the assets built for it, so a phone gets a phone layout and never downloads desktop-sized markup or images. The agencies that make the speed claim (Matchbox Design Group, Mailchimp) describe it as a tendency, not a measured result.
Responsive sites that manage their assets well still load quickly (Relia Software). Server-side detection adds infrastructure and potential latency (Redefine Web), and Client Hints return device details on the second request, which can add delay (51Degrees).
HTTP Archive’s Web Almanac 2025 puts the median mobile home page at 2,559 KB against 2,862 KB on desktop in July 2025, only 303 KB lighter. The 2024 edition showed a similar gap: 2,311 KB on mobile against 2,652 KB on desktop in October 2024.
Median home page images weigh 911 KB on mobile and 1,058 KB on desktop in the 2025 data. The 2024 Almanac’s authors said responsive image serving could explain the lighter mobile figure.
That mechanism is the srcset attribute, which lists candidate image files so the browser picks one by screen width and pixel density. It works inside a single fluid layout, so the byte savings need no adaptive templates at all.
Measure instead of assuming. An LCP of 2.5 seconds or less at the 75th percentile counts as good (web.dev, updated September 2025), and each layout can have its own largest element, so each needs its own run.
Faster is a hypothesis to test per site, not a property of the approach.
How Google Handles Adaptive Design Sites
An adaptive site that detects the device falls under dynamic serving (one URL, different HTML) or separate mobile URLs in Google’s terms, and Google indexes the mobile version either way.
A CSS-only adaptive layout serves the same HTML on one URL, so it counts as responsive design. All of this comes from Google Search Central’s mobile-first indexing guide, last updated December 2025.
| Configuration | URLs | What Google needs from you |
|---|---|---|
| Responsive design | One URL, same HTML | No extra annotations |
| Dynamic serving | One URL, different HTML | Vary: user-agent header |
| Separate mobile URLs | Desktop and mobile URLs | Canonical to desktop, alternate to mobile, user-agent and Vary headers for redirects |
Google recommends responsive design because it’s the easiest pattern to implement and maintain. Some agency posts, Matchbox Design Group’s among them, say Google rewards responsive sites, but the passage in Google’s guide gives no ranking reason.
Google crawls all sites with Googlebot Smartphone after July 5, 2024, and sites that do not work on mobile are no longer indexed (Google Search Central blog, June 2024).
Primary content and headings have to match between versions. The design may differ, the content may not. The same goes for structured data, and if you have to prioritize, start with Breadcrumb, Product and VideoObject. Robots meta tags need to agree too, so no noindex lands on the mobile version alone. Titles and meta descriptions round it out.
A phone layout can move content into tabs or accordions. Removing it is different: Google says to expect traffic loss when the mobile version carries less than the desktop one.
With dynamic serving, the same URL returns different HTML per device. Google’s 2012 Webmaster Central post strongly recommends the Vary: user-agent header, because it tells caching servers and Google’s algorithms that the response changes with the user agent.
DeviceAtlas cites google.com itself as an example. Every device sees the same URL, and device detection decides the response.
Separate mobile URLs bring their own ways to fall out of the index. If many desktop URLs redirect to the mobile home page, those pages get dropped. An error page on mobile where desktop serves content removes the page too. And mobile URLs with # fragments are, most of the time, not indexable.
Where Adaptive Design Breaks Down
Adaptive sites tend to fail in a few predictable places, and the table sums them up before the details.
| Failure mode | Trigger | Mitigation |
|---|---|---|
| New device shapes | Foldables, ultrawide monitors | Revisit device classes |
| Layout drift | Same tweak repeated per template | Share components across layouts |
| Stale device data | Database not refreshed | Automate updates |
| Fragmented caches | Raw Vary: user-agent | Normalize to device classes |
New Device Shapes
Elementor and Redefine Web say foldables and ultrawide monitors need new layouts or updated breakpoints. WildNet Edge says the opposite, that adaptive design handles emerging devices well because it targets device types.
The likely reason for the split is what each side keys the layout to. Width-keyed layouts inherit the gap problem, while type-keyed layouts depend on the detection database knowing the new device.
Layout Drift
A small design tweak has to be repeated in every version, and the versions drift apart over time (ProfileTree). Anyone who has fixed the same button padding in four templates knows how this goes.
Stale Device Data
Server-side detection keeps its device database in your backend, so refreshing it is your job. ScientiaMobile publishes a WURFL snapshot weekly and DeviceAtlas updates its data file daily.
ScientiaMobile measures the pace of change as a user-agent half-life. In its study, only 50% of the user-agent strings seen today were still in use after 7 months, and only 38% after 12 months. That figure tracks how fast real-world user agents turn over, not the accuracy of any one database, but it shows why a device database that isn’t refreshed falls behind.
Fragmented Caches
Vary: user-agent tells a CDN to store one copy per distinct user-agent string, which Transparent Edge’s documentation says makes the cache ineffective.
That sets Google’s guidance against CDN documentation. Google asks for the header, and CDN vendors warn that raw user-agent variation destroys hit rates.
Normalizing the header to device classes before the cache lookup satisfies both. ModPageSpeed’s CDN guide notes that CloudFront exposes mobile, tablet and desktop viewer headers for exactly this purpose.
When Should You Use Adaptive Design?
Use it when a small, known set of device classes needs different content or flows and your team can maintain one template per class. Otherwise, start with a responsive layout.
Check your analytics first. If a few devices or resolutions dominate, adaptive is worth considering (InVision). Then ask whether each class needs different content or interaction, as opposed to the same page rescaled (UXPin). Last, ask whether you can design, test and keep one template per class current.
If the first answer is no, the long tail of screen sizes favors a fluid layout. If the second is no, you’re paying for templates that differ only in width.
Uxcel’s examples show what different flows look like. A tablet layout can use a split screen and a phone layout can simplify the navigation, and enterprise software might pair a detailed desktop dashboard with a lean mobile interface for field staff.
Older devices are the other documented case. Idealogic’s glossary names legacy devices and browsers as a reason to choose adaptive design, and Wikipedia’s entry (flagged since 2018 as needing an update) says the approach is typically seen where sites target non-smart mobile devices and obsolete smartphones.
| Pros | Cons |
|---|---|
| Tight control over each layout | One template per layout to maintain |
| Content and flows can differ by device | Detection has to stay accurate |
| Works for devices that cannot run fluid layouts | Device shapes outside the set fit badly |
Cost to Build and Maintain
Layout count drives most of it, since every class gets designed, built and tested on its own. Detection adds more if you buy a commercial device database such as DeviceAtlas or WURFL, which brings a license or subscription.
WURFL is no longer released under an open source license. ScientiaMobile’s FAQ points users who want an economical option to WURFL Cloud Lite or WURFL.js Lite. No source publishes a cost per layout, so estimate from your own design and test hours.
The Hybrid Option
Sizzy and UXPin both describe the same compromise: a responsive fluid base with adaptive adjustments at key breakpoints.
The base gives smooth scaling, and the adjustments give tighter control where one device class needs different content or interaction. For most sites I’d call that the better starting point over a full set of fixed templates.
How to Implement Adaptive Design
Detection, headers and parity are where builds most often go wrong, so give those steps extra time.
- Export device and resolution data from analytics.
- Group devices into classes and set one breakpoint per class.
- Design one wireframe per class, built from the same content list.
- Add detection, either server-side or script-based, with a default layout for requests that match no class.
- Vary every asset per class, meaning the HTML, CSS, JavaScript bundles and images.
- Send Vary: user-agent on any URL that returns different HTML, and normalize the cache key to device classes.
- Check that content, structured data, robots meta tags, titles and meta descriptions match across versions.
- Test on devices. Emulate first, then use a real phone and tablet, and run Lighthouse on each layout.
- Schedule reviews of analytics and device data on a fixed cycle.
Draw each layout as a wireframe before any code, so the layouts differ in arrangement and not in what they say.
Varying the markup alone isn’t enough. In an older Google+ post reported by Search Engine Roundtable, Google’s Pierre Far named JavaScript, CSS and images as the places dynamic serving sites most often go wrong.
The same Google+ series advised treating Googlebot like any other device. If it identifies itself as an iPhone, serve it the iPhone layout.
Chrome’s device mode approximates a phone from a laptop, and its documentation says mobile CPU architecture is not emulated. For the most reliable results, run the page on a real mobile device.
Device mode can set the user agent string and User-Agent Client Hints, so detection logic can be tested by switching them. In Search Console, the URL Inspection tool shows the rendered page as Google sees it, which is where missing mobile content shows up.
Adaptive Design FAQ
How can you tell whether a site uses adaptive or responsive design?
Resize the browser window slowly. A layout that flows at every width is responsive, while one that jumps between fixed widths with no smooth transition is adaptive (UXPin).
A layout that never moves on resize can still be adaptive. Switch the user agent in DevTools and reload to see whether the server returns a different layout.
Which well-known sites use adaptive design?
UXPin’s 2026 comparison names Amazon and IHG as sites using adaptive techniques. It points to search and one-tap purchasing on Amazon’s mobile experience, and to an IHG booking flow that changes significantly between mobile and desktop.
That label is an outside observation, not a statement from either company.
Is adaptive design still used in 2026?
Yes, though less often than responsive design, which UXtweak calls the more commonly adopted approach.
Google’s mobile-first indexing guide, updated December 2025, still documents dynamic serving and separate mobile URLs as supported configurations.
Does adaptive design apply to mobile apps?
It does. Uxcel defines it as a web and app approach that delivers different layouts based on the detected device or screen size.
App design systems use the same breakpoint logic. Material Design’s original responsive UI guidance, for example, changes layouts at 480, 600, 840, 960, 1280, 1440 and 1600dp.
When to Move From Adaptive Design to Responsive Design
Move when your analytics show more device classes than you maintain templates for, or when each design change has to be repeated in every version.
Start by matching mobile content to desktop content. Then merge the templates into one fluid layout, and remove detection and the Vary: user-agent header last.
Parity goes first because Google indexes the mobile version, and a content gap there costs traffic during the move.
The header goes at the end. Caches keep per-device copies until every device receives the same HTML, and Vary is what tells them the response changes by user agent.
What you give up is per-device control over content and flows, which is the reason many teams chose adaptive design in the first place. Type then has to scale with the fluid layout, a job for responsive typography.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- How to Insert Image in Figma With Ease - November 3, 2026
- How to Download Figma Files Fast and Free - October 30, 2026
- Figma Keyboard Shortcuts That Will 10x Your Speed - October 25, 2026
