Responsive vs Adaptive Design: Building for Every Screen
Key takeaway
Responsive — one codebase, fluid layouts, breakpoints driven by content — is the right default for almost every site. Adaptive or separate mobile builds are justified only when the mobile task genuinely differs from the desktop one, and they double the maintenance cost forever.
Mobile is now the majority of traffic for most sites, and the question is no longer whether to support it but how. The two approaches differ in where the decision about layout is made.
The distinction
- Responsive — one set of markup and styles that reflows fluidly across any width. The browser decides what it gets.
- Adaptive — predefined layouts for specific device classes, selected by detection, often server-side. The server decides what it sends.
- Separate mobile site — a distinct build on its own URLs. Largely superseded, and a maintenance and SEO burden.
Why responsive is the sensible default
- One codebase, one content model, one deployment — every change happens once.
- It handles devices that don't exist yet, along with resized windows and split-screen use.
- No device detection to maintain, which is a permanently losing battle as new devices appear.
- Search engines see one URL with one set of content, which avoids an entire class of duplication problem.
Doing it well
- Set breakpoints where the content stops working, not at the widths of specific popular devices.
- Design mobile-first: start with the narrow layout and add as space allows. Removing from a desktop design produces cramped, compromised small screens.
- Serve appropriately sized images rather than shrinking large ones — layout responsiveness without image responsiveness just wastes bandwidth.
- Touch targets large enough to hit reliably, with real spacing between them.
- Test on actual devices on a real mobile connection. A resized desktop browser hides both performance and ergonomic problems.
When adaptive is defensible
If the mobile user's task is genuinely different — a field engineer's job list versus an office reporting interface — then serving a different experience is a product decision rather than a layout one, and may justify separate builds. The same applies where mobile performance demands radically less markup and script than the desktop site carries. In both cases, be clear you're accepting permanent duplicate maintenance, and make sure content still comes from one source.