Core Web Vitals (CWV) are three page-speed metrics search engines use to measure real user experience. Many site owners have heard they affect rankings, but get stuck on another problem: they know the scores aren’t passing, but don’t know how to locate the issue in a real environment or how to actually pull the scores back up. This article gives you a data-driven diagnosis and fix checklist, breaking down LCP, CLS, and INP one by one, with directly implementable code and configuration.
Why is this worth doing seriously? Because slow pages hurt two things at once: rankings from search engines, and real-user retention and conversion. A page that takes three or four seconds to open — visitors close it before the content even appears, and all the traffic-driving and copywriting before that point is wasted. Pulling the metrics back to the passing line isn’t showing off — it’s actually catching the traffic you already have.
First, distinguish field data from lab data
A lot of optimization gets stuck halfway because the two types of data are confused. Lab data comes from local speed-testing tools — clean environment, ideal network — good for catching obvious problems during development. Field data comes from aggregated real-user devices — that’s the one rankings actually reference.
- Lab data: runs on a fixed machine, results stable and reproducible — used to find causes and watch trends.
- Field data: comes from massive real devices, including mid-low-end phones and weak networks — used to set targets and see impact.
- The two often disagree: LCP might be 2.1s in the lab but 3.8s in the field, because real users aren’t on flagship phones.
- Diagnosis order: first open Search Console’s Core Web Vitals report to see field scores; then use PageSpeed Insights to see lab details and locate specific elements.
The conclusion is straightforward: use lab data to find causes, use field data to set targets. Don’t assume everything’s fine online just because local scores look good.
LCP (Largest Contentful Paint): get the first-screen hero to appear fast
LCP measures when the largest element in the viewport (often a hero image, a title block, or a large image) finishes rendering. The passing line is 2.5 seconds. When it’s slow, users’ first impression is that the site is laggy.
- Large images not compressed: original 3000px-wide images uploaded directly, several megabytes. Switch to WebP or AVIF, export at display size.
- Key images not preloaded: add a preload line for the first-screen image, so the browser fetches it early.
- Fonts blocking render: users see blank space while text is invisible — feels even slower. Switch to font-display: swap and preload key fonts.
- Slow server response: first get TTFB under 600ms, then add edge caching — only then does LCP have room to drop.
For that LCP image on the first screen, adding a preload is most effective:
Code snippet: In the head, write link rel=”preload” as=”image” href=”hero.avif” — so the browser fetches this image while parsing HTML, instead of waiting until CSS or JS runs to initiate the request.
CLS (Cumulative Layout Shift): reserve space for every element that moves
CLS measures unexpected element movement during page load. The passing line is 0.1. An ad slot suddenly expanding and pushing the body down half a screen — this kind of jitter hurts trust the most.
- Images and videos must have fixed width and height, or declare aspect-ratio — otherwise content below gets pushed down when the image loads.
- Ad slots and embedded third-party frames need a fixed-height container reserved — don’t let them dynamically expand and squeeze other content.
- Avoid inserting new elements above existing content — like a delayed popup pushing the body down. This kind of jitter is most likely counted in CLS.
- For animations, prefer transform over changing top or left — reduces layout reflow triggers.
| Element | Wrong approach | Right approach |
|---|---|---|
| Image | No width/height, expands after load | Fixed width/height or aspect-ratio |
| Ad slot | Dynamically inserted, no height | Reserve fixed-height container |
| Popup | Loads and covers content from above | Delayed appearance or fixed position |
INP (Interaction to Next Paint): break up long tasks
INP replaced the old metric in March 2024. It measures the delay from each user click, tap, or keypress to when the screen responds. The passing line is 200ms. It’s the easiest to overlook, but it directly determines “does clicking do anything.”
- Main-thread long tasks are the culprit: a synchronous script over 50ms blocks all interactions, even scrolling stutters.
- Shard big loops — use idle callbacks or chunking, cutting a 200ms synchronous task into multiple 5ms micro-tasks.
- Defer non-critical third-party scripts until after page load, or use modular loading so the browser parses in parallel.
- Use the Performance panel’s “long tasks” waterfall on real devices to locate bottlenecks — don’t only look on desktop flagships.
- Give buttons instant feedback — even if the backend hasn’t responded yet, show a visual response first, and users’ perceived latency drops dramatically.
The chunking idea is straightforward: don’t process 10,000 records at once — process a small batch per frame, hand the rest to the next frame, and the main thread always has gaps to respond to users. For a concrete example: a search box that filters a list in real time as you type — if it synchronously iterates all 10,000 records on every keystroke, every keypress stutters on low-end phones. Change it to process only the first 500 per frame and continue the rest next frame, and typing stays responsive.
Quick reference for the three metrics’ passing lines
Before diagnosing, memorize the targets so you don’t push in the wrong direction. Below is a quick reference — field data takes the 75th percentile, meaning at least three-quarters of users must pass for it to count.
| Metric | Passing line | Measures | Most common cause |
|---|---|---|---|
| LCP | 2.5s | Largest content render | Large image uncompressed, not preloaded |
| CLS | 0.1 | Layout jitter | Images no width/height, ads expanding |
| INP | 200ms | Interaction response | Main-thread long task blocking |
Fix rhythm and verification
- First look at the worst device percentile (p75) in field data — don’t be fooled by average scores. A good average doesn’t mean low-end phones aren’t laggy.
- Change only one thing at a time, retest in lab, then wait about 28 days for field data to flow back before drawing conclusions — avoid misjudgment.
- Include Core Web Vitals in the pre-launch checklist, not fixing it after something goes wrong post-launch.
Run through the flow above, and LCP, CLS, and INP will all improve together — because they share the same foundation: faster server, smaller resources, shorter main-thread occupation.
