Core Web Vitals explained in one paragraph: they are three measurements Google uses to describe how your page feels to a real visitor. One measures how long until the main content appears, one measures how quickly the page responds when someone taps or clicks, and one measures how much the layout jumps around while loading. That is the whole concept.
They matter for two reasons. They are part of how Google ranks pages, and more directly, they describe the experience that decides whether a visitor stays. A page that looks broken for three seconds loses people regardless of rankings.
The three metrics, without the jargon
Largest Contentful Paint — how fast the page looks ready
LCP measures the time until the biggest visible element in the viewport has rendered. Usually that is your hero image, a heading, or a video poster frame. It is a reasonable proxy for the moment a visitor thinks “the page has loaded”.
Good: 2.5 seconds or less. Needs work: 2.5 to 4 seconds. Poor: over 4 seconds.
What makes it bad: an enormous unoptimized hero image, a slow server response, render-blocking CSS and JavaScript in the head, web fonts that delay text, or a slider that loads six images when it displays one.
Interaction to Next Paint — how fast the page responds
INP measures the delay between a visitor interacting with your page and the page visibly reacting. Click a menu, tap a button, open an accordion. If the browser is busy running JavaScript, nothing happens for a moment, and the visitor taps again thinking it failed.
Good: 200 milliseconds or less. Needs work: 200 to 500 milliseconds. Poor: over 500 milliseconds.
What makes it bad: too much JavaScript running on the main thread, heavy page builder scripts, chat widgets, multiple tracking and analytics tags, and plugins that initialise everything on every page whether or not it is used.
Cumulative Layout Shift — how much the page jumps
CLS measures unexpected movement of content while the page loads. You go to click a link, an image above it finishes loading, the link moves, and you click an ad instead. That is layout shift, and it is the one visitors find most irritating.
Good: 0.1 or less. Needs work: 0.1 to 0.25. Poor: over 0.25.
What makes it bad: images and embeds without width and height set, ads or banners injected above existing content, late-loading web fonts that resize text, and cookie notices or announcement bars that push the page down after it has rendered.
The three at a glance
| Metric | Plain-English question | Good | What usually causes a bad score |
|---|---|---|---|
| LCP | How long until it looks loaded? | ≤ 2.5s | Huge hero images, slow server, blocking CSS |
| INP | How fast does it react to a tap? | ≤ 200ms | Too much JavaScript, heavy builders, chat and tracking scripts |
| CLS | How much does it jump? | ≤ 0.1 | Images without dimensions, injected banners, late fonts |
Lab data versus field data, and why your score disagrees with itself
This confuses almost everyone, so it is worth being precise.
Lab data comes from a single simulated test on a specified connection and device. Running a page speed tool gives you this. It is useful because it is repeatable and it tells you what to fix.
Field data comes from measurements collected from real visitors on real devices and connections. This is what Google uses for ranking purposes, and it is reported across a rolling window, so it lags behind changes you make.
That is why you can fix things, see your lab score jump immediately, and watch the field data take weeks to move. Both are correct. Use lab data to diagnose and verify fixes, and field data to judge whether the site is actually better for visitors.
One more thing: field data is segmented by mobile and desktop, and mobile is usually much worse. Most sites that fail Core Web Vitals fail on mobile while passing on desktop. Check mobile first.
What actually moves each metric on a WordPress site
To improve LCP
- Compress and resize the hero image. Serve it in a modern format, at the dimensions it is actually displayed, and preload it so the browser fetches it early.
- Fix the server response. Page caching, a current PHP version, and hosting that is not oversubscribed. If time to first byte is already high, nothing on the front end will save you.
- Stop CSS and JavaScript from blocking the render. Inline the small amount of CSS needed for the top of the page and defer the rest.
- Serve static assets from a CDN so images, CSS and fonts come from a location near the visitor.
- Remove the slider. Sliders are the most reliable LCP problem on business sites, and they rarely earn their cost.
To improve INP
- Cut the number of scripts. Audit what loads on every page and remove anything whose value you cannot name.
- Load third-party widgets late or on interaction. Chat widgets and video embeds do not need to initialise before the visitor has scrolled.
- Stop plugins loading site-wide. A contact form plugin should load its assets on the contact page, not on every blog post.
- Consolidate tracking. Multiple analytics and pixel scripts each compete for the main thread.
- Reconsider heavy builder add-ons. Some single add-ons load more JavaScript than the rest of the page combined.
To improve CLS
- Set explicit width and height on every image and iframe. This reserves the space before the asset arrives and fixes the majority of CLS problems by itself.
- Reserve space for anything injected. Banners, notices and ads should occupy a defined area from the start rather than appearing and pushing content down.
- Preload fonts and set a sensible font-display value so text does not resize when the web font finally loads.
- Avoid inserting content above existing content after the page has rendered.
- Test on a throttled mobile connection, where the gaps between assets arriving are long enough to see the shifts happen.
How to check your own site in ten minutes
- Pick your three highest-value pages: homepage, main service page, and your best-performing blog post.
- Run each through a page speed tool and record LCP, INP and CLS for mobile, not desktop.
- Check the field data section if your site gets enough traffic to have any.
- Write down which of the three metrics fails, per page.
- Work the matching fix list above for the failing metric only. Do not optimise what is already passing.
- Re-test after each change, so you know what worked.
What not to chase
A single overall performance score is a summary, not a target. Pushing a number from 88 to 94 on a lab test often involves tradeoffs that make the page worse for actual visitors.
The questions worth answering are narrower: does the main content appear in under 2.5 seconds on a phone, does the page react immediately when tapped, and does it hold still while loading. If the answer to all three is yes, you are done, whatever the composite score says.
Equally, do not treat Core Web Vitals as the whole of SEO. They are one input among many, and a fast page with nothing worth reading will not rank. They matter most as the difference between a visitor who converts and one who leaves before your hero image finishes loading.
Start with your three key pages on mobile. Find which single metric is failing, fix that one, and re-measure. If you want the diagnosis and the fixes handled in one pass with before-and-after numbers, that is what the Website Optimization Sprint page covers.