Core Web Vitals Explained: A Practical Guide to LCP, INP, and CLS
LCP, INP and CLS are the metrics Google uses to judge real-world performance. This guide explains what each one measures and the concrete fixes that move the needle.
- Home-
- Categories-
- Frontend Development-
Core Web Vitals Explained: A Practical Guide to LCP, INP, and CLS
Core Web Vitals Explained: A Practical Guide to LCP, INP, and CLS
Why these three metrics matter
Google uses Core Web Vitals as part of its page experience signal. They describe what real users experience in the field, not what a synthetic lab test reports, so improving them is genuine product work.
Largest Contentful Paint (LCP)
LCP measures when the largest above-the-fold element finishes loading. The target is under 2.5 seconds.
- Preload the hero image and the stylesheet that affects it.
- Serve images in modern formats with sensible dimensions.
- Cut render-blocking third-party scripts from the critical path.
Interaction to Next Paint (INP)
INP replaces First Input Delay. It measures the worst response to a user interaction, and the good limit is 200 milliseconds.
- Keep long tasks on the main thread under 50 milliseconds.
- Defer non-essential work until after the page becomes interactive.
- Debounce expensive handlers instead of running them on every event.
Cumulative Layout Shift (CLS)
CLS rewards pages that do not jump around while loading. A score below 0.1 is good.
- Reserve space for images and embeds with explicit dimensions.
- Avoid inserting content above existing content after the request starts.
- Let fonts keep their fallback metrics to stop invisible-text reflows.
How to verify your work
Run Lighthouse for a quick lab pass, then compare it to CrUX field data for your real traffic. Field performance is what search engines ultimately see, so an analytics tool that reports RUM metrics is worth the setup cost.
The takeaway
Performance is not a one-time checklist. Set the targets, add the metrics to your CI, and treat every release that regresses them as a bug.
Key takeaways
- Judge performance with field data, because Core Web Vitals describe what real users experience, not lab results.
- Preload the hero image and its stylesheet, then move render-blocking third-party scripts out of the critical path.
- Keep main-thread long tasks under 50 milliseconds and debounce expensive handlers to protect the 200 millisecond INP limit.
- Reserve explicit space for images and embeds so nothing shifts and CLS stays below 0.1.
- Add the metrics to CI and treat any release that regresses them as a bug, not a follow-up ticket.
FAQ
Q: Which is better for checking my work, Lighthouse or CrUX? A: Use both, for different jobs. Lighthouse gives a quick lab pass you can run on every change, while CrUX field data shows what your real traffic experienced. Search engines ultimately judge field performance, so a tool that reports RUM metrics is worth the setup cost.
Q: Why is my CLS worse than my LCP after a redesign? A: Most layout shift comes from content arriving without reserved space. Give images and embeds explicit dimensions, avoid inserting anything above content that already exists, and let fonts keep their fallback metrics so text does not reflow when the real font arrives.
5406
you might also like...
The staged path from a slow WordPress site to a fast Next.js one, keeping Persian content, Persian URLs and search traffic intact.
The App Router and React Server Components are not just new APIs; they change where your code runs. Here is how they cut bundle size, simplified data fetching, and made my pages measurably faster.
Newer post
Moving from WordPress to Next.js: a migration guide for Persian websites
Older post
React Server Components vs. Client Components: When to Use Each


