Google now measures the real experience your visitors get, and it rewards fast, stable, responsive pages. If your Core Web Vitals are poor, you're losing both rankings and revenue.
What is LCP, and what's a good score?
Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element, usually the hero image or main headline, to appear. Google's threshold for a good experience is 2.5 seconds or less, assessed at the 75th percentile of real visits, so most of your visitors need to hit it, not just the lucky ones on fast Wi-Fi. LCP is the metric visitors feel most directly: it's the moment the page looks ready. It usually fails for three reasons: an oversized hero image, a slow server response, or render-blocking theme code and fonts that delay everything else. The fixes are equally concrete, namely right-sized modern image formats, a fast host or CDN, and fewer blocking resources. On a lean custom build, passing LCP is the default rather than a project, which is one of the main reasons we build that way.
What is INP, and why did it replace FID?
Interaction to Next Paint (INP) measures how quickly a page responds visually after someone taps, clicks or types, across the whole visit rather than only the first interaction. A good score is 200 milliseconds or less. It replaced First Input Delay as a Core Web Vital in March 2024, because FID only measured the delay before the first interaction was processed, which most sites passed easily while still feeling sluggish. INP catches the real frustration: an add-to-cart button that hesitates, a menu that opens a beat late, a filter that freezes the page. The usual cause is too much JavaScript competing for the browser's main thread, from chat widgets, popups, trackers, review apps and theme features. The fix is a script budget: fewer third-party scripts, loaded later, and interactions built so the page responds first and finishes its work afterwards.
What is CLS, and what causes layout shift?
Cumulative Layout Shift (CLS) measures how much visible content moves unexpectedly while the page loads and during use. A good score is 0.1 or less. You've felt a poor one: you go to tap a link, an image or banner loads above it, the text jumps, and you tap the wrong thing. Beyond the annoyance, shifts erode trust at exactly the wrong moments, such as on a product page or at checkout. The causes are mechanical and fixable: images and videos without declared dimensions, fonts that swap in at a different size, cookie bars, promo banners and ads injected after the content has rendered, and embeds that resize themselves. Clean builds prevent almost all of it by reserving space for every element before it loads, so the layout is stable from the first paint. It's the cheapest of the three metrics to get right when it's planned from the start.
Why do Core Web Vitals pay off twice?
Because the same improvement helps two different things at once: how search engines rank the page and how many visitors stay long enough to buy. Core Web Vitals are part of Google's page experience signals, so passing them removes a disadvantage in search. Independently, faster and steadier pages keep more visitors engaged: the Deloitte and Google "Milliseconds Make Millions" study associated even a 0.1-second improvement in mobile speed with higher conversion on the retail sites it measured. Few site improvements touch both acquisition and conversion; most marketing spend buys one or the other. That's also why speed work tends to outlast campaigns: once a site is fast, every future visitor benefits, whether they came from search, ads, email or an AI answer. Speed connects to AI visibility too, since lightweight, server-rendered pages are easier for any crawler to read and cite.
How do you check your Core Web Vitals?
Two free tools tell you everything. PageSpeed Insights (pagespeed.web.dev): paste your URL and read the top section, "Discover what your real users are experiencing", that's field data from actual Chrome visitors, the data Google actually uses. The lab score below it is a diagnostic, not your grade, so don't panic over it. Second, Google Search Console → Core Web Vitals report: it shows which groups of pages pass or fail across your whole site, so you can spot patterns (all product pages failing LCP, say) instead of testing URLs one by one. Check the phone tab first in both tools, mobile thresholds are where most sites fail and where most of your traffic is. Five minutes, once a month, is enough to catch regressions before they cost rankings.
What usually breaks each metric?
The culprits are remarkably consistent. LCP breaks on oversized hero images (a 2MB photo where a 150KB WebP would do), slow theme code that delays rendering, and fonts loaded inefficiently. INP breaks on JavaScript, the death-by-a-thousand-scripts of app-heavy stores: chat widgets, popups, trackers and theme features all competing for the main thread when a user taps. CLS breaks on images without declared dimensions, late-injected banners and cookie bars, and ads that shove content around. Notice the pattern: almost every cause is "something was added without asking what it costs." That's why the durable fix is architectural, a build where images ship optimized, scripts are few and deferred, and space is reserved before anything loads, rather than an optimization plugin fighting symptoms.
What do we prioritise on our own builds?
This isn't only theory for us, it's how we build. On every store we ship, the same priority keeps coming back: make the experience faster and clearer for the visitors you already have, before thinking about bringing in more. In practice that means right-sized images, a lean script budget, a layout that doesn't jump while it loads, and checking all of it on a real phone rather than a fast office laptop. That is exactly what Core Web Vitals measure, and it's the honest case for treating them as part of the quality of a site, not a technical checkbox.
Do Core Web Vitals really move rankings?
Honest answer: they're a real but modest ranking signal, closer to a tie-breaker than a trump card, great content on a slow site still beats thin content on a fast one. So why obsess? Because the ranking effect is the smaller half of the payoff. The same slowness Google measures is what your visitors feel: pages that lose half their mobile audience before rendering don't convert, whatever their position. Speed also compounds indirectly, faster sites get crawled more efficiently, keep users engaged longer, and earn better behavioral signals. Treat Core Web Vitals as a health check for the experience you're selling, with the ranking boost as a bonus. Optimizing them purely "for Google" misses the point; the money was always in the visitors.
Sources
Want a site that passes Core Web Vitals and is built right for search? We build fast by default. Let's talk.