Responsive Web Design Best Practices That Still Matter
Responsive design is twenty years old and most sites still get it wrong in the same five ways. Here is what actually holds up across devices.
Everyone builds responsive sites now. Plenty of them still break — a table that forces horizontal scrolling, a menu that cannot be closed, a hero that eats the whole screen on a phone. Responsive is not a checkbox you tick once; it is a set of habits. These are the ones that have held up for me across hundreds of builds.
Design from the smallest screen up
Starting at desktop and squeezing down produces compromises. Starting at 375px forces the real decision — what is essential — and everything you add on larger screens is then a deliberate upgrade rather than a rescue. This is the whole argument of mobile-first design, and it has not stopped being true.
Let content pick your breakpoints
Do not inherit breakpoints from a device list that goes stale every eighteen months. Widen the browser slowly and add a breakpoint at the exact width where the layout starts to look wrong. You will usually end up with three or four, not nine.
Use fluid type and spacing
Fixed font sizes stepping between breakpoints leave awkward middle widths. A clamp()-based scale handles every width in between with one declaration:
font-size: clamp(1.75rem, 4vw + 0.5rem, 3.5rem);
Do the same for section padding. Most "it looks odd on my tablet" reports are spacing that never got a tablet value.
Reserve space for images and embeds
Always set width and height (or an aspect-ratio) on images, videos, and iframes. Without it the browser cannot reserve space, content jumps as assets arrive, and your layout shift score suffers — one of the three metrics in Core Web Vitals.
Serve the right image, not the biggest one
A 2400px hero on a phone wastes bandwidth and battery. Use srcset and sizes so each device downloads what it needs, and ship modern formats. Images are still the single largest cause of slow pages — see the ten performance mistakes I see most.
Design for touch, not just for width
A narrow viewport usually means fingers. Give tap targets at least 44 by 44 pixels, keep them apart, and never hide a primary action behind hover — there is no hover on a phone. Test the thumb zone: the bottom third of the screen is comfortable, the top corners are not.
Handle the hard components deliberately
- Tables: wrap them in a scrolling container, or restack into cards below your smallest breakpoint.
- Navigation: a drawer is fine, but it needs a visible close control, focus trapping, and Escape to dismiss. More in the navigation design guide.
- Long forms: single column, always. Two-column forms are a mobile disaster and barely help on desktop.
Respect user settings
Honour prefers-reduced-motion, do not disable pinch zoom, and let text scale when someone has increased their default size. These take minutes and are part of the baseline covered in why accessibility is not optional.
Test on real devices
Browser dev tools emulate dimensions, not reality — not sluggish scroll, not a notch, not an on-screen keyboard covering the field you are typing into. Keep one mid-range Android around and check every build on it. That single habit catches more issues than any emulator.
Site falling apart on mobile? Get in touch and I will run through it with you.
