Only 48% of mobile sites pass Core Web Vitals. A redesign checklist that passes on day one.

Direct answer

Core Web Vitals are three measurements Google takes from real visitors: Largest Contentful Paint (under 2.5 seconds), Interaction to Next Paint (under 200 milliseconds) and Cumulative Layout Shift (under 0.1), judged at the 75th percentile. The HTTP Archive Web Almanac 2025 found 48% of mobile sites passing all three; the Chrome UX Report for September 2026 puts origins at 55.9%. A redesign passes on day one when the platform, the template, the images, the fonts and the third-party widgets are chosen with those three numbers in mind, which is a short list of decisions made early rather than a long list of fixes made late.

The numbers, so you know what you are aiming at

Google measures three things from the Chrome users who actually visit your site, and judges each at the 75th percentile, meaning three out of four visits have to pass:

• Largest Contentful Paint (LCP): how long until the biggest thing on the first screen is visible. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how long the page takes to respond when someone taps. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much the page jumps around while loading. Good is 0.1 or less.

The HTTP Archive’s Web Almanac 2025 found 48% of mobile sites and 56% of desktop sites passing all three. The Chrome UX Report’s September 2026 dataset, published October 13, puts the share of origins with good Core Web Vitals at 55.9%, with LCP the most commonly failed metric (68.3% pass) and INP the one that regressed across the web in August. The thresholds did not change in 2026, whatever a vendor blog told you.

So roughly half of your competitors fail. A site that passes on launch day is not a miracle. It is a set of decisions.

Decision 1: the platform

This is where most of the outcome is decided, before a pixel is drawn. A hand-coded static site serves plain HTML with almost no JavaScript and passes by default; our own sites run under a second on a phone. WordPress passes when the theme is lean and the plugin list is short, and fails when a page builder stacks twelve scripts and a slider. Shopify and Webflow are in between and depend heavily on the theme and the apps. Our comparison, static vs WordPress, covers the trade-offs; the short version is that every plugin and app you add is a decision against speed, so make the platform choice knowing how many you will need.

Decision 2: the template, or the absence of one

If a template, run Lighthouse on the theme’s own demo before you buy it, on mobile. A demo that scores 60 will not become 95 once your content is in. If custom, insist on a performance budget in the brief: a maximum page weight, a maximum number of requests, and the three thresholds above as acceptance criteria. Our quotes include that budget because it is the only way to hold a build to it.

Decision 3: the hero

LCP is almost always the hero image or the hero headline. The rules:

1. One image, sized for the phoneA 400-kilobyte photo on a phone is the single most common LCP failure. Serve a mobile-sized version (around 800 pixels wide) in WebP or AVIF, and let the browser pick with srcset.
2. No slider, no video backgroundBoth delay the largest paint and add scripts. A static hero with one strong photo converts as well and loads in a fraction of the time.
3. Load the hero image firstMark it high priority and do not lazy-load it. Lazy-load everything below the fold instead.

Decision 4: fonts

Web fonts cause two problems: they delay text and they cause layout shift when the fallback swaps to the real font. Use at most two families, self-host them, preload the one the headline uses, and set a fallback font with matching metrics so the swap does not re-wrap the text. Or use the system font for body text, which costs nothing and reads fine. Most of our sites use one display face for headings and the system stack for everything else.

Decision 5: everything that loads late

CLS comes from things that arrive after the page first appears: a reviews badge, a chat widget, an ad, a cookie banner, an image with no dimensions. Every one of them needs its space reserved in advance. Width and height on every image. A fixed-height box for the reviews widget. A chat button that is positioned, not inserted. If a third-party widget cannot be sized in advance, it does not belong above the fold.

Decision 6: the scripts

INP is the metric a redesign most often makes worse, because new sites add new features. Each script that runs on tap, scroll or load competes for the same main thread. The discipline: analytics loads after the page is interactive, the chat widget loads on first scroll or after a few seconds of idle time, and nothing runs a large amount of work in a single click handler. Count the third-party scripts on the final build. If it is more than three, ask what each one is for.

Decision 7: launch day verification

Lab tools predict; field data decides. On launch day run PageSpeed Insights on the home page and the three most-visited inner pages, mobile tab, and fix anything under 90. Then wait: the Chrome UX Report needs about 28 days of real visits before Search Console’s Core Web Vitals report shows the new site. If the lab numbers are green at launch and the layout holds still, the field numbers follow. Our Denver business clients’ sites are checked this way before we hand them over, and the free website health checks post lists the tools so you can do it to any site, including the one you have now.

The short version to paste into your brief

• Mobile Lighthouse performance 90 or above on home and the top three inner pages, before launch.
• LCP under 2.5 s, INP under 200 ms, CLS under 0.1, measured on a mid-range Android phone, not a MacBook.
• Hero: one sized image, no slider, no video background, loaded first.
• Two font families maximum, self-hosted, metric-matched fallbacks.
• Width and height on every image; reserved space for every widget.
• Three third-party scripts maximum, none before the page is interactive.

Hand that list to any designer. If they push back on it, you have learned something useful before you paid them. Our website redesign page explains how we hold ourselves to it, and redesigning without losing rankings covers the SEO side of the same project.