Three metrics that affect both how a site feels to use and how it ranks — and a specific set of things that actually move them.
Core Web Vitals measure real aspects of user experience — how fast something useful appears, how quickly the page responds to interaction, and whether the layout stays stable while loading. They matter for two overlapping reasons: they're part of how Google evaluates page experience for ranking, and they're a reasonable proxy for whether real visitors are having a good or frustrating time on the page.
Largest Contentful Paint — how long it takes for the largest visible element (usually a hero image or heading) to render.
Moved by: image optimization and modern formats, faster server response time, and removing render-blocking CSS/JS above the fold.
Good is under 2.5 seconds.
Interaction to Next Paint — how long the page takes to visibly respond after a user clicks, taps, or types, measured across the whole page visit.
Moved by: breaking up long JavaScript tasks, reducing main-thread work, and deferring non-critical scripts.
Good is under 200 milliseconds.
Cumulative Layout Shift — how much visible content unexpectedly moves around as the page loads.
Moved by: reserving space for images and ads before they load, and avoiding web fonts that shift text once they arrive.
Good is under 0.1.
A Lighthouse score run on a fast connection in a clean browser tab is a lab measurement — useful for catching regressions, but not what Google actually uses for ranking. Google's ranking signal comes from real user data collected across actual visits, on real devices and real networks, which is almost always messier and less favorable than a lab run. Optimizing purely for a lab score can miss the real-world conditions — a slow mid-range phone on a patchy connection — that real user data reflects and that lab testing on a fast machine tends to hide.
The common mistake is attacking whichever metric is easiest to explain rather than whichever one is actually failing worst in real-user data — teams spend a sprint on CLS because a shifting layout is visible and embarrassing, while LCP quietly costs more ranking and conversion the whole time. Check Search Console's Core Web Vitals report first; it tells you which metric is actually failing for real visitors, not which one looks worst in a demo.
In practice, LCP is usually the highest-leverage fix and the cheapest to make: compress and modern-format the hero image, and stop non-critical scripts from blocking it. INP comes next and is the most engineering-heavy, since it usually means breaking up long JavaScript tasks rather than a config change. CLS is typically the fastest to resolve outright — reserve space for images and ads before they load, and most of the shift disappears in an afternoon.
Yes, they're part of Google's page experience signals, though content relevance still matters more overall. Vitals tend to act more as a tiebreaker between otherwise similar pages than as the deciding factor on their own.
Often yes — most fixes are technical (image optimization, reducing JavaScript execution, reserving layout space) rather than visual, so they can usually be applied without changing how the site looks.
Lab tools like Lighthouse test a single simulated load under controlled conditions; real user data (what Google actually uses for ranking) reflects a mix of devices, network speeds, and real-world conditions, which is usually less favorable than a clean lab run.
Whichever one is failing hardest in your real-user data (CrUX/Search Console), not the one that's easiest to fix — LCP issues usually have the biggest ranking and conversion impact.
Often the single biggest factor — analytics, chat widgets, and ad tags routinely account for most of a page's blocking time and INP delay.
A practical comparison of headless and traditional content management systems — flexibility, editorial workflow, and how to pick the right one.
Read the guide