Mobile-First Web Design: Building for the Majority

Design the narrow layout first, with the real content in it, and treat the wide layout as the version that gets extra breathing room. That is the whole idea. Mobile-first is not a visual style and it is not a separate site. It is an ordering decision: you decide what matters when you only have a 390-pixel-wide column and a thumb, and then you let that ordering survive every larger screen.

The reason to work this way is not fashion. Statista’s series on mobile’s share of global web traffic, built on StatCounter measurements, put phones at 51.48% in the second quarter of 2026 — just over half, and the series has bounced between roughly 51% and 63% over the preceding two years. Call it half the web and you will not be far wrong in any quarter. More importantly, the phone half is the half that struggles.

Mobile is not a segment, it is the default

Google has crawled and indexed with its smartphone agent for years now, and its own mobile-first indexing guidance is blunt about the consequence: if content, structured data or metadata exists on your desktop layout but not the mobile one, Google may never see it. That alone retires the old habit of hiding half the page below a 768-pixel breakpoint.

The share figure moves around more than most people expect, and anyone quoting a single tidy number is usually quoting a stale one. Statista’s quarterly series shows 62.73% in Q2 2025, then 57.96%, then 51.29%, then 52.27%, then 51.48% in Q2 2026. Measurement methodology, bot filtering and regional weighting all push that line around. The honest reading is that mobile and desktop are close to an even split globally, with the balance tipping heavily towards mobile in some regions and heavily towards desktop in others. If you sell business software to people at desks, check your own analytics before you accept any of these numbers as your reality.

Why the small screen is the harder target

The 2025 Web Almanac, which HTTP Archive builds from Chrome UX Report field data, is the clearest picture of the gap. In 2025, 48% of mobile websites passed all three Core Web Vitals against 56% on desktop. Mobile has improved faster — it was 36% in 2023 and 44% in 2024 — but it has never caught up, because slower silicon and less predictable networks punish the same page harder.

Break it down by metric and the pattern gets more useful. Largest Contentful Paint is good on 74% of desktop pages and 62% of mobile pages, and poor on 13% of mobile pages against 7% on desktop. Interaction to Next Paint is the widest gap of all: 97% good on desktop, 77% on mobile, although that 20-point gap had narrowed from 23 points the year before. Cumulative Layout Shift is the one place mobile wins, at 81% good against desktop’s 72%, mostly because single-column layouts have less room to jump around.

That INP figure is the one worth sitting with. Responsiveness on phones is a JavaScript problem, not a bandwidth problem. A phone that downloads your bundle quickly still has to parse and execute it on a chip with a fraction of a laptop’s single-core budget.

Where the bytes go

The Almanac’s page weight chapter puts the median mobile home page at 2,164 KB and the median desktop home page at 2,412 KB. The composition tells you where to aim.

Images and JavaScript are 71% of the median mobile home page between them. Everything else is rounding. If you only ever do two things for mobile performance, serve responsive images in a modern format and delete the scripts nobody can name the purpose of.

What mobile-first changes in practice

Narrow-first design is mostly a set of small, boring decisions made in a particular order. The ones that change the result:

• Content order is the design. On a phone there is no sidebar, no third column and no hero split. Whatever is first is what gets read, so decide the sequence before anyone opens a design tool.
• One primary action per screen. If a visitor has to choose between five buttons on a 6-inch screen, they usually choose none.
• Reserve space for anything that loads late. Width and height on images, fixed heights on ad and embed slots. This is what keeps CLS near zero.
• Forms get shorter, not smaller. Use the right input types so the keyboard matches the field, and cut any question you do not act on.
• Nothing important hides behind hover. Touch has no hover state. Tooltips and hover menus simply do not exist for half your visitors.
• Test the thumb zone. Primary actions belong in the lower two thirds of the screen where a thumb comfortably reaches.

Tap targets, text and the 24-pixel rule

WCAG 2.2, published as a W3C Recommendation on 5 October 2023, added nine success criteria, and two of them are aimed squarely at touch. Success criterion 2.5.8 Target Size (Minimum) sits at Level AA and asks that interactive targets be at least 24 by 24 CSS pixels, with exceptions for inline links in text and for targets that have enough spacing around them. Criterion 2.5.7 Dragging Movements asks that anything you can drag also be operable with a single pointer action.

Breakpoints without the device shopping list

Breakpoints named after devices age badly. The phone that justified a 375-pixel breakpoint is long gone, foldables sit between categories, and plenty of desktop visitors browse in a half-width window. Set breakpoints where your content breaks: when a line of body copy gets too long to track comfortably, when a table stops fitting, when a two-column layout stops being cramped. Then check the result at a handful of real widths rather than a device list.

Testing on conditions your visitors actually have

Lab tools on a fast laptop over office fibre will tell you everything is fine. Field data will not. The Chrome UX Report is where your real 75th-percentile numbers live, and Google assesses a metric as good when at least 75% of page views meet the threshold, measured separately for mobile and desktop. Check both. A site that passes on desktop and fails on mobile is a site failing for half its visitors.

1. Pull your own mobile and desktop Core Web Vitals from Search Console or PageSpeed Insights field data, not from a lab score.
2. Throttle to a mid-tier Android profile and 4G in Chrome DevTools before you call anything fast.
3. Measure INP by actually interacting — open the menu, filter the list, submit the form.
4. Record the LCP element on your three most-visited templates. On mobile it is an image 76% of the time, per the Almanac, so that image is your main job.
5. Re-measure after every third-party script you add. That is usually where the regression came from.

Where mobile-first costs you something

Some interfaces are genuinely worse narrow-first, and pretending otherwise wastes money. Dense data tables, admin dashboards, scheduling grids and anything built for comparison across many columns need the wide layout designed properly, with the phone version deliberately reduced rather than squeezed. Internal tools used almost entirely on company laptops are another fair exception: build for the screen your users have and spend the saved effort elsewhere.

The other honest cost is review time. Narrow-first means your stakeholders see the least impressive version of the design first, and you will spend meetings explaining that the desktop version is coming. Budget for that conversation instead of being surprised by it.

A sequence that works

1. Write the content for the page before the layout. If it does not survive a single column, the layout cannot save it.
2. Design the 390-pixel view with real copy, real images and real button labels.
3. Set a performance budget in kilobytes per template, informed by the 2,164 KB median mobile page, and reject anything that blows it without a named business reason.
4. Build the wide layout as an enhancement of the narrow one, not a separate design.
5. Audit tap targets and contrast against WCAG 2.2 Level AA before launch, not after.
6. Watch mobile field data for a month after launch and fix the worst template first.

If you want a second pair of eyes on a layout that is already built, our web development and hosting service covers mobile-first rebuilds, performance work and the measurement that proves it worked, delivered remotely wherever you are. Two companion pieces worth reading next: web accessibility basics, because touch targets and contrast overlap almost entirely with accessibility, and how to redesign without losing rankings if a mobile rebuild means new URLs. For the underlying speed question, web hosting types explained covers where the first byte comes from.

Want a mobile-first rebuild or an honest performance audit of what you have now? Get in touch with Eudora Technology to talk about your project.