You tap a link and the page jumps at the last second, so you hit the wrong thing. Or you land on a page and stare at a blank space where the main picture should be. Visitors notice this straight away, and Google measures it with three numbers called Core Web Vitals.
This guide explains what they are, what a good score looks like, and the fixes that usually make the biggest difference. There are a few notes for WordPress sites too, since that is where many of us end up fixing these things.
By the ClearAITools team · Last updated October 25, 2026
Quick answer: Core Web Vitals are three measurements of what real visitors experience. LCP is how quickly the main content appears, INP is how fast the page reacts when someone taps or clicks, and CLS is how much the layout jumps around. A page passes when at least 75% of visits get a “good” result on all three: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less.
The three metrics and what counts as good
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading speed | 2.5 s or less | 2.5 – 4 s | over 4 s |
| INP (Interaction to Next Paint) | Responsiveness | 200 ms or less | 200 – 500 ms | over 500 ms |
| CLS (Cumulative Layout Shift) | Visual stability | 0.1 or less | 0.1 – 0.25 | over 0.25 |
Two details trip people up. First, Google judges these at the 75th percentile of real visits, so it is not enough that the page feels fast on your own laptop. A quarter of your visitors can be on slower phones and weaker connections and the page still needs to hold up. Second, INP replaced the old First Input Delay (FID) metric in March 2024. If a guide still lists FID as a Core Web Vital, it is out of date.
Do Core Web Vitals really affect your Google ranking?
Yes, but keep it in proportion. They are part of Google’s page experience signals, and Google’s own documentation says great content still matters more than a perfect score. A page that answers the question best can rank even with mediocre vitals.
So think of them as a tiebreaker and as protection. When two pages are equally useful, the faster and steadier one has the edge. And whatever your ranking is, slow or jumpy pages lose visitors, which is the bigger cost for most sites.
LCP: how fast does the main content show up?
LCP is the moment the largest visible element finishes rendering. That element is usually a hero image, a featured image or a big block of heading text. To fix it, first find out what it is. In PageSpeed Insights, scroll to the diagnostics and look for “Largest Contentful Paint element”.
The time it takes is made of four parts: how long the server takes to respond, how long the browser takes to discover the image, how long it takes to download, and how long it waits before painting it. Most fixes attack one of those.
1. Don’t lazy-load the main image
Lazy loading is great for images far down the page. It is a mistake for the one at the top. Some plugins lazy-load every image by default, including the hero. Tell the browser the opposite for that one image:
<img src="hero.webp" width="1200" height="630"
alt="Describe the image" fetchpriority="high" loading="eager">2. Preload it if it is set in CSS
If the picture is a CSS background, the browser only finds it after the stylesheet loads, which is late. A preload hint fixes that:
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">3. Send a smaller file
Use WebP or AVIF, compress it, and export it at the size it is actually shown. A 3000-pixel-wide photo displayed in a 600-pixel slot wastes bandwidth. Use srcset so phones get a smaller version than desktops.
4. Speed up the server
If the server is slow to respond, nothing else can make up for it. Page caching, decent hosting and a CDN usually help the most. On WordPress, a caching plugin and fewer heavy plugins are the first things to check.
5. Don’t build the image with JavaScript
Images that only appear after a script runs, like many sliders and carousels, are discovered late. Plain HTML <img> tags are the fastest option.
CLS: why does the page jump around?
CLS adds up every unexpected layout shift while the page loads. Anything that appears late and pushes content down or sideways counts. The usual suspects are below.
| Cause | Fix |
|---|---|
Images without width and height | Always set both, or reserve space with CSS aspect-ratio |
| Ads and embeds that load late | Give the slot a fixed or minimum height before the ad arrives |
| Web fonts swapping in | Use font-display: swap and preload your main font |
| Banners injected above the content, such as cookie notices | Overlay them (fixed position) instead of pushing the page down |
| Content added by JavaScript | Reserve its space with a placeholder |
/* Keep the space reserved while the image loads */
.card img { width: 100%; height: auto; aspect-ratio: 16 / 9; }
/* Reserve room for an ad slot so nothing jumps when it fills */
.ad-slot { min-height: 280px; }If you plan to show ads, the ad slot rule matters a lot. Ads that arrive after the text are one of the most common causes of poor CLS on content sites.
INP: does the page react quickly?
INP watches every tap, click and key press during a visit and reports a result close to the slowest one. A page can load quickly and still feel sluggish if the browser is busy running JavaScript when you try to use it.
That is why images are rarely the main cause of INP problems. The usual culprits are heavy scripts, especially third-party ones such as chat widgets, tag managers, ad scripts and analytics, plus big pages with lots of elements and event handlers that do too much work.
- Remove what you do not use. Every plugin and script adds work. Deleting an unused one beats optimizing it.
- Load third-party scripts later. Use
defer, or load non-essential widgets after the first interaction. - Keep click handlers light. Show feedback immediately (a spinner, a changed button) and do the heavy work afterwards.
- Break up long tasks. Split big jobs into smaller chunks so the browser can respond in between.
// Process a big list in small slices so the page stays responsive
async function processAll(items) {
for (let i = 0; i < items.length; i++) {
handle(items[i]);
if (i % 50 === 0) await new Promise(r => setTimeout(r, 0)); // give the browser a turn
}
}How to measure your scores
- PageSpeed Insights: the top section shows field data from real Chrome users, and the lower section is a lab test. Trust the field data first.
- Google Search Console: the Core Web Vitals report groups your pages into good, needs improvement and poor, so you can fix whole templates at once.
- Chrome DevTools: the Performance panel shows the LCP element and long tasks on your own device.
Be patient after a fix. Field data is collected over a rolling window of about four weeks, so a real improvement can take a while to show up in the report even though the lab test changes immediately.
A sensible order of work for a WordPress site
- Run PageSpeed Insights on your homepage and one article, on mobile, and note which metric fails.
- Fix the LCP image: right size, WebP,
fetchpriority="high", no lazy loading on that one. - Add width and height to images and reserve space for ads and embeds.
- Turn on page caching and check that you are not running plugins you no longer need.
- Delay or remove third-party scripts that are not earning their place.
- Test again, then check Search Console in a month.
Frequently asked questions
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024. It looks at all interactions during a visit, not only the first.
Do I need a perfect PageSpeed score of 100?
No. The goal is to pass the three Core Web Vitals for most real visitors. A lab score of 100 is nice but not required.
Do Core Web Vitals apply to mobile and desktop?
Both, and they are assessed separately. Mobile is usually harder because phones have slower processors and networks, so start there.
Why does my score change from one test to the next?
Lab tests vary with server load, network conditions and the device used. That is why field data from real visits is the more reliable guide.
How long until I see results after fixing something?
Lab tests update instantly, but the field data behind Search Console is gathered over about 28 days, so give it a few weeks.
Keep reading: PageSpeed tips to push your score above 90 · How to reduce image file size