Core Web Vitals get treated as an abstract Google ranking signal, but they're really just a proxy for "does this page feel fast and stable to a real person." Every fix in this post is one we've shipped on an actual client site, not a theoretical optimization from a blog post about blog posts.
The three metrics, briefly
Largest Contentful Paint (LCP) measures how long the biggest visible element takes to render. Interaction to Next Paint (INP) measures how responsive the page feels when someone actually clicks or taps something. Cumulative Layout Shift (CLS) measures how much content jumps around unexpectedly while loading. Google's "good" thresholds are roughly 2.5s for LCP, 200ms for INP, and 0.1 for CLS.
Fixing Largest Contentful Paint
The largest element is almost always a hero image or a large block of text. For image-led heroes, the single biggest lever is preloading that specific image rather than letting the browser discover it after parsing the CSS:
We also moved several clients off render-blocking web fonts in the critical path (more on that below), and eliminated unused CSS from third-party page builder templates that were shipping several hundred kilobytes of unrelated styles the browser had to parse before painting anything.
Fixing Interaction to Next Paint
INP problems usually trace back to long JavaScript tasks blocking the main thread right when someone tries to interact. The fix is rarely "write less JavaScript" — it's breaking existing work into smaller chunks so the browser can respond to input between them.
We also audited third-party scripts on several sites — chat widgets, analytics tags, A/B testing snippets — and found that a single poorly-optimized script was responsible for the majority of long tasks on more than one occasion. Deferring non-critical third-party scripts until after first interaction, rather than loading them eagerly, resolved the issue without removing functionality.
Fixing Cumulative Layout Shift
Layout shift almost always comes from one of three sources: images without explicit dimensions, web fonts that render with different metrics than their fallback, or content injected above existing content (a common one: a promotional banner that loads in after the page has already rendered).
- Always set explicit
widthandheightattributes on images, even when using responsive CSS — the browser uses them to reserve space before the image loads. - Reserve space for ad slots and embeds with a fixed minimum height, rather than letting them push content down once they load.
- Use
font-display: optionalor carefully matched fallback font metrics for critical above-the-fold text.
Font loading, specifically
Web fonts deserve their own section because they touch all three metrics at once. Our default approach: preconnect to the font host, preload the specific font files actually used above the fold, and use font-display: swap paired with a fallback font stack whose metrics are close enough that the swap doesn't visibly shift layout.
How we measure, not just guess
Lab tools like Lighthouse are useful for catching regressions before launch, but they don't reflect what real visitors experience on real networks and devices. We treat Chrome's Real User Monitoring data (via the Chrome UX Report or a lightweight in-app reporting script using the web-vitals library) as the actual source of truth, and use Lighthouse scores as a pre-launch gate rather than a final grade.
Frequently Asked Questions
They're one of many ranking signals, generally described as a tie-breaker among pages of similar relevance and content quality rather than a dominant factor on their own.
In most audits we've run, yes — the changes in this article are typically enough to move a site into the "good" range without changing the underlying framework or stack.
Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital, since it measures responsiveness across a page's full lifespan rather than just the first interaction.