Core Web Vitals are the three page experience metrics Google asks site owners to monitor: how fast the main content loads, how quickly a page reacts to a tap or click, and how stable the layout stays while it loads. This guide covers the core web vitals 2026 thresholds, the difference between lab and field data, the tools that report each, and a fix list organized by metric, with a worked example so you can see how a diagnosis actually flows.
Key takeaways
- The three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). The good targets are 2.5 seconds or less, 200 milliseconds or less, and 0.1 or less.
- A page passes only when the 75th percentile of real visits is good on all three metrics. One poor metric fails the whole assessment.
- Field data (real Chrome users over a rolling 28 days) is the verdict. Lab data (a single Lighthouse run) is for diagnosis.
- Google recommends good Core Web Vitals for success in Search, but describes them as one part of broader page experience, not a standalone ranking switch.
- Most failures trace back to a few causes: an unoptimized hero image, heavy JavaScript on the main thread, and images or embeds with no reserved space.
What Core Web Vitals measure
Each metric answers one plain question about a visit.
- LCP (loading): how long until the largest image, video or text block in the viewport has rendered. Typical LCP elements are a hero image, a poster frame, or a large heading block.
- INP (responsiveness): how long the page takes to show a visual response after clicks, taps and key presses, observed across the whole visit. The reported value is the longest interaction, excluding outliers.
- CLS (visual stability): how much visible content moves unexpectedly while the page loads or updates.
INP succeeded First Input Delay (FID). FID looked only at the delay before the first interaction. INP covers input delay, the time spent running event handlers, and the time until the browser paints the next frame, for every interaction. That is why a site can have passed FID comfortably and still struggle with INP.
Core web vitals 2026 thresholds
Google’s published targets, as shown in Search Console and PageSpeed Insights, are:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 seconds or less | Up to 4.0 seconds | Over 4.0 seconds |
| INP | 200 ms or less | Up to 500 ms | Over 500 ms |
| CLS | 0.1 or less | Up to 0.25 | Over 0.25 |
Each value is judged at the 75th percentile of page loads, split by mobile and desktop. In practice that means the slowest quarter of your real visits sets the grade. A page that loads in 2.0 seconds on your office fiber connection can still fail if a quarter of your mobile visitors wait longer than 2.5 seconds.
In Search Console, URLs are grouped with similar pages, and a group takes the worst status among its metrics for each device type. A group with good INP and LCP but poor CLS is reported as poor.
Field data versus lab data
This distinction causes more confusion than any threshold.
- Field data comes from the Chrome User Experience Report (CrUX) and reflects real visitors over a rolling 28-day collection period. It is what Search Console’s Core Web Vitals report uses, and it is the number that decides pass or fail.
- Lab data comes from Lighthouse, which runs one simulated load of a mid-tier mobile device on a mobile network, or an emulated desktop. It is reproducible and ideal for debugging, but it can miss real-world bottlenecks, and scores vary between runs.
If a page has too few samples, PageSpeed Insights falls back to origin-level data for the whole site, and if the origin lacks data too, no field data is shown. Low-traffic pages therefore often have no field verdict of their own.
Which tool answers which question
| Tool | Data type | Best for |
|---|---|---|
| Search Console, Core Web Vitals report | Field (CrUX) | Finding which groups of URLs fail, and tracking a fix through validation |
| PageSpeed Insights | Field and lab | Checking one URL: real-user numbers on top, Lighthouse diagnosis below |
| Lighthouse in Chrome DevTools | Lab | Tracing what blocks rendering or delays a response |
| web-vitals JavaScript library | Field (your own users) | Collecting real-user data on your site and sending it to your analytics |
A common trap is polishing the Lighthouse score while field data stays red. Lighthouse cannot see slow servers for distant visitors or weak mobile networks. Use field data to find the problem and lab data to reproduce it.
Worked example: reading a failing report
Example scenario: a local service company’s WordPress site shows its service-page group as Poor on mobile in Search Console. PageSpeed Insights for one of those URLs shows these illustrative field values at the 75th percentile: LCP 3.6 seconds, INP 160 ms, CLS 0.04.
- INP and CLS are already good, so the whole fix is about LCP.
- In DevTools, the Performance panel identifies the LCP element as the hero photo.
- Web.dev breaks LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. Suppose the photo shows a long load duration (it is a very large file) and a long load delay (it is discovered late, after CSS and scripts).
- The fixes follow from the diagnosis: compress and resize the photo, mark it as high priority, and make sure it is not lazy-loaded.
- After deploying, the lab test improves right away, but the Search Console group will not turn green until the 28-day window has rolled over.
The numbers above are invented for illustration. The workflow is the point: find the failing metric, find the element or script responsible, fix that, then wait for field data.
Fixing LCP
Web.dev recommends thinking of LCP as four subparts. Time to first byte should take roughly 40 percent of the total, resource load duration about 40 percent, and the two delay subparts (load delay and render delay) should each be under about 10 percent. Treat those as guidelines, not fixed millisecond budgets.
- Identify the LCP element first. You cannot optimize what you have not found. DevTools and PageSpeed Insights both name it.
- Do not lazy-load the LCP image. Web.dev states that lazy-loading it always adds unnecessary load delay.
- Raise its priority. Set fetchpriority=”high” on the one image most likely to be the LCP element. Using it on more than one or two images dilutes the effect.
- Preload when the browser discovers it late. If the image is referenced only from CSS or JavaScript, preload it in the HTML so it starts loading alongside the stylesheet.
- Shrink the file. Resize to the displayed dimensions and use a modern format such as WebP or AVIF.
- Speed up the first byte. Minimize redirects, use server-side caching and a CDN, and avoid unique URL parameters that stop CDN edge caching.
Fixing INP
Poor INP almost always means the main thread is busy when the visitor interacts. Web.dev splits an interaction into input delay, processing time and presentation delay, and each has its own remedy.
- Reduce input delay. Startup script parsing, compiling and execution create long tasks that make early taps wait. Ship less JavaScript and delay what is not needed at load.
- Keep event handlers short. Run only the logic needed for the next visual update inside the handler, and defer saving, analytics and similar work to a later task, for example with setTimeout.
- Avoid layout thrashing. Reading layout values right after changing styles in the same task forces synchronous layout.
- Keep the DOM small. Rendering cost grows with DOM size, and content-visibility can defer rendering of off-screen sections.
- Audit third-party scripts. Chat widgets, tag managers and embeds run on the same main thread. Remove the ones you cannot justify and load the rest later.
Web.dev advises finding slow interactions in field data first, then reproducing them in the lab. Expect to repeat that cycle.
Fixing CLS
CLS is the most mechanical of the three, because it is about reserving space before content arrives.
- Give every image and video dimensions. Set width and height attributes, or use the CSS aspect-ratio property, so the browser reserves the space.
- Reserve space for ads, embeds and iframes. Use a minimum height or aspect ratio, and keep the placeholder even when no ad loads.
- Do not inject content into the flow above what people are reading. Cookie bars and banners should overlay the page or occupy a slot that was reserved in advance.
- Tame font swapping. Choose a close fallback font, adjust fallback metrics, preload critical fonts, or consider font-display: optional.
- Animate with transform. Animating properties such as top and left causes shifts, while transform does not.
Do Core Web Vitals affect rankings?
Google’s documentation says: “We highly recommend site owners achieve good Core Web Vitals for success with Search,” and adds that this, along with other page experience aspects, aligns with what its core ranking systems seek to reward. It does not describe Core Web Vitals as a standalone ranking factor that overrides relevance. The sensible reading is that vitals are worth fixing because they improve the experience of the people you want to convert, and because they are part of what Google’s systems look at, but they will not rescue a page that does not answer the query. If you are budgeting a technical foundation, see how much SEO costs, and for AI answer surfaces read how to rank in Google AI Overviews.
A WordPress checklist
- Hosting and caching: a slow server limits every other fix. Use server-side page caching and a CDN to improve time to first byte.
- Images: compress, convert to a modern format, set dimensions, and exclude the hero image from lazy loading. Many lazy-load plugins and themes apply it to every image by default, so check the first image on each template.
- Plugins and theme: remove unused plugins and look for ones that load scripts on every page when they are needed on one. Page builders can add substantial markup and JavaScript.
- Third-party tags: review the tag manager container twice a year.
- Re-test by template: test one post, one service page, one category page and the homepage, since each fails for different reasons.
For a wider speed checklist, see how to speed up WordPress.
Common mistakes
- Chasing a 100 Lighthouse score while field data is poor.
- Testing only the homepage. Templates fail independently.
- Lazy-loading the hero image.
- Expecting immediate results in Search Console. Group metrics reflect the last 28 days, and validation starts a 28-day monitoring period.
- Fixing mobile and ignoring desktop, or the reverse. Both are reported separately.
Frequently asked questions
How long until Search Console shows my fix?
Plan on about four weeks. The report uses a 28-day window of field data, and after you click Start Tracking, Search Console monitors for 28 days before it considers the issue fixed.
Why does PageSpeed Insights show no field data for my page?
The page does not have enough real-user samples. PageSpeed Insights then shows origin-level data if it exists, and nothing if it does not. Use lab data to debug, and the web-vitals library if you want your own measurements.
Which metric should I fix first?
Whichever is poor in field data on your highest-value template. Fix that one first, then re-measure after the window turns over.
Sources
- Google Search Central: Understanding Core Web Vitals and Google search results
- Search Console Help: Core Web Vitals report
- PageSpeed Insights: About
- web.dev: Interaction to Next Paint
- web.dev: Optimize Largest Contentful Paint
- web.dev: Optimize Cumulative Layout Shift
If a technical review would help, you can get in touch with SSA Agency.