Content Marketing Glossary

  • What is Responsive Design?

What is Responsive Design?

Responsive Design

Responsive Design is an approach to web design in which a single codebase serves all screen sizes - desktop, tablet, mobile - by adapting its layout fluidly rather than by serving separate fixed-size pages. The term was introduced by Ethan Marcotte in a 2010 A List Apart article, and it replaced the earlier pattern of maintaining a separate “m.example.com” mobile site. Responsive design is now the default assumption for nearly every web project; the interesting decisions are about how to do it well, not whether to do it.

The three technical foundations

Fluid grids. Layout columns sized in percentages (or relative units like fr in CSS Grid) rather than fixed pixels. When the viewport shrinks, grid columns shrink proportionally.

Flexible images and media. Images that scale within their container using max-width: 100%, paired with srcset for serving appropriately sized assets. Avoids the old problem of a 1200px desktop image forcing horizontal scroll on mobile.

Media queries. CSS rules that apply conditionally based on viewport width, device orientation, or pixel density. Break layouts at specific thresholds - typical breakpoints are 480px, 768px, 1024px, 1280px - though modern practice prefers content-driven breakpoints over device-driven ones.

Mobile-first as the default

Responsive design has evolved toward a mobile-first methodology: write the mobile styles as the default, then layer desktop-specific styles via media queries. The reasons:

Mobile is the majority. For most web audiences, mobile traffic is 50–70% of total sessions. Designing desktop-first and then “cramming it down” to mobile produces worse mobile experiences than the reverse.

Progressive enhancement matches capability. Mobile devices have smaller screens, slower networks, and more variable inputs. Starting from those constraints and then loosening them for desktop is a better discipline than starting unconstrained and then tightening.

Performance budgets are tighter on mobile. A mobile-first codebase tends to ship less unused CSS and less oversized imagery than a desktop-first one. See mobile-first design for the full methodology.

Common failure modes

Four problems that trip up responsive implementations:

Breakpoint over-proliferation. A site with 14 media-query breakpoints becomes ungovernable. Every layout change has to be verified across 14 viewport widths. Three to five well-chosen breakpoints, driven by where content actually needs to reflow, is a sustainable number.

Content parity loss at smaller sizes. Some teams strip content at mobile widths to “simplify the experience”. This breaks the core responsive premise, which is that the same content adapts to different screens. Mobile users deserve the same information as desktop users, presented accessibly.

Touch-target sizing. Buttons that are clickable on desktop are often too small to tap on mobile. Standard recommendation: 44×44 CSS pixels minimum for tap targets. Many responsive designs pass visual QA but fail usability testing on this alone.

Performance regression. Responsive images and media queries can reduce payload, but badly implemented responsive sites ship full-size assets everywhere and use JavaScript to reflow layouts. The result is a mobile experience slower than a fixed “m.example.com” would have been.

Responsive versus adaptive versus separate mobile

Three alternative approaches worth distinguishing:

Responsive design. One codebase, fluid layout, continuous adaptation to any viewport. Default for most sites.

Adaptive design. One codebase, but specific fixed layouts at specific breakpoints (e.g., 320, 768, 1024). More predictable for complex layouts where fluidity causes problems. Less popular today.

Separate mobile site. A distinct m.example.com codebase optimised for mobile. Legacy pattern; creates SEO and content duplication issues. Mostly retired except in a few high-traffic corners of the web (some news and e-commerce sites retain it).

A quick sanity check for responsive implementations

Four tests any responsive site should pass:

Resize the browser window slowly. Layouts should reflow smoothly rather than jumping between rigid breakpoints.

Test on a real device. Browser dev-tools emulate, but don’t fully replicate, touch behaviour and mobile network conditions.

Test with actual content. A layout that works with placeholder Lorem ipsum often breaks with real long titles, extreme edge-case data, or non-English text.

Measure the Core Web Vitals. Mobile LCP, INP, and CLS are the objective measures of whether the responsive work is helping or hurting the user experience.

Related terms

Here's how we can help you

Want a glossary just like this?

Get in touch for our DFY glossary service.