Core Web Vitals Test

Metrics and thresholds

Google assesses a page's experience using the 75th percentile of visits (p75): if at least 75% of visits fall within the “good” threshold, the metric is good. The thresholds are the values from Google's web.dev documentation.

How to fix LCP, INP and CLS problems: example scenarios

For each metric you'll first see the short answer, then how the problem looks to a visitor (left) and the fixed version (right); the thin line under the previews shows elapsed time. The same explanations also appear in the results for every metric and finding that comes out problematic in your measurement.

• How do you fix LCP?
• How do you fix INP?
• How do you fix CLS?
• How do you fix FCP?
• How do you fix TTFB?

How do you fix LCP?

Symptom: The main content appears late

LCP (Largest Contentful Paint) is the time it takes for the largest image or text block on the page to appear on screen. It's considered good if it's 2.5 seconds or less for 75% of real visits, and poor above 4 seconds. To fix LCP, shrink the main image and load it with priority, speed up the server response, and reduce render-blocking CSS/JavaScript files.

What does a visitor experience when LCP is high?

The visitor opens the page; the menu and header appear, but the page's main image or large headline sits as an empty box for a while. A wait of more than 4 seconds makes the page feel “slow” and drives visitors back.

Why is LCP high?

Usually a large, uncompressed main image, a slow server response, the main image being discovered late (lazy loading, CSS background) and blocking CSS/JavaScript files at the top of the page.

Step-by-step fix

1. Shrink the main image and convert it to WebP or AVIF; don't send it larger than it's displayed.
2. Add fetchpriority="high" to the main image and don't give it loading="lazy".
3. Put the image directly in the HTML with an <img> tag; don't add it later as a CSS background or with JavaScript.
4. Speed up the server response (page cache, CDN) and reduce blocking CSS/JavaScript at the top of the page.

How do you fix INP?

Symptom: Taps get a delayed response

INP (Interaction to Next Paint) measures how long the page takes to respond visually to a visitor's clicks, taps and key presses; it replaced FID in March 2024. 200 milliseconds or less is good, and above 500 milliseconds is poor. To fix INP, break up long JavaScript tasks, remove unnecessary third-party code and give visual feedback first when something is clicked.

What does a visitor experience when INP is high?

The visitor taps “Add to cart”, but the screen stays frozen for half a second. They can't tell whether the tap registered, so they tap again or give up.

Why is INP high?

Usually heavy JavaScript that keeps the phone's processor busy, third-party code such as ads and analytics, click handlers that do too much at once, and an overly crowded page structure (DOM).

Step-by-step fix

1. Respond visually first when something is clicked (button color, a loading indicator), then do the heavy work.
2. Break long JavaScript tasks into small chunks so the browser can respond to taps in between.
3. Remove unused scripts and unnecessary third-party code, and start the rest after the page has loaded.
4. Reduce the number of elements on the page: paginate long lists and build the contents of hidden menus only when needed.

How do you fix CLS?

Symptom: Content jumps around

CLS (Cumulative Layout Shift) is a score that shows how much content shifts unexpectedly while the page loads and is used. 0.1 or less is good, and above 0.25 is poor. To fix CLS, give images a width and height, reserve space for ads and banners in advance, and don't add elements that push content down later.

What does a visitor experience when CLS is high?

Just as the visitor is about to tap a button, an ad or image loads above it; the content shifts down and their finger lands on something else, often the ad. Text jumping while someone reads causes the same frustration.

Why is CLS high?

Usually images without a specified width and height, ads, banners or cookie notices added later, and late-loading web fonts that re-flow the text.

Step-by-step fix

1. Give every image and video a width and height, or set an aspect-ratio in CSS.
2. Reserve space for ads, banners and embeds up front: a fixed-height box that fills when the content arrives.
3. Show elements like cookie notices and announcement bars pinned to the bottom of the screen instead of pushing content.
4. Use a fallback font with matching metrics for web fonts, and use transform instead of top/left in animations.

How do you fix FCP?

Symptom: The screen stays blank for a long time

FCP (First Contentful Paint) is the moment a visitor opening the page sees the first text or image on screen. 1.8 seconds or less is good, and above 3 seconds is poor; it isn't part of Core Web Vitals, but it's an early sign of a slow LCP. To fix FCP, speed up the server response and reduce render-blocking CSS/JavaScript files at the top of the page.

What does a visitor experience when FCP is high?

The visitor opens the address and stares at a white screen for a few seconds, unsure whether the page is loading at all. The longer this lasts, the more people leave.

Why is FCP high?

Usually a slow server response, render-blocking CSS/JavaScript files loaded at the top of the page, and web fonts that hide text.

Step-by-step fix

1. Shorten the server response time (page cache, CDN).
2. Put the small amount of CSS needed for the first screen inside the HTML and load the rest later.
3. Add defer to JavaScript files and remove unused plugins and libraries.
4. Use font-display: swap for web fonts so text shows even before the font arrives.

How do you fix TTFB?

Symptom: The server responds slowly

TTFB (Time to First Byte) is the time between the browser requesting the page and the first byte arriving from the server. 0.8 seconds or less is good, and above 1.8 seconds is poor; this wait is added directly to FCP and LCP. To fix TTFB, use a page cache and a CDN, and reduce slow database queries and redirect chains.

What does a visitor experience when TTFB is high?

The browser requests the page, but the server “thinks” for a long time before sending the first byte of its response. This wait passes with nothing on screen and is added to both LCP and FCP.

Why is TTFB high?

Usually pages that are rebuilt on every visit (no caching), slow database queries, heavy plugins, servers far from visitors and redirect chains.

Step-by-step fix

1. Use a page cache so the page isn't rebuilt on every visit (in WordPress, a caching plugin is enough).
2. Reduce slow database queries and unnecessary plugins; upgrade your hosting plan if it isn't enough.
3. Use a CDN that serves from locations close to your visitors.
4. Remove redirect chains: links should go straight to the final address (one step instead of http → https → www).

Field data and lab data

Field data (Chrome UX Report) is the experience of real visitors over the last 28 days and is the data Google uses; it doesn't exist without enough traffic. Lab data (Lighthouse) is a single simulated load: it shows where the problem is and lets you test a fix right away, but it can't measure interaction metrics like INP (Total Blocking Time is used instead).

Frequently asked questions

Why do field data and lab data differ?

Field data (CrUX) is the experience of Chrome users who actually opened your page over the last 28 days, across different devices, connections and interactions; it's the data Google uses to assess page experience. Lab data is a single load with one simulated device and connection (slow 4G and a mid-range phone on mobile); it's for finding problems and testing fixes right away.

How much do Core Web Vitals affect rankings?

Page experience is one of the signals Google uses, but it doesn't outweigh relevance and content quality: a slow but excellent answer can rank above a fast but weak one. Still, good Core Web Vitals directly improve user experience and conversions, and they can make the difference between pages of similar quality.

Why do some pages have no real-user data?

The Chrome User Experience Report only publishes data for public pages that get enough visits. If there's no URL-level data, site-wide (origin) data is shown; if there's none of that either, only the lab measurement is available.

What does it take for the assessment to “Pass”?

The 75th percentile values of LCP, INP and CLS must all be within the “good” threshold; in other words, at least 75% of visits must have a good experience. A metric without data isn't included in the assessment.

Why does the measurement take 20–60 seconds?

Google's servers open your page in a real Chrome browser and run a Lighthouse audit. Results for the same address are served from cache for 10 minutes, so after publishing a change, wait that long before measuring again.

For the page's HTML weight, use the HTML Size Analyzer; for image sizes and formats, use the Image SEO Checker.

Last updated: October 10, 2026