Core Web Vitals are three numbers that describe how a page feels to a real visitor. They measure how fast the main content shows, how fast the page reacts to a tap or click, and whether content jumps while the page loads. Google says its ranking systems use them. It recommends that site owners get them into the "good" range.
This guide is for site owners, not performance engineers. It explains what each metric means, how to read your scores, and the fixes that Google's Chrome team calls the most effective. You can give most of them to your developer as a short list.
What are Core Web Vitals?
Core Web Vitals are three metrics that measure real-world user experience. The current set and targets, from web.dev:
- Largest Contentful Paint (LCP) measures loading. It is the time until the largest content element in the visible area shows, usually a hero image or a large block of text. Target: 2.5 seconds or less.
- Interaction to Next Paint (INP) measures responsiveness. It is how long the page takes to show a visible response after a click, tap or key press. Target: 200 milliseconds or less.
- Cumulative Layout Shift (CLS) measures visual stability: how much visible content moves unexpectedly. Target: 0.1 or less.
INP is the newest of the three. It replaced First Input Delay (FID) on March 12, 2024. If an older guide or plugin still talks about FID, it is out of date.
The 75th percentile rule
A page passes when it meets all three targets at the 75th percentile of page loads, measured separately for mobile and desktop (web.dev). In plain English: at least three out of four real visits must have a good experience. A fast test on office Wi-Fi does not count if most of your customers use older phones.
Search Console puts every URL group into one of three statuses. These ranges come from the Core Web Vitals report help page:
- LCP: good 2.5 s or less, need improvement 4 s or less, poor over 4 s.
- INP: good 200 ms or less, need improvement 500 ms or less, poor over 500 ms.
- CLS: good 0.1 or less, need improvement 0.25 or less, poor over 0.25.
A URL group gets the status of its worst metric. Good LCP with poor CLS is still "Poor."
How much do Core Web Vitals matter for SEO?
Google's page experience documentation says Core Web Vitals are used by its ranking systems. It also says good scores do not guarantee top rankings, and that "trying to get a perfect score just for SEO reasons may not be the best use of your time." Google always tries to show the most relevant content, even if the page experience is weak. But for many queries there is a lot of helpful content, and there a good page experience can help.
So treat Core Web Vitals as one important check, not the only one. Get your pages out of "Poor," then go back to content and the rest of technical SEO.
Step 1: Find out where you stand
There are two kinds of data. Know the difference.
Field data comes from real Chrome users, through the Chrome User Experience Report (CrUX). It powers:
- Search Console's Core Web Vitals report. It groups similar URLs and shows the value that 75% of visits met or beat over the last 28 days, for mobile and desktop.
- PageSpeed Insights (pagespeed.web.dev). Enter a URL to see its real-user data (when there is enough) and a lab test with suggestions.
Lab data comes from a simulated test, such as Lighthouse. It helps you find causes and check a fix before release. But web.dev says it is not a substitute for field data. A lab test cannot measure INP, because no real person clicks. It shows Total Blocking Time (TBT) as a stand-in.
If Search Console shows "No data available," your property is new or CrUX does not have enough data for your site yet. Use lab tests until it does.
Prioritize the way Google suggests
Search Console's help page gives an order of work. Fix everything labeled Poor first. Then fix the issues that affect the most URLs or your most important URLs. "Need improvement" is less important than "Poor." Search Console groups similar URLs, so one fix to a shared template (for example, every product page) can improve the whole group.
Step 2: Fix LCP (slow loading)
The Chrome team says LCP is the metric developers struggle with most. Its guide to the most effective fixes (last updated October 2024) says 40% of sites in the Chrome UX Report do not meet the LCP target. It also cites the 2024 Web Almanac: 73% of mobile pages have an image as their LCP element. So on most sites, to fix LCP you fix how the main image loads.
Make the main image easy to find and load it first
- Use a normal <img> tag with src or srcset for the hero image. Do not use attributes like data-src that need JavaScript before the image can start to download.
- Do not lazy-load the main image. loading="lazy" is good for images lower on the page. On the hero image it delays the download. Many themes and plugins add it to every image, so check.
- Add fetchpriority="high" to the hero image. The browser then downloads it before less important files.
- Render pages on the server where you can. If JavaScript builds the page in the browser, the browser cannot find the image until that script runs.
Make the image smaller
Compress the hero image and serve it at the size it shows on screen. A photo from a camera or a stock site is often much larger than a phone screen needs. Most CMSs and image plugins can resize and compress images for you. Search Console's help page also gives a rule of thumb: keep a page and all its resources under 500 KB, and use no more than 50 resources for the best mobile performance.
Speed up the server's first response
Nothing loads until the server sends the first byte of HTML (Time to First Byte, or TTFB). The Chrome team recommends a CDN, which serves and caches your pages close to your visitors. Even if you cache HTML for only a few minutes, it can help when your content does not change every second. On shared hosting, better caching or better hosting often gives the biggest gain.
Check fonts and render-blocking files
If your LCP element is text, a slow web font can delay it. A font-display value other than auto or block keeps text visible while the font loads. Large CSS and JavaScript files at the top of the page can also delay everything. Defer what the first screen does not need.
Step 3: Fix INP (slow reactions to clicks and taps)
INP is about the moment a visitor taps "Add to cart" and nothing seems to happen. web.dev's INP guide splits every interaction into three parts: the input delay before the page starts to handle the tap, the processing time of the code that runs, and the presentation delay before the screen updates. A common cause is JavaScript that keeps the browser busy.
Cut unnecessary JavaScript
- Audit plugins, widgets and tags. Chat widgets, sliders, pop-up builders, review carousels and old marketing tags all add script. Remove what you do not use. If you use a tag manager, the Chrome team recommends that you remove old tags from time to time.
- Use the Coverage tool in Chrome DevTools (or ask your developer to) to find code that loads but does not run.
- Load code only where you need it. A booking widget on one page does not need to load on every page.
Break up long tasks
The browser cannot react to a tap while it is busy with a big piece of work. A task longer than 50 milliseconds is a "long task." The Chrome team's fix is to split long tasks into smaller pieces and "yield" between them, so the browser can respond to the visitor. Ask your developer for it by name.
Keep pages lean
The Chrome team also recommends a small DOM (the page's HTML structure). On a very large page, every screen update takes more work. Large menus and long product grids are examples to check.
Step 4: Fix CLS (content that jumps)
The Chrome team says CLS is the metric most sites do well on, but about a quarter of sites still miss the target.
Give every image and embed a size
Images with no size are a common cause. The Chrome team found that 66% of pages have at least one image with no size. Without a size, the browser reserves no space, then pushes content down when the image arrives. The fix: add width and height attributes (or the CSS aspect-ratio property) to every image and video, and reserve space for iframes.
Reserve space for ads, embeds and banners
web.dev calls ads one of the largest causes of layout shifts on the web. If you do not know the exact size of an ad or embed, give its container a sensible min-height. The jump is then smaller. Show cookie notices and promo bars as an overlay, or reserve their space before they appear. Do not let them push the page down. If you animate them, animate CSS transform, not top or left.
Control web fonts
When a custom font replaces a fallback font of a different size, text reflows and the page shifts. These steps help: preload key fonts, use font-display: optional, or adjust the fallback font to match the size of the web font.
Let the browser restore pages instantly
The back/forward cache (bfcache) lets the browser show a page instantly when someone clicks Back. This helps both loading and layout stability. A page can lose this benefit if the server sends it with Cache-Control: no-store or if it uses unload event listeners. Chrome DevTools has a bfcache test that shows why a page is not eligible.
Step 5: Confirm the fix
After you deploy the changes:
- Test again in PageSpeed Insights and check that the lab results are better.
- Click "Start Tracking" on the issue in Search Console's Core Web Vitals report. Search Console then checks real-user data for 28 days. If no URL has the issue in that time, the issue counts as fixed.
- Expect a slow change. Field data covers the last 28 days, so improvements show gradually.
If many pages change status when you changed nothing, Search Console's help page points to site-wide causes. Examples are a large traffic increase or a slower image server that pushes borderline pages over the limit.
A quick Core Web Vitals checklist
- The hero image uses a plain <img> tag, is not lazy-loaded, and has fetchpriority="high".
- Images are compressed and sized for the screen.
- Pages are cached, ideally on a CDN.
- Unused plugins, widgets and tracking tags are removed.
- Every image, video, iframe and ad slot has reserved space.
- Banners and pop-ups do not push content down.
- Fonts load without big shifts.
- Fixes are validated in Search Console.
Questions people ask
What are good Core Web Vitals scores?
Google's targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Google measures them at the 75th percentile of real page loads, separately for mobile and desktop.
Do Core Web Vitals affect Google rankings?
Google says its ranking systems use Core Web Vitals. It also says good scores do not guarantee top positions, and that a perfect score just for SEO may not be the best use of your time.
Why does PageSpeed Insights show different numbers from Search Console?
Search Console groups similar URLs and shows the real-user data of the group over the last 28 days. PageSpeed Insights tests one URL and adds a lab test, so the numbers can differ.
What happened to First Input Delay (FID)?
Interaction to Next Paint (INP) replaced FID as the Core Web Vital for responsiveness on March 12, 2024. INP looks at clicks, taps and key presses during the whole visit, not only the first one.
My site has no Core Web Vitals data. What now?
Field data only appears when enough Chrome users visit a page. Until then, use a lab test such as Lighthouse or PageSpeed Insights. A lab test measures LCP and CLS, and uses Total Blocking Time as a stand-in for INP.
Page speed is one part of an audit
Core Web Vitals are only one part of technical SEO. An SEOSFT audit crawls your site for ten checks, such as indexability, structured data, site structure and AI search access. Its page speed check tests your homepage and key pages on mobile with PageSpeed Insights. It uses real-user Core Web Vitals when Google has them, and a lab test when it does not. All problems from all checks go into one list, ranked by their effect on Google Search, then by effort.
Sources
- web.dev, Web Vitals: https://web.dev/articles/vitals
- web.dev, The most effective ways to improve Core Web Vitals: https://web.dev/articles/top-cwv
- web.dev, Optimize LCP: https://web.dev/articles/optimize-lcp
- web.dev, Optimize INP: https://web.dev/articles/optimize-inp
- web.dev, Optimize CLS: https://web.dev/articles/optimize-cls
- web.dev, INP becomes a Core Web Vital on March 12: https://web.dev/blog/inp-cwv-launch
- web.dev, Back/forward cache: https://web.dev/articles/bfcache
- Google Search Central, Core Web Vitals: https://developers.google.com/search/docs/appearance/core-web-vitals
- Google Search Central, Page experience: https://developers.google.com/search/docs/appearance/page-experience
- Search Console Help, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520