State of the art, no fluff
Core Web Vitals stopped being an academic debate and became a business metric. Google uses them as a ranking signal, users feel them directly in conversion, and serious teams already have explicit budgets per page.
Targets, at p75 over field data:
- LCP (Largest Contentful Paint) ≤ 2.5 s
- INP (Interaction to Next Paint) ≤ 200 ms
- CLS (Cumulative Layout Shift) ≤ 0.1
INP officially replaced FID in March 2024 and is the most demanding today: it measures real response latency to clicks, taps and keyboard, not just the first one.
What actually moves the needle
For LCP: identify the LCP element in each template (usually a hero image or an H1 with a webfont), add fetchpriority="high" to the image and a <link rel="preload"> for the font that paints it. Serve the image as AVIF/WebP and dimension it with width/height to avoid reflows.
For INP: the main villain is JavaScript on the main thread blocking interactions. Reduce third-party JS (analytics, chat, video) by loading them via Partytown or web workers. For your own JS, avoid heavy state updates in handlers; use requestIdleCallback for non-urgent work.
For CLS: reserve space for everything that loads later (images, iframes, ads, web fonts with FOIT/FOUT, cookie banners). font-display: swap with appropriate size-adjust avoids the typical jump when webfonts load.
The gap between fast and feeling fast
A site can have a 2.0 s LCP and feel slow if the main button takes 400 ms to respond to a click. That’s why INP matters so much. Optimizing perceived performance means investing in real interactivity, not just load metrics.
How to measure it for real
Don’t stop at Lighthouse. It’s useful but it’s lab data; decisions should be made with field data. Use the Core Web Vitals report in Search Console or the web-vitals library reporting to your analytics. Set per-page budgets and break them should block deploys.