Core Web Vitals: A No-Nonsense Checklist
Core Web Vitals stopped being a nice-to-have the day Google folded them into ranking signals. But most performance advice is either hand-wavy ("optimise your images!") or so deep in the weeds it never gets implemented. This is the checklist we actually run against client sites, in the order that buys the most speed per hour of work.
The three metrics that matter: Largest Contentful Paint (aim under 2.5s), Interaction to Next Paint (under 200ms), and Cumulative Layout Shift (under 0.1). Everything below maps to one of those three.
Fix the Largest Contentful Paint first
LCP is usually the hero image or headline, and it is usually slow for boring reasons. The fastest wins:
- Serve images as WebP or AVIF and size them to the actual rendered dimensions, not the original 4000px export.
- Add fetchpriority="high" to the LCP image and preload it; let everything below the fold lazy-load.
- Put static assets on a CDN so the byte travels 50ms, not 500ms.
- Inline the critical CSS for above-the-fold content and defer the rest.
Ninety percent of LCP problems are a single oversized image and a render-blocking stylesheet. Fix those two and the score moves before you touch anything clever.
Kill layout shift at the source
CLS is the cheapest metric to fix and the most embarrassing to ignore. Always set explicit width and height (or an aspect-ratio) on images and embeds so the browser reserves space. Reserve room for ad slots and late-loading banners. Load web fonts with font-display: swap and a metric-matched fallback so text does not reflow when the custom font lands.
Tame the JavaScript for INP
Interaction to Next Paint punishes heavy main-thread work. The usual culprit is shipping a megabyte of JavaScript to render what could have been HTML. Code-split by route, defer non-critical scripts, and break long tasks so the browser can respond to taps between chunks of work. For most marketing sites, the honest answer is to ship less JavaScript in the first place.
Shrink the request waterfall
Beyond the headline metrics, a slow site is often just doing too much before it can paint. Open the network waterfall and you will usually find third-party scripts, chat widgets, tag managers, and analytics bundles each adding a connection and a render-blocking dependency. Audit every third-party tag and ask whether it earns its place; a single marketing script can add hundreds of milliseconds and a chunk of main-thread work. Preconnect to the origins you genuinely need, lazy-load the rest, and self-host critical fonts so you are not waiting on someone else's CDN to render your headline.
Measure with field data, not just lab
Lighthouse runs on your fast laptop; your users are on a mid-range phone over patchy mobile. Trust the Chrome User Experience Report and real-user monitoring over a single lab score. A 98 in Lighthouse means little if the 75th-percentile field LCP is 4 seconds. Set a performance budget in CI so a regression fails the build instead of being discovered in production weeks later, and watch the field numbers trend over time rather than chasing a one-off perfect lab run.
- Audit field data to find the metric that is actually failing.
- Optimise the LCP element and critical render path.
- Eliminate layout shift with reserved space.
- Trim and split JavaScript to protect interactivity.
- Re-measure in the field, not just the lab.
A final word on prioritisation: do not chase a perfect score on every metric across every page. Fix the metric that is failing for the most users on the pages that matter most to the business, ship it, then move to the next. Performance work has steeply diminishing returns once you clear the thresholds, and the time is usually better spent making the next page fast than squeezing a fast page faster.
Performance is a feature your users feel even when they cannot name it, and it pays compounding dividends in conversion and ranking. If your scores are stuck in the red, send KadamTech the URL and we will run this exact checklist against it.
