Core Web Vitals Audit. LCP, CLS, INP explained by someone who fixes slow sites for a living.

01 — What Core Web Vitals are

Core Web Vitals are three metrics Google standardised in 2020 to measure the real user experience of a web page.

LCP (Largest Contentful Paint) measures when the site appears loaded. CLS (Cumulative Layout Shift) measures how much the layout jumps during loading. INP (Interaction to Next Paint) measures how fast the site responds to user actions.

Google replaced FID with INP in March 2024 because INP is more representative of real experience: it measures every interaction, not just the first. Current thresholds: LCP < 2.5s, CLS < 0.1, INP < 200ms. To "pass the check" all three must be in "good" range for 75% of users.

02 — Why Google uses them for ranking

"Page Experience" has been an official ranking factor since 2021. Google stopped only requiring that sites be relevant: it now also requires they be usable.

Core Web Vitals' weight in ranking is not huge by itself (Google declares "tiebreaker when content is comparable") BUT it compounds with other signals. High mobile bounce rate (caused by slow LCP), reduced session duration (caused by bad INP), pogo-sticking (user returns to SERP because the site is unusable). All these are secondary signals that push a site down.

The real effect is asymmetric: green CWV doesn't give you a boost, but red CWV makes you slip. It's a "qualifier", not an "amplifier". For serious SEO it's a necessary condition.

Beyond pure ranking, there's the conversion data. Every 100ms more LCP reduces e-commerce conversions by 1% (Akamai/Cloudflare median industry data). For an e-commerce with 100k€ monthly volume, getting LCP from 4s to 2s is, in real money, multiples of the audit cost.

03 — The 3 metrics explained (and how to fix them)

• LCP< 2.5s

  Largest Contentful Paint

  Measures the time it takes for the largest visible element (hero image, main heading, video poster) to appear on screen. It's the best proxy for 'when the site looks loaded to the user'.

  Fixes in impact order

  • Hero served in AVIF/WebP instead of PNG/JPEG
  • fetchpriority="high" on the cover image
  • Preload of above-the-fold display font
  • Eliminate render-blocking CSS
  • Hosting with TTFB under 600ms
• CLS< 0.1

  Cumulative Layout Shift

  Measures how much the layout 'jumps' during loading. A layout shift is when an element moves because something loads later (image without dimensions, cookie banner, font that changes metrics). Measured in dimensionless units 0 to infinity.

  Fixes in impact order

  • Explicit dimensions (width/height) on every <img>, <iframe>, <video>
  • Reserved space for cookie banner (e.g. min-height: 80px)
  • Font-display swap with size-adjust to minimise the fallback→display jump
  • Sticky header with fixed height, not 'auto'
  • Skeleton loader with same dimensions as final content
• INP< 200ms

  Interaction to Next Paint

  Measures how long the site takes to react to an interaction (click, tap, key press). Replaces FID since March 2024. A site that responds in 500ms feels 'broken' even if everything works.

  Fixes in impact order

  • Long tasks split with scheduler.yield() or setTimeout
  • Heavy events moved to requestIdleCallback
  • Optimised React/Vue hydration (server components, lazy hydration)
  • JavaScript bundle split per route, not monolithic
  • Heavy listeners debounced or throttled

04 — The 4 tools that actually matter

Nothing exotic. Four tools, free or built-in, cover 95% of the audit.

• 01

  PageSpeed Insights

  pagespeed.web.dev

  Quick test. Once you enter the URL, gives you both lab data (Lighthouse) and field data (CrUX, real users last 28 days). What actually counts for Google is the field data.

• 02

  WebPageTest

  webpagetest.org

  Deep test. Frame-by-frame filmstrip, waterfall request, TTFB/render/scripting/loading breakdown. Lets you see WHERE time is lost, not just how much.

• 03

  Chrome DevTools Performance

  built-in

  When you need to understand why an interaction is slow (INP). Record a session, look at the flame chart, identify long tasks. The tool developers use for the most technical fixes.

• 04

  CrUX Dashboard (BigQuery or Looker Studio)

  BigQuery

  For large sites, dashboard on aggregated real Chrome data (Chrome User Experience Report). Shows how your real users perform, not a lab test. The data Google uses for ranking.

05 — How to run a serious audit in 30 minutes

1. Identify the 5 critical pages. Don't test everything: test the ones that drive traffic/conversions (home, product/service list, top-3 detail, checkout if e-commerce).
2. PageSpeed Insights on every page. Look at field data, not lab. Lab numbers (Lighthouse) are laboratory tests. Field data (CrUX) is real users. Huge difference.
3. Identify the worst metric per page. If LCP is 4.2s, INP is 280ms, CLS is 0.05 → priority is LCP. Don't do 30 random fixes: do 3-5 fixes on the metric that fails.
4. WebPageTest waterfall on the worst page. See which request blocks the render (usually CSS or font), which request is the LCP element's, how much time passes before paint. Specific fixes come out of this.
5. Prioritised fix list, not alphabetical. Audit output: 3-5 fixes in impact/effort order, each with estimated delta. "Replace hero PNG with AVIF + fetchpriority" → expected -800ms LCP.

06 — Fixes in priority order (for most sites)

For ~80% of the sites I see, the fix order that actually moves the needle is this:

1. Image optimisation (AVIF/WebP + lazy loading + dimensions). 3MB hero in PNG → 80KB in AVIF is the biggest difference you'll see. Low effort, high impact on LCP and CLS.
2. Font loading. next/font, selective preload, size-adjust. Reduces CLS to almost zero, speeds up LCP by 200-400ms.
3. Render-blocking CSS/JS cleanup. Critical CSS inlined, JavaScript split per route, defer everything not needed above the fold. Reduces LCP by 500-1500ms on heavy sites.
4. Hosting/TTFB. If TTFB is above 600ms even after cache, the problem is server-side. CDN, edge caching, tuned hosting. For WordPress sites: WP Engine, SiteGround, Kinsta. For Next.js: Vercel, Cloudflare.
5. INP optimisation. Usually the last fix. Long tasks split, optimised hydration, throttled listeners. Without heavy JavaScript, INP is almost always green by default.

When these five steps are done, 80% of sites pass the check. The remaining 20% needs deeper interventions. Architectural refactor, CMS change, heavy component rewrite. There the full audit is needed, not the checklist.