"Responsive" used to mean a handful of breakpoints and a hamburger menu. In 2026 it means something stricter: one design system that adapts to any screen, any input and any connection — without a separate "mobile site" hiding behind it.
breakpoints were never the point
Designing for three fixed widths — phone, tablet, desktop — made sense when there were three kinds of device. There aren't anymore. Foldables, ultrawides, in-car displays and split-screen multitasking mean the viewport is a continuum, not a set of buckets. The modern approach is intrinsic design: components that know their own minimum and maximum size and lay themselves out from the content out, using CSS grid, flexbox, clamp() and container queries. You stop asking "how wide is the screen?" and start asking "how much room does this component have?"
fluid grids and type that scales
A fluid grid sizes columns in fractions, not pixels, so the layout breathes between breakpoints instead of snapping. Type scales the same way — a single clamp() rule gives you a headline that is large on a monitor and still readable on a phone, with no media queries at all. The result is fewer rules, fewer edge cases, and a layout that looks deliberate at every width, not just the three you tested.
the order that matters
- content first — structure the HTML so it reads top to bottom with no CSS at all. If it makes sense unstyled, it will reflow cleanly.
- mobile up — design the smallest screen first, then add room as it becomes available. Adding is easier than taking away.
- components, not pages — a card, a nav, a form. Each owns its own responsive behaviour and works wherever it lands.
performance is part of "responsive"
A layout that fits the screen but takes eight seconds to load isn't responsive in any meaningful sense. Real responsiveness includes a performance budget: a hard ceiling on page weight and on the Core Web Vitals Google uses as ranking signals — Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. In practice that means modern image formats (AVIF, WebP) served at the right size for the device, fonts that don't block rendering, and JavaScript shipped only where it earns its place.
accessible by default
The same discipline that makes a site responsive makes it accessible: semantic HTML, real focus states, sufficient colour contrast, and layouts that survive a user zooming to 200% or navigating by keyboard alone. It is not an add-on at the end; it is the cheapest insurance you will ever buy, and increasingly a legal expectation.
what good looks like
- one codebase that serves every device — no m. subdomain, no app/desktop drift.
- fluid everything — grids, spacing and type scale continuously, with container queries for the components that need it.
- a budget you enforce — weight and Core Web Vitals checked in the build, not discovered in production.
- accessible from the first commit — semantics and contrast baked in, not retrofitted.
Done well, responsive design stops being a phase of the project and becomes a property of the system — the brand holding its shape on every screen it lands on.