Updated March 2026: This post was originally written in early 2023. I have added notes where things have changed, particularly around CSS container queries and the new Core Web Vitals metric (INP). The core advice still holds.
I have been building websites since 2011. Somewhere around website number 30, responsive design stopped being a "feature" and started being the default. You don't think about it anymore. You just do it. Like adding a favicon or setting up HTTPS.
But every now and then, a client or a colleague asks why we bother making something work on mobile when "most of our users are on desktop." And every time, the analytics tell a different story.
So here is what I have learned from building responsive layouts across 90+ production websites over the past decade and a half.
Your users are already on mobile
This isn't a prediction anymore. It happened years ago. Mobile traffic has been over 50% of global web traffic since roughly 2017, and it hasn't gone back. For most of the websites I have worked on, mobile accounts for 60-70% of total visits.
The thing people miss is that "mobile" doesn't just mean phones. It's tablets, foldables, smart displays, car dashboards. My portfolio site gets traffic from screen widths ranging from 320px to 3440px. If your layout only works at 1440px, you are ignoring most of your audience.
Google cares. A lot.
Google switched to mobile-first indexing years ago. What this means in practice: if your site looks broken on a phone, your search rankings take a hit even for desktop searches. Google's crawler evaluates the mobile version of your site first.
I have seen this play out directly. At one of my previous roles, we had a landing page that looked great on desktop but had horizontal scroll issues on mobile. The CLS (Cumulative Layout Shift) score was terrible. After fixing the responsive layout and bringing CLS under 0.1, organic traffic to that page went up about 20% over the following month. Not because the content changed. Because Google stopped penalizing it.
[2026 update] Since March 2024, Google replaced FID (First Input Delay) with INP (Interaction to Next Paint) as a Core Web Vital. INP measures responsiveness across the entire page lifecycle, not just the first interaction. This makes responsive layouts even more important because layout shifts from non-responsive elements directly hurt your INP score.
One codebase, not two
I have worked at places where the solution to "it doesn't work on mobile" was to build a separate mobile site. Separate domain (m.example.com), separate codebase, separate deployment. Double the bugs, double the maintenance, half the consistency.
A responsive site is one codebase. One URL. One set of styles. When you update the pricing table, you update it once. When you fix a typo, you fix it once. This sounds obvious, but the cost savings add up fast when you're maintaining dozens of sites.
At Reliance, we managed a large number of web properties. Every one of them was responsive from the start. The alternative (separate mobile builds for each) would have been impossible to maintain with our team size.
How I actually build responsive layouts now
The tooling has gotten so much better since I started. Back in 2011-2012, we were using float-based grids and media queries for everything. It was painful. You'd spend hours debugging why a three-column layout collapsed wrong at 768px.
Today, my responsive stack looks like this:
- CSS Grid and Flexbox for layout. Grid for two-dimensional layouts (dashboards, card grids), Flexbox for one-dimensional flows (navbars, form rows). Between these two, I rarely need media queries for layout changes anymore.
clamp()for fluid typography and spacing. Instead of settingfont-size: 16pxand then overriding it at three breakpoints, I useclamp(1rem, 0.5rem + 1vw, 1.25rem). Font scales smoothly. No breakpoints needed.min(),max(), andminmax()in Grid to create intrinsically responsive layouts.grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))gives you a card grid that adapts to any width without a single media query.- Media queries only for major layout changes, like switching from a sidebar layout to a stacked layout below a certain width.
[2026 update] CSS container queries have now shipped in all major browsers and are stable in production. This is a genuine shift. Instead of asking "how wide is the viewport?", you can ask "how wide is the container this component lives in?" I have started using them for reusable components that appear in different layout contexts, like a card component that renders differently in a sidebar vs. a main content area. The @container syntax is clean and it solves a problem that media queries never could.
The business case is boring but real
Here is what actually happens when a site isn't responsive:
- Bounce rate goes up. Users pinching and zooming to read text will leave. Average bounce rate for non-responsive mobile experiences is significantly higher than responsive ones.
- Conversions drop. If someone can't tap your CTA button because it's 30px wide and sandwiched between two other elements, they're not converting.
- Support tickets increase. "Your site doesn't work on my phone" is a real email that real people send.
- Brand perception suffers. Rightly or wrongly, people judge your business by your website. A site that breaks on mobile feels outdated.
This isn't complicated math. If 60% of your traffic is mobile and your mobile experience is bad, you're providing a bad experience to the majority of your users.
Common mistakes I still see
Even in 2023, I review sites that make the same responsive design mistakes:
- Fixed-width containers. Setting
width: 960pxon a wrapper. Usemax-widthinstead. - Images without
max-width: 100%. An 1800px-wide hero image will cause horizontal scroll on every phone. - Hover-only interactions. Touch devices don't have hover. If your navigation relies on hover to show dropdowns, it's broken on mobile.
- Tiny tap targets. Google recommends at least 48x48px for touch targets. Anything smaller and people will mis-tap constantly.
- Viewport meta tag missing. Still happens. Without
<meta name="viewport" content="width=device-width, initial-scale=1">, mobile browsers render at 980px width and zoom out. Your media queries won't fire.
What I would tell someone starting out
If you're learning front-end development, responsive design is not optional and it's not an advanced topic. It's day-one stuff. Start mobile-first. Write your base styles for small screens, then add complexity as the viewport grows. This forces you to prioritize content and keeps your CSS cleaner.
Learn Flexbox and Grid properly. Not just the syntax, but when to use which. Flexbox for distributing space in a single direction. Grid for placing items in two dimensions. These two tools handle 90% of responsive layout needs without any media queries.
And test on real devices. Browser DevTools device mode is useful but it doesn't catch everything. The way a real phone renders fonts, handles touch events, and scrolls is different from what Chrome's emulator shows you.
Honest takeaway
Responsive design isn't exciting. Nobody writes blog posts about it anymore because it's assumed. But that's exactly why it matters. It's infrastructure. Like plumbing. Nobody notices when it works. Everyone notices when it doesn't.
If your website isn't responsive in 2023, you're not saving time or money. You're losing both.