Mobile-first design: content priority, layout and speed, phone first

Mobile-first design means you design and build the phone version of a page first, then add to it as the screen gets bigger, instead of designing for desktop and squeezing the result onto a phone. It is a way of deciding: with one narrow column and a thumb, you have to choose what matters most on the page, and that choice makes the desktop version better too. This guide is for designers, site owners and developers planning a new site or a redesign. It covers content priority, layout for touch, the CSS approach and the speed budget, and it is part of our guide on how to make a website mobile friendly.

Quick answer

• Start with the content, not the layout. List what the page must do and rank it; the phone shows it in that order.
• One primary action per screen, visible without scrolling on a 360 × 640 px screen, the smallest size worth designing for.
• Design for thumbs: tap targets of 44–48 px for main actions (24 px minimum), main actions within easy reach, no hover-only features.
• Build with a phone-first stylesheet: base styles for the narrowest screen, then min-width media queries that add columns and detail.
• Set a speed budget before the first mockup, for example Largest Contentful Paint under 2.5 s on a mid-range phone, and design within it.
• Enhance, don't hide: bigger screens get more layout, never different content; Google indexes the phone version.
• Test on a real phone and with the free mobile-friendly test at every stage, not only before launch.

What is mobile-first design?

The term comes from Luke Wroblewski, a product designer who argued in a 2009 blog post, and in his 2011 book Mobile First, that teams should design for phones before desktops. His reasons still hold: mobile use was growing fastest, the small screen forces focus, and phones offer capabilities (touch, location, camera) that desktop designs ignore.

Mobile-first is not the same as responsive design, though the two usually go together:

You can build a responsive site desktop-first: design the wide layout, then write max-width rules that remove columns. That usually produces phone pages that feel like leftovers, with the sidebar pushed to the bottom and the key action three screens down. Mobile-first reverses the direction, so every addition for a larger screen is a deliberate choice. Our guide to responsive web design covers the technique itself.

Why design mobile-first?

There are three practical reasons, and none of them depends on a statistic about your traffic.

1. Constraint improves decisions. A 360 px column has room for one thing at a time. Teams that start there agree early on what the page is for, and the desktop design inherits a clear hierarchy instead of a crowded one.
2. Google reads the phone version. Under mobile-first indexing, Google crawls and ranks the page its smartphone crawler gets. A design that starts from the phone and keeps all content in it avoids the common trap of trimming content for mobile.
3. Performance is designed, not added. The phone on a mobile network is the hardest case. Designing for it first keeps heavy hero videos, carousels and web font families out of the concept, rather than trying to optimise them away later.

Check your analytics for the device split on your own site; for most consumer sites phones bring the majority of visits, but B2B tools and some niches differ. Mobile-first still pays off when desktop dominates, because the constraint improves the desktop design too.

Step 1: Rank the content

Before any wireframe, write down everything the page needs, then put it in one ordered list. That list is the phone layout.

For a product page, a typical order is:

1. Product name and price
2. Main photo
3. Add to cart
4. Key facts (size, availability, delivery time)
5. Description
6. Reviews
7. Related products

Questions that help:

• What did the visitor come to do? Buy, call, book, read. That action goes near the top.
• What do they need to trust it? Price, delivery, reviews. Those come next, not below 2,000 px of marketing copy.
• What is only nice to have? It goes last, or behind a "Show more" that expands content already in the page.

Everything in the list stays on every screen size. Desktop gets the same list arranged in more columns, not a longer list. Removing content on phones hurts visitors who want it and, because Google indexes the mobile version, removes it from search too.

Step 2: Design the first screen

On a phone, the first screen is roughly 360 × 640 CSS px on small Android devices and a little more on larger phones, minus the browser's address bar and toolbar. That space should show:

• what the page is (a clear heading, not a slogan);
• the primary action or the start of the main content;
• nothing that hides both, such as a full-width promotional banner, a newsletter pop-up or an oversized cookie dialog.

Google's page experience guidance asks you to avoid intrusive interstitials: pop-ups that cover the main content right after a visitor arrives from search. Legally required dialogs such as cookie banners are fine; design them to use a strip of the screen, not all of it.

Use svh, lvh or dvh units, supported in all current browsers, if you size a section to the viewport height. The older 100vh on phones includes the area under the browser toolbar, which pushes buttons off screen.

Step 3: Lay out for thumbs

Touch changes the rules desktop design grew up with:

• Target size. WCAG 2.2 success criterion 2.5.8 sets 24 × 24 CSS px as the minimum; Apple's Human Interface Guidelines recommend 44 × 44 pt and Material Design 48 × 48 dp. Use 44–48 px for main actions. Our guide to the 24 × 24 pixel target-size rule has the CSS.
• Reach. Many people hold a phone in one hand and tap with the thumb, so the lower middle of the screen is the easiest to reach and the top corners the hardest. Sticky bottom bars for the main action ("Add to cart", "Call") work well on long pages; keep them small and never cover content without a way to scroll past.
• No hover. There is no hover on a touch screen. Menus, tooltips and previews that only appear on hover are invisible on phones. Put hover effects inside @media (hover: hover) so they are an extra, not a requirement.
• Spacing between links. Rows of icons, pagination and footer links cause mis-taps. Give them padding rather than making the text bigger.

Navigation

Start with a short list: the three to five destinations most visitors need, visible or one tap away. A menu button with a visible label ("Menu") is clearer than an icon alone. On larger screens the same links can move into a horizontal bar, and a mega menu can add depth, but keep the important category links reachable on phones too; they are internal links Google follows on the mobile page.

Forms

Forms are where mobile designs fail most often, and where they earn money:

• one column, labels above the fields, generous field height;
• the right keyboard with type="email", type="tel" and inputmode="numeric";
• autocomplete attributes (name, email, postal-code, cc-number) so the phone fills in what it knows;
• input text at 16 px or more, so iOS Safari does not zoom in when a field is tapped;
• fewer fields: every optional field is a reason to give up on a phone keyboard.

Step 4: Build it phone first

In CSS, mobile-first means the base styles are the phone styles, and media queries only add:

/* main stylesheet: phone first */
.product { display: grid; gap: 1rem; }

@media (min-width: 48em) {           /* about 768 px */
  .product { grid-template-columns: 1fr 1fr; }
}

@media (min-width: 64em) {           /* about 1,024 px */
  .product { grid-template-columns: 2fr 1fr; gap: 2rem; }
}

@media (hover: hover) {
  .card:hover { box-shadow: 0 2px 8px rgb(0 0 0 / 0.15); }
}

Two rules keep this clean. Place breakpoints where your content starts to look wrong, not at device widths, and use em or rem so they follow the visitor's font size. Our guide to media queries and breakpoints explains the syntax and how to choose them. For components that sit in columns of varying width, container queries let the component respond to its own width rather than the screen's.

Start every page with the viewport tag, or the phone will render it at desktop width:

<meta name="viewport" content="width=device-width, initial-scale=1">

Step 5: Set and keep a speed budget

A speed budget is a limit you agree on before design starts: page weight, number of requests, JavaScript size, or a target for Largest Contentful Paint on a mid-range phone. Google's Core Web Vitals thresholds give you the targets: LCP 2.5 s or less, Interaction to Next Paint 200 ms or less and Cumulative Layout Shift 0.1 or less, at the 75th percentile of real visits.

What the budget changes in design:

• Hero media. A still image sized for the phone instead of a background video. If there is video, it should not be the Largest Contentful Paint element.
• Fonts. One or two families and weights, or a system font stack.
• Carousels. One image and a link usually does the same job with a fraction of the weight.
• Third-party widgets. Chat, reviews, social feeds and pop-up tools each add JavaScript that phones pay for on every tap.

Images do most of the damage on real sites: a 2,000 px photo sent to a 400 px screen. Plan srcset and sizes from the start, as our guide to responsive images explains, and see setting a speed budget and holding to it for how to keep it after launch.

Step 6: Enhance for larger screens

Once the phone version works, widen the browser and add only what the space earns:

• more columns: the product photo beside the buy box, filters beside the list;
• more of what was collapsed, shown open;
• larger images, served at larger sizes through srcset;
• hover states and keyboard shortcuts for mouse users.

What you should not add is different content. The desktop visitor and the phone visitor should be able to find the same information; only the arrangement changes.

How to test a mobile-first design

Test the design as it grows, not only at the end:

1. On a real mid-range phone, in portrait and landscape, on mobile data. Complete the main task: buy, book, send the form.
2. At fixed widths with the free mobile-friendly test, which renders the page at 360, 414, 768, 1024 and 1440 px and names elements that overflow, text under 12 px and tap targets under 24 × 24 px.

3. With a speed test on the mobile setting, which simulates a slower phone and network. Compare it with your budget.

4. Zoomed to 200 % and 400 % in a desktop browser, which checks that the layout reflows for visitors who enlarge text.

The full report runs these checks on every page you enter:

Common mistakes

• Designing the desktop mockup first "because the client reviews on a laptop". Review the phone mockup first, on a phone.
• Hiding content on phones to make them simpler. Collapse it instead; hidden content still loads, removed content is lost to search.
• A hamburger menu for three links. Show them.
• Hover-only menus and tooltips that phones never trigger.
• Designing for one phone. Use the narrowest width you support, 360 px, and check the widths between devices.
• Leaving speed to the developers. The heaviest decisions, video heroes, carousels, fonts and widgets, are made in design.

Questions people ask

What is the difference between mobile-first and desktop-first design?

Mobile-first starts with the phone layout and adds columns, detail and hover effects as the screen grows, using min-width media queries. Desktop-first starts with the wide layout and removes or stacks things for smaller screens with max-width queries. Both can produce a responsive site, but mobile-first forces content decisions early and usually gives phones a clearer, lighter page.

Is mobile-first design still relevant if most of my visitors use desktop?

Yes. The narrow screen forces you to rank content and pick one main action, which improves the desktop layout too. Google also indexes the mobile version of every page, whatever your traffic split, so content missing on phones is missing from search. Check your own analytics, then design the phone version first and enhance it for the desktop visitors you have.

What screen size should a mobile-first design start from?

Start from about 360 CSS pixels wide, the width of many current Android phones and the narrowest width the getReport mobile-friendly test renders. Make sure nothing breaks down to 320 px, which is what WCAG reflow testing uses. Then widen the design and add breakpoints where the layout starts to look stretched or empty, rather than at the widths of specific devices.

Does mobile-first design mean building an app?

No. Mobile-first design is about how you design and build a website so it works best on phones: content order, touch-friendly layout, speed. The result is still one responsive website on the same URLs for every device. An app is a separate product that makes sense for offline use, push notifications or device features, not a replacement for a mobile-friendly site.