Core Web Vitals are three Google metrics based on real users' experience: LCP measures how long the main content takes to appear (good: 2.5 seconds or less), INP measures how quickly the page responds when you interact with it (good: 200 milliseconds or less) and CLS measures how much the content shifts while it loads (good: 0.1 or less). Google evaluates them with data from real visitors at the 75th percentile, separately for mobile and desktop.
- Good LCP: 2.5 s or less; needs improvement up to 4 s; poor above 4 s.
- Good INP: 200 ms or less; needs improvement up to 500 ms; poor above 500 ms.
- Good CLS: 0.1 or less; needs improvement up to 0.25; poor above 0.25.
- INP replaced FID as the official metric in March 2024.
- What counts is field data from real users, not just the Lighthouse score.
- Heavy images and third-party scripts are the most common culprits.
What Core Web Vitals are and why they matter
Core Web Vitals are three metrics Google chose to measure whether a page feels fast, responds well and doesn't jump around while you use it. They're part of the page experience signals Google considers in rankings.
It's worth being precise about how much they weigh: content relevance still rules. A slow page with the best answer can outrank a fast one that doesn't answer the query. But when two pages are comparable, experience counts, and above all it counts for your customers: a page that's slow to show the WhatsApp button or the phone number loses leads even if it ranks first.
In La Laguna, our home region in northern Mexico, much of the traffic to local businesses comes from phones, often on mobile data with spotty coverage. That's where a heavy site is most noticeable, and Google measures mobile separately.
The three metrics and their thresholds
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long it takes for the largest visible element to render: the main image or the headline | ≤ 2.5 s | 2.5 to 4 s | > 4 s |
| INP (Interaction to Next Paint) | How long the page takes to respond visually to clicks, taps and key presses, throughout the entire visit | ≤ 200 ms | 200 to 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | How much content moves unexpectedly while it loads | ≤ 0.1 | 0.1 to 0.25 | > 0.25 |
Two details matter. First, Google evaluates the 75th percentile: to pass, at least three out of four visits must fall in "good." Second, it measures mobile and desktop separately, so a site can pass on desktop and fail on mobile.
INP replaced FID (First Input Delay) in March 2024. FID only measured the delay of the first interaction; INP considers all of them, which is why it's tougher on JavaScript-heavy sites.
How to measure them: field data vs. lab data
There are two kinds of data, and mixing them up is the most common mistake:
- Field data: comes from real Chrome users, via the Chrome UX Report, over a 28-day window. It's what Google uses. You'll find it in PageSpeed Insights (the real-user experience section) and in Search Console's Core Web Vitals report.
- Lab data: a simulation under controlled conditions, such as Lighthouse or the PageSpeed Insights score. It's useful for diagnosing problems, but it isn't what Google evaluates. Also, the lab can't measure INP because there's no real interaction; it uses Total Blocking Time as a proxy.
If your site gets little traffic, there may not be enough field data; in that case, go by the lab results and by testing on a mid-range phone using mobile data. Our SEO and GEO audit checks speed along with the other factors on your site.
How to improve LCP
The LCP element is usually the main image or the largest text block at the top of the page. The highest-impact improvements:
- Optimize the main image: a modern format (WebP or AVIF), the right dimensions for each screen with srcset, and compression. A 4 MB photo taken with a phone is culprit number one.
- Don't lazy-load the main image. The loading="lazy" attribute is great for images further down, but on the top one it delays LCP. Use fetchpriority="high" on it instead.
- Cut server response time: good hosting, page caching and a CDN. A server that's slow to respond delays everything else.
- Remove render-blocking CSS and JavaScript or load them after the essentials.
- Preload critical fonts and images that the browser would otherwise discover late.
- Avoid sliders and carousels at the top: they usually load several large images and extra JavaScript.
A typical example in La Laguna: a restaurant home page with a carousel of five 3 MB photos, a background video and the menu embedded as a PDF. Swapping the carousel for a single optimized photo and the PDF for an HTML menu usually brings mobile LCP down from several seconds to one or two, without losing anything the customer needs to see.
How to improve INP
A poor INP almost always means too much JavaScript running on the main thread. When the user taps a button, the browser is busy and slow to respond.
- Audit third-party scripts: chat widgets, ad pixels, maps, session recording tools, pop-ups. Each one adds up. Remove the ones you don't use and delay loading the rest until after interaction or the load event.
- Break up long JavaScript tasks into small chunks so the browser can handle clicks in between.
- Shrink the DOM: pages built with visual page builders sometimes generate thousands of nested elements that make every change slow.
- Give immediate visual feedback: show the change on the button right away and do the heavy lifting afterward.
To track conversions without weighing down the user's browser, one alternative is to send events from the server, such as Meta's Conversions API, instead of piling pixels onto the page.
How to improve CLS
CLS measures those annoying jumps where you're about to tap a button and the page moves. The typical causes and their fixes:
- Images and videos without dimensions: always add width and height, or an aspect-ratio in CSS, so the browser reserves the space.
- Ads, maps and iframes: reserve a container with a fixed height before they load.
- Banners that appear above the content, such as cookie notices or promotions, pushing everything down. Show them as overlays or at the bottom.
- Web fonts: when the final font replaces the fallback, text changes size. Use font-display with a fallback font of similar metrics, or tune size-adjust.
- Content injected by JavaScript above what's already been displayed.
WordPress, page builders and static sites
The platform makes a big difference. A WordPress site with a visual page builder, 30 plugins and a multipurpose theme starts at a disadvantage: lots of CSS and JavaScript that isn't used on any given page. You can optimize it with caching, minification, optimized images and fewer plugins, but there's a limit.
| Type of site | Starting point | What to watch |
|---|---|---|
| Static (HTML, CSS and minimal JS) | Very fast | Images and third-party scripts |
| Optimized WordPress | Good | Plugins, theme, caching and hosting |
| WordPress with a page builder and many plugins | Slow on mobile | All of the above plus DOM size |
| Online store | Varies | Third-party apps or plugins, product images |
In the case of La Brasa Norteña Taquería, we replaced a slow WordPress site with a static site generated from data, and mobile LCP ended up at 0.9 seconds. If you're thinking about rebuilding your site, see our web development service; if your site was attacked, the guide to fixing a hacked WordPress site also explains when it makes sense to go static.
Hosting counts too
A slow or overloaded server increases the initial response time (TTFB) and with it LCP, no matter how well optimized your images are. On shared hosting with many sites, performance can vary by time of day. A CDN that serves your site from locations close to the user helps a lot, especially if your audience is in one country and your server is in another.
If you have doubts about your server, the guide to shared hosting vs. VPS will help you decide. And since speed is only one part of technical SEO, also read the 7 SEO decisions to make before building your site and check out our SEO service.
Quick review checklist
- I checked the Core Web Vitals report in Search Console for mobile and desktop.
- The main image is in WebP or AVIF, with the right dimensions and no lazy loading.
- Every image has width and height.
- I removed third-party scripts I don't use and delayed the rest.
- The site uses caching and a CDN.
- I tested the site on a mid-range phone using mobile data.
- I check again after every major change, keeping in mind that field data takes up to 28 days to reflect it.
