Responsive Web Design in Practice
Resizing a desktop browser is not the same as holding a phone. A layout can look tidy in an emulator and still clip a headline on a real device, jump under your thumb while it loads, or force a sideways scroll on a tablet. It matters for search, too: Google indexes and ranks pages using their mobile version.
Whether you hire a team for web design & development services or maintain the site in-house, the same handful of mistakes keeps turning up. Here are seven of them, what they cost users, and the fixes developers typically reach for.
Responsive design is an important consideration throughout the software development process, as developers must ensure that applications and websites work reliably across different devices, screen sizes and user environments.
Table of Contents
1. Breakpoints tied to devices instead of content
Setting breakpoints at “phone,” “tablet” and “laptop” widths ages quickly, because screen sizes keep multiplying. Widths between your chosen targets get awkward layouts, like a three-column grid squeezed until words break mid-line.
The fix: start with the smallest layout, then drag the viewport wider and add a media query only where the content starts to strain. Fluid sizing cuts the number of breakpoints you need. clamp(1rem, 0.9rem + 0.5vw, 1.25rem) scales type smoothly, and repeat(auto-fit, minmax(16rem, 1fr)) lets a grid decide its own column count. For a component that appears in both a sidebar and a main column, container queries let it respond to the space it actually has.
2. A missing or misused viewport tag
Without <meta name=”viewport” content=”width=device-width, initial-scale=1″>, mobile browsers lay the page out at a virtual desktop width and shrink it, so your media queries never behave as intended.
The opposite error is just as common. Adding user-scalable=no or maximum-scale=1 to suppress a zoom glitch stops people with low vision from enlarging text. WCAG’s Reflow criterion expects content to work at a 320 CSS pixel width without two-dimensional scrolling.
The fix: keep the standard tag and nothing more, and fix the glitch itself. Then test at 320px, or at 400% zoom on a desktop, which the W3C describes as equivalent.
3. Fixed widths and the accidental horizontal scroll
The usual culprits are a hard-coded width: 600px, an embedded iframe, a wide table, or a long unbroken URL.
The fix: give media max-width: 100% and height: auto, and prefer max-width or min() over fixed pixel widths. Flex and grid children default to a minimum size of their content, so long text can push a layout wider than the screen; min-width: 0 or overflow-wrap: anywhere usually resolves it. Wrap wide tables in an overflow-x: auto container so only the table scrolls.
4. Images that are too heavy, or that push content around
Sending a 2,000-pixel hero image to a small phone wastes bandwidth. Images with no declared dimensions create a second problem: they arrive late and shove the text down. That is layout shift. Google’s web.dev guidance treats a Cumulative Layout Shift of 0.1 or less as good and anything above 0.25 as poor.
The fix: use srcset and sizes so the browser picks a suitable file, and reserve <picture> for art direction, such as swapping a wide landscape crop for a tighter portrait on phones. This belongs in HTML rather than CSS or JavaScript because the browser starts fetching images before it has parsed either. Add width and height attributes, or CSS aspect-ratio, so space is reserved before the file loads.
5. Tap targets built for a mouse
Tiny icon links, tightly stacked footer links and close buttons crammed into modal corners lead to mis-taps. WCAG 2.2 (criterion 2.5.8, level AA) sets a floor of 24 by 24 CSS pixels for pointer targets, with an exception for well-spaced smaller ones. Apple and Google’s own platform guidelines ask for more, commonly quoted at around 44 to 48 pixels.
The fix: add padding rather than enlarging the icon. A 20px icon can sit inside a 44px tappable area. Space neighbouring links apart, and never hide essential actions behind hover; touch screens have none.
6. Using 100vh for full-screen sections
Picture a hero section set to height: 100vh. On desktop it fits perfectly. On a phone, the call-to-action button slides beneath the browser toolbar, because vh ignores toolbars that expand and retract as people scroll.
The fix: the newer viewport units. svh sizes to the visible area with toolbars expanded, and dvh follows them as they move. Declare 100vh first as a fallback, then 100dvh. Use min-height rather than height so larger text sizes don’t clip the content.
7. Hiding content on mobile
Trimming a page for small screens is tempting, but Google’s mobile-first indexing guidance says the mobile version should carry the same primary content as desktop, with matching structured data. Accordions and tabs are fine as long as the content stays equivalent. Content that loads only after a swipe or click is risky, since Google won’t trigger those interactions.
The same attention to mobile usability is important when building applications for smartphones. Understanding mobile app development provides additional context on designing digital experiences around mobile users and their interactions.
The fix: restructure rather than remove. Collapse, reorder and simplify the presentation while keeping the text and markup intact.
How developers catch these before users do
Chrome DevTools’ device mode is a quick first pass, but emulation does not reproduce real toolbar behaviour, touch input or the speed of a mid-range handset. Test on at least a couple of physical devices. Zoom to 400%, tab through the page with a keyboard, and throttle the network.
Including responsive testing, accessibility checks and performance validation in the software development process helps teams identify usability issues before a website reaches production.
Lab scores only tell part of the story. The Core Web Vitals report in Search Console and field data in PageSpeed Insights reflect what real visitors experience.
Where to start
Responsive behaviour works best as a habit, not a late layer. On WordPress, custom WordPress development lets templates and components be planned for small screens from the start rather than patched later. And since mobile experience feeds into how pages are measured and crawled, it is worth pairing that work with technical WordPress SEO services that cover Core Web Vitals and crawlability.
For businesses building or maintaining WordPress websites, choosing the right development approach can make responsive layouts easier to maintain. Learn more about WordPress for website development and how it supports website design and functionality.
If you only have an hour, open your highest-traffic template at 320px wide. Fix whatever breaks first, then repeat on the next template.
