Responsive Web Design in 2026: What's Changed and What Matters

When Ethan Marcotte coined the term “responsive web design” back in 2010, the challenge was relatively simple: make websites work on phones as well as desktops. Fifteen years on, the landscape is fundamentally different. We’re designing for foldable phones, ultra-wide monitors, tablets used as point-of-sale systems, in-car browsers, and everything in between. The tools have improved enormously, but so have the expectations.

Here’s what actually matters when building responsive websites today, based on what we’re doing in production rather than what looks good in conference talks.

Container Queries Have Changed Everything

Media queries served us well for years, but they always had a fundamental limitation: they respond to the viewport, not to the space a component actually occupies. If you’ve ever built a card component that needs to look different in a sidebar versus a main content area, you know the pain. You’d end up with modifier classes, JavaScript-based resize observers, or just accepting that the layout would be slightly wrong in certain contexts.

Container queries solve this properly. A component can now respond to the size of its parent container:

.card-container {
  container-type: inline-size;
  container-name: card;
}

@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 200px 1fr;
    gap: 1.5rem;
  }
}

@container card (max-width: 399px) {
  .card {
    display: flex;
    flex-direction: column;
  }
}

Browser support is now excellent across all modern browsers, and we’ve been using container queries in production since late 2024. The impact on component reusability is significant — you write a component once and it genuinely adapts to wherever it’s placed.

We still use media queries for page-level layout decisions (switching between single and multi-column layouts, adjusting overall page padding), but component-level responsiveness is now handled almost entirely with container queries.

CSS Grid and Flexbox: Use Both, Use Them Properly

There was a period where developers treated Grid and Flexbox as competing technologies. They’re not. They solve different problems and work beautifully together.

Use CSS Grid for:

• Page layouts (header, sidebar, main, footer)
• Card grids with consistent sizing
• Any two-dimensional layout where you need control over both rows and columns

Use Flexbox for:

• Navigation bars
• Button groups and inline element alignment
• Single-axis distribution of space
• Centering content (still the simplest approach)

A pattern we use constantly is Grid for the overall page structure with Flexbox inside individual components:

.page {
  display: grid;
  grid-template-columns: 1fr min(65ch, 100%) 1fr;
  padding-inline: 1rem;
}

.page > * {
  grid-column: 2;
}

.page > .full-width {
  grid-column: 1 / -1;
}

This gives you a centred content column with the ability to break out to full width for images or feature sections. It’s clean, requires no magic numbers, and adapts to any screen width.

Fluid Typography That Actually Works

Fixed font sizes at different breakpoints create jarring jumps as the viewport changes. Fluid typography scales smoothly using clamp(), and it’s now our default approach:

:root {
  --font-size-base: clamp(1rem, 0.9rem + 0.5vw, 1.2rem);
  --font-size-lg: clamp(1.25rem, 1rem + 1vw, 1.75rem);
  --font-size-xl: clamp(1.75rem, 1.25rem + 2vw, 3rem);
  --font-size-sm: clamp(0.875rem, 0.85rem + 0.15vw, 0.95rem);
}

The clamp() function takes a minimum, a preferred value (usually viewport-relative), and a maximum. Text scales fluidly between the min and max, which means it looks right on a phone and right on a widescreen monitor without a single media query.

We apply the same principle to spacing:

:root {
  --space-md: clamp(1rem, 0.75rem + 1vw, 2rem);
  --space-lg: clamp(1.5rem, 1rem + 2vw, 4rem);
}

The result is a layout that breathes naturally at every size rather than snapping between fixed states.

Image Optimisation Is Not Optional

Images remain the biggest performance bottleneck on most websites. The tooling has improved, but you still need to be deliberate about it.

What We Do on Every Project

1. Serve modern formats — WebP as the default, AVIF where browser support allows, with JPEG/PNG fallbacks via the <picture> element
2. Responsive images with srcset — serve appropriately sized images rather than scaling down a 2400px original on a 375px phone screen
3. Lazy loading — native loading="lazy" on all images below the fold
4. Explicit dimensions — always set width and height attributes (or use aspect-ratio in CSS) to prevent layout shift
5. Compression — we run everything through a build-time pipeline; most images compress by 60-80% without visible quality loss

<picture>
  <source srcset="/images/hero-800.avif 800w, /images/hero-1600.avif 1600w"
          type="image/avif" sizes="100vw">
  <source srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
          type="image/webp" sizes="100vw">
  <img src="/images/hero-800.jpg" alt="Project showcase"
       width="1600" height="900" loading="lazy"
       decoding="async">
</picture>

It’s more markup than a simple <img> tag, but the performance difference is substantial, particularly on mobile connections. Many of our clients are based in rural Wales where mobile signal can be patchy at best — optimisation isn’t academic here, it’s essential.

Mobile-First vs Desktop-First: It Depends

The “mobile-first” mantra has been gospel for years, and for good reason — it forces you to prioritise content and strip away unnecessary complexity. But in practice, we don’t dogmatically follow one approach.

Mobile-first makes sense when:

• The primary audience is on mobile (consumer-facing sites, local businesses)
• Content needs to be ruthlessly prioritised
• You’re building a progressive enhancement

Desktop-first (or “content-first”) makes sense when:

• The application is primarily used on desktop (enterprise dashboards, admin panels)
• Complex data tables and multi-panel layouts are central to the experience
• You’re working with an existing desktop application being made responsive

What we always do is design both layouts early. Whether we code mobile-first or desktop-first, we ensure both breakpoints are considered from the start. The worst responsive sites are those where one layout was clearly an afterthought.

Core Web Vitals Still Matter

Google’s Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — directly affect search rankings. They also affect how your site feels to use, which matters more than any SEO consideration.

The responsive design decisions that most impact these metrics:

• LCP: Don’t lazy-load your hero image. Preload it. Use appropriately sized images so the browser isn’t downloading unnecessary bytes.
• INP: Keep your JavaScript lean. Heavy client-side frameworks on pages that don’t need interactivity will hurt INP. Consider server-rendered HTML with progressive enhancement.
• CLS: Always define dimensions for images and embedded content. Use min-height on containers that load dynamic content. Avoid inserting content above the fold after page load.

We test every project against Core Web Vitals using Lighthouse and real-world data from Chrome UX Report. It’s part of our standard quality process, not an afterthought.

Dark Mode Is a Feature, Not a Fad

User preference for dark mode has grown steadily, and supporting it is now straightforward with prefers-color-scheme:

:root {
  --bg: #ffffff;
  --text: #1a1a2e;
  --surface: #f1f5f9;
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg: #0f172a;
    --text: #e2e8f0;
    --surface: #1e293b;
  }
}

The key is designing with CSS custom properties from the start. Retrofitting dark mode onto a site that uses hard-coded colours throughout is tedious and error-prone. Plan for it from day one, even if you don’t implement it immediately.

What We Tell Clients

Responsive design isn’t a feature you add — it’s how websites should be built. When we scope a project, responsiveness is baked into every estimate because it’s not optional. A website that doesn’t work well on mobile in 2026 is a broken website.

The good news is that the CSS tools available today make responsive design significantly easier than it was five years ago. Container queries, fluid typography with clamp(), and native lazy loading have removed much of the complexity that used to require JavaScript workarounds or preprocessor gymnastics.

The fundamentals haven’t changed, though: understand your audience, prioritise your content, test on real devices, and measure performance continuously. The technology evolves, but those principles remain constant.