Because it was designed on a laptop. Most sites start as a wide desktop layout and get squeezed down at the end, which is backwards. Squeezing a three column layout into one column produces something that technically fits but reads badly, taps badly, and loads more than it needs to.
We see this on almost every site we inherit. The desktop version is considered, and the mobile version looks like an afterthought because it was one. Nobody decided what the phone experience should be. It just happened.
Mobile-first is the opposite habit. You decide what matters on the smallest screen, then add room as the screen grows.
Mobile-first means designing the smallest screen first and treating everything wider as an enhancement. You start with one column, the essential content, and the primary action. Then you add space, columns, and detail as the viewport grows. It is a sequencing decision, not a separate mobile website.
The discipline it forces is the real benefit. A phone screen has no room for six competing messages, so you have to choose one. That choice usually improves the desktop version too, because the desktop version was hiding weak thinking behind extra space.
In practice this means writing your CSS so the base styles are the mobile styles, then using media queries or container queries to add complexity upward. Building the other way around means every breakpoint is an override fighting a previous decision.
Yes, but by a narrower margin than most people assume. StatCounter Global Stats put worldwide platform share for June 2026 at 51.51 percent mobile, 47.12 percent desktop, and 1.36 percent tablet. Mobile leads, but desktop is very close behind. This is not a phone-only web.
That split matters because it kills two bad arguments at once. You cannot dismiss mobile as a minority case, and you cannot treat desktop as legacy. Both need to be genuinely good, which is exactly why the mobile-first sequence works better than designing two disconnected experiences.
Your own numbers matter more than the global average. A business-to-business software company often sees desktop dominate, while a local restaurant may be almost entirely mobile. Check your analytics before you let a worldwide statistic decide your layout priorities.
Yes, and the question is settled rather than optional. Google announced on 31 October 2023 that the move to mobile-first indexing was complete. Google now crawls and indexes what the mobile version of your page shows. If content only exists on your desktop layout, Google is not reading it.
Google started mobile-first crawling and indexing back in 2016, so this has been coming for a long time. The 2023 announcement was the finish line, not the starting gun. Google also turned off the indexing crawler information in Search Console settings at the same time, because there was no longer a distinction worth reporting.
The practical consequence is blunt. Content hidden on mobile is content Google may not count. If you collapse your product details or strip your footer links on small screens, you are editing what search engines see. That is a decision worth making on purpose rather than by accident, and it sits alongside the other technical factors we cover in our guide to how Core Web Vitals affect rankings.
The W3C sets a clear floor. WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), is a Level AA requirement that pointer targets be at least 24 by 24 CSS pixels, unless there is enough spacing around them. The enhanced Level AAA criterion, 2.5.5, raises that to 44 by 44 CSS pixels.
We design to the 44 pixel figure rather than the 24 pixel minimum. Twenty four pixels is a compliance floor, not a comfortable target. A finger is not a cursor, and people use phones while walking, on buses, and one-handed. The extra size costs almost nothing and removes a whole class of frustration.
Spacing matters as much as size. Two buttons that each meet the minimum but sit flush against each other still produce mis-taps. WCAG''s own wording allows undersized targets when they are spaced so that 24 pixel circles centred on each do not overlap, which tells you spacing is part of the requirement rather than a nicety.
The worst offenders are usually links inside body text and icon-only buttons in headers. Both tend to inherit whatever size the typography gave them, which is rarely enough. This is one of several places where accessibility and usability point the same way, as we discuss in our walkthrough on making a website WCAG accessible.
Cut decoration, not content. Background videos, parallax layers, oversized hero images, and secondary navigation can all go. What should stay is every piece of information and every link, because Google indexes the mobile version and because visitors did not come to your site for less.
This distinction gets muddled constantly. Teams hide entire sections on mobile to make the page shorter, then wonder why those pages stop ranking. Shortening a page by deleting its substance is not responsive design, it is a content decision made by a media query.
Long pages are fine on phones. People scroll without complaint when what they are scrolling through is worth reading. What they will not tolerate is a page that takes four seconds to become usable because it is still loading a video nobody asked for.
Put the one action you most want people to take somewhere permanently visible, and put everything else behind a menu. On a phone there is no room for a full navigation bar, so the hamburger menu is a reasonable compromise. What is not reasonable is hiding your primary call to action inside it.
We keep a visible button in the header on mobile, usually contact or book a call, and let the rest collapse. That single choice tends to matter more than any argument about menu icons, because it is the difference between a visitor having to hunt for the next step and simply seeing it.
Inside the menu, keep the list short and the labels plain. A mobile menu with nested submenus three levels deep is a filing cabinet, not navigation. If your structure genuinely needs that depth, the structure is the problem, which is the argument we make at length in our piece on what makes website navigation easy to use.
Because phones do more work with less. A mobile processor parses the same JavaScript a laptop does, on a smaller power budget, often over a slower connection. A page that renders instantly on your development machine can take several seconds on a mid-range Android phone on a weak signal.
Layout shift makes this worse in a way raw speed numbers miss. When content jumps because an image or an ad loaded late, the page feels broken even if it finished loading quickly. On a small screen a shift of a hundred pixels moves the thing someone was about to tap.
The fix is unglamorous. Set explicit width and height on images so the browser reserves space, load fonts in a way that does not blank the text, and defer anything that is not needed for the first screen. None of it is clever. All of it is usually skipped.
On a real phone, on a real network, held in one hand. Browser developer tools are useful for catching layout breaks quickly, but they simulate a screen size, not a device. They do not reproduce a slow processor, a patchy connection, a thumb, or sunlight on a screen.
Chrome DevTools and Safari''s responsive mode are where we start, because they make it fast to find the obvious breaks at each width. Then we open the same page on an actual mid-range Android device rather than the newest iPhone, because the newest iPhone will forgive performance problems that most of your visitors will not.
Test with one hand. Reach for the primary button with a thumb and see whether it is comfortable. Anything in the top corners of a large phone is hard to reach, which is why important actions belong lower on the screen than desktop instincts suggest.
Open your homepage on your own phone right now and try to complete the main action. Time how long it takes to become usable, check whether the primary button is visible without opening a menu, and see whether anything from the desktop version is missing. That three minute test will give you your first three tasks.
Mobile-first is less a technique than an order of operations. Decide what matters when you have the least room, and the rest of the design gets easier. Sites built the other way spend their whole life patching breakpoints.
If your site works on desktop and falls apart on a phone, and you would rather not guess at why, we are happy to look at it with you. Reach out at phoenix.studio and we will walk through what we find.
Tell us where you want to go. We'll tell you how we'd get you there.