
- Core Web Vitals measure loading (LCP), responsiveness (INP) and visual stability (CLS).
- Good thresholds: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less, measured at the 75th percentile of real visits.
- Most problems come from heavy images, too much JavaScript, third-party tags and layout that shifts while loading.
What are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure the real-world experience of a web page: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. They are part of the page experience signals Google considers, and more importantly they reflect whether visitors find your site fast and pleasant to use.
What is LCP?
Largest Contentful Paint (LCP) measures how long the largest image or text block in the visible part of the page takes to appear. Google's web.dev guidance counts an LCP within 2.5 seconds as good, measured at the 75th percentile of page loads on mobile and desktop.
What is INP?
Interaction to Next Paint (INP) measures how quickly the page visibly responds when someone clicks, taps or types, across the whole visit. According to web.dev, a page should have an INP of 200 milliseconds or less, measured at the 75th percentile of page loads.
What is CLS?
Cumulative Layout Shift (CLS) measures how much visible content jumps around unexpectedly while the page loads and is used. web.dev says pages should keep CLS at 0.1 or less, measured at the 75th percentile, so text and buttons stay where visitors expect them.
What scores count as good?
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP | How long the largest visible element takes to render | ≤ 2.5 s | > 4 s |
| INP | How quickly the page responds to clicks, taps and key presses | ≤ 200 ms | > 500 ms |
| CLS | How much the layout jumps while the page loads | ≤ 0.1 | > 0.25 |
Google assesses these at the 75th percentile of real visits, separately for mobile and desktop. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024.
How do I measure them?
- Field data: the Core Web Vitals report in Google Search Console and the real-user section at the top of PageSpeed Insights show data from real Chrome users.
- Lab data: Lighthouse and the PageSpeed Insights lab test simulate a load on a mid-range phone. They are great for debugging, but field data is what counts.
How do I fix a slow LCP?
The LCP element is usually a hero image, a video poster or a large heading. To speed it up:
- Serve images in modern formats (WebP or AVIF) at the right size for each screen, using
srcset. - Do not lazy-load the hero image; give it
fetchpriority="high"instead. - Reduce render-blocking CSS and JavaScript, and inline critical CSS where it makes sense.
- Preload the main web font and use
font-display: swap. - Improve server response time with page caching, a CDN and decent hosting.
How do I fix a poor INP?
INP suffers when the browser's main thread is busy running JavaScript, so the page cannot react to a tap. Common fixes:
- Remove unused scripts, plugins and apps, especially chat widgets, heatmaps and old tracking tags.
- Delay non-essential third-party scripts until after the page is interactive or until the user interacts.
- Break long tasks into smaller pieces and avoid heavy work inside click handlers.
- Keep the DOM lean; very large pages with thousands of elements are slower to update.
How do I fix CLS?
Layout shift happens when something appears or resizes after the page has started rendering. Fix it by:
- Always setting
widthandheight(or an aspect ratio) on images, videos and iframes. - Reserving space for banners, cookie notices and embeds before they load.
- Avoiding inserting content above existing content, except in response to a user action.
- Using font loading strategies that limit text reflow.
Platform-specific tips
WordPress: audit plugins, use a proper caching plugin and image optimization, and avoid loading every builder asset on every page. Shopify: review installed apps and remove leftovers from uninstalled ones, compress images and limit heavy sliders. Webflow and Framer: watch large background videos, unoptimized images, heavy interactions and third-party embeds.
How long until improvements show?
Lab scores change as soon as fixes go live. Field data in Search Console is based on a rolling 28-day window of real visits, so expect several weeks before the report fully reflects your improvements.
Need help?
Soft IT Land's speed and Core Web Vitals service finds the real causes, fixes them in the code and reports before-and-after numbers. If your site also needs ongoing care, see our maintenance plans.
Frequently asked questions
Do Core Web Vitals affect Google rankings?
Yes, as part of the page experience signals Google's ranking systems consider, but relevance and helpful content still matter more. A page with average vitals can outrank a faster page that answers the question less well. Treat good Core Web Vitals as a way to keep visitors and convert them, with a ranking benefit on top.
Why is my PageSpeed Insights score different every time I test?
The lab score comes from a single simulated load, so server response time, third-party scripts, ads and network conditions change the result from run to run. Read the real-user field data at the top of the report first, and when you use the lab score, compare several runs of the same URL rather than one.
Why does Search Console say there is not enough data for my pages?
The Core Web Vitals report only covers URLs with enough real Chrome visits. Low-traffic pages may have no field data of their own, so Search Console groups similar URLs and PageSpeed Insights may show data for the whole origin instead. Use lab tests to improve those pages until the traffic grows.
What is CLS in Core Web Vitals?
CLS, or Cumulative Layout Shift, is the Core Web Vital for visual stability. It scores how far content moves without the visitor causing it, such as text pushed down by a late-loading image, ad, embed or cookie banner. Reserving space with width and height attributes and loading fonts carefully keeps it at or below the 0.1 target.
Should I fix mobile or desktop first?
Mobile, in most cases. Google indexes the mobile version of your site, and mobile visitors usually have slower devices and networks, so problems show up there first and hurt the most. Fixes made for mobile almost always improve desktop as well.
Last updated