Core Web Vitals: How to Pass LCP, INP, and CLS
Core Web Vitals are the three numbers Google keeps on how your pages feel to a real person: how long the main content takes to appear, how quickly the page reacts when someone taps, and how much the layout jumps around while it settles. Search Console reports them as a pass or a fail, and most site owners meet them the same way, as a red bar in a dashboard with no obvious next step. This guide covers what each metric measures, the exact thresholds for 2026, why the two scores in PageSpeed Insights disagree, and the specific fixes that move each one. There is a live scorecard partway down so you can grade your own numbers before you touch any code.
The short version
Three metrics, three thresholds: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.10. Google grades the 75th percentile of real Chrome visits over the past 28 days, and you have to clear all three to pass. Most failures trace to one oversized hero image, one heavy third party script, or one element that loads without reserved space.
The three metrics and what they actually measure
Every Core Web Vital stands in for one thing a visitor complains about. LCP is the person waiting on a blank screen. INP is the person tapping a button that does nothing. CLS is the person who goes to press one thing and hits an ad because the page moved under their thumb. Once you read them that way, the fixes stop being abstract.
| Metric | What it measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | Time until the biggest visible block of content finishes rendering, usually a hero image or a headline | 2.5s or less | 2.5s to 4.0s | Over 4.0s |
| INP | Worst delay between a tap or keypress and the next frame the browser paints, across the whole visit | 200ms or less | 200ms to 500ms | Over 500ms |
| CLS | How far visible elements move without the visitor causing it, scored as a share of the viewport | 0.10 or less | 0.10 to 0.25 | Over 0.25 |
Two details trip people up. The grading percentile is the 75th, not the average, so a page that is quick for most people can still fail on the slower quarter of visits, which is usually mid range Android phones on cell networks. And the three are graded together: two greens and one red is a fail.
Field data and lab data are not the same score
Run any URL through PageSpeed Insights and you get two sets of numbers that often disagree, which makes people assume the tool is broken. It is not. The panel at the top is field data from the Chrome User Experience Report: actual visits from actual Chrome users on actual devices, aggregated over the trailing 28 days. That is the data Google uses for search, and it is the only one that decides whether Search Console shows a pass.
The section underneath is Lighthouse lab data: one simulated load, on a throttled connection, on an emulated mid tier phone, in a clean browser with no extensions and an empty cache. It is repeatable and it points at specific causes, which makes it the right tool for diagnosing. It is the wrong tool for judging, because a single scripted load cannot represent the spread of real visits. Use lab data to find and verify the fix, then watch field data to confirm it landed.
One consequence worth planning around: field data lags. A fix you deploy today does not fully clear the 28 day window for about four weeks. Ship the fix, confirm it in the lab immediately, and do not panic when Search Console looks unchanged the next morning.
Core Web Vitals scorecard
Copy your three field values out of PageSpeed Insights or Search Console and drop them in. This grades each one against the 2026 thresholds and tells you which to fix first.
Your result
Enter at least one metric to see where you stand.
Speed only decides whether the visitor stays long enough to ask a question. Intellure answers that question the moment it arrives, so a page you worked hard to make fast does not end in an unread message.
Fixing LCP: the largest element is almost always the problem
LCP failures are the most common and the most mechanical to solve. Lighthouse names the offending element for you, and on the vast majority of marketing and service pages it is the hero image. Work through these four in order and most sites clear 2.5 seconds without a rebuild.
Shrink and reformat the hero image
A 2MB JPEG exported straight from a camera or a stock site is the single most common cause of a failing LCP. Serve it as WebP or AVIF, size it to the largest width it will ever display at rather than the original, and let responsive sources hand phones a smaller file. The same photo at 150KB looks identical and loads more than ten times faster on a cell connection.
Never lazy load what is above the fold
Lazy loading everything is a habit that quietly breaks LCP: the browser waits to discover the hero image instead of fetching it immediately. Set loading to eager on the LCP element, add fetchpriority high, and preload it in the head. Lazy loading still belongs on everything below the fold, where it genuinely helps.
Stop render blocking CSS and fonts
Every stylesheet in the head pauses rendering until it downloads and parses. Inline the small amount of CSS the first screen needs, defer the rest, and self host your fonts with font-display swap so text paints in a fallback face instead of staying invisible. Cutting one blocking web font request often takes several hundred milliseconds off LCP.
Cut the server response time
Nothing on the page can start before the HTML arrives. If time to first byte sits above roughly 800 milliseconds, your problem is the server, not the front end. Cache the page at the edge, put a CDN in front of static assets, and check for the slow database query or bloated plugin that runs on every request.
Fixing INP: the browser is busy when the visitor taps
INP replaced First Input Delay in March 2024 and it is a far stricter test. FID only counted the wait before the browser began handling the first interaction, so most sites passed it while still feeling slow. INP measures the entire path, from tap to the next painted frame, and reports near the worst interaction in the visit rather than the first one.
The cause is nearly always the same: the main thread is occupied running JavaScript, so it cannot get to the visitor input. Analytics bundles, chat widgets, heatmap recorders, A/B testing scripts, and tag managers loaded through a single tag are the usual suspects, and each one felt harmless when it was added. Open the performance profile, look for tasks longer than 50 milliseconds, and find out who owns them.
Three fixes carry most of the weight. Defer third party scripts until the page is interactive, or load them only on the pages that need them. Break long tasks into smaller pieces so the browser gets a chance to respond between them. And render the visible feedback first, then do the heavy work, so a tapped button changes state immediately instead of after the calculation finishes. This is also a good moment to audit which widgets are earning their place. If a support chat script is costing you 200 milliseconds on every interaction, an Intellure AI employee handles the same conversations across WhatsApp, Instagram, and your site without parking that weight on the main thread.
Fixing CLS: reserve the space before the content arrives
Layout shift is the most preventable of the three, and it comes from a short list of causes. Images and videos without width and height attributes, so the browser cannot reserve a box until the file loads. Ad slots and embeds that get their size from the response. Banners and cookie notices injected at the top of the document, pushing everything down. Web fonts that swap in at a different metric and reflow the text around them.
Every fix is the same idea: reserve the space in advance. Put explicit width and height on every image and iframe, or set an aspect ratio in CSS. Give ad and embed containers a fixed minimum height. Overlay notification bars instead of inserting them into the flow. Preload the font files you actually use and pick a fallback with similar metrics so the swap barely moves anything. Test on a slow connection, because CLS problems hide completely on a fast one where everything arrives at once.
How much do Core Web Vitals really matter for rankings?
Less than the average performance pitch implies, and more than the skeptics say. Google has been consistent that page experience is a lightweight signal: it will not lift a thin page above a genuinely better one, and no amount of speed substitutes for content that answers the query. Where it moves the needle is among pages that are already close on relevance, which describes most competitive commercial searches.
The stronger argument is commercial rather than algorithmic. Bounce rate climbs steeply with load time, and mobile visitors abandon before the page ever finishes. A page that takes six seconds is not losing a ranking position so much as losing the visitor outright, and that loss happens whether you ranked first or fifth.
Which is worth keeping in perspective. Speed buys you the visit. What happens in the next few minutes decides whether it becomes revenue: the question that goes unanswered at 9pm, the quote request nobody replies to until Monday, the booking that goes to whoever responded first. Fixing LCP and letting inquiries sit overnight is optimizing the cheap half of the funnel. Intellure exists for the other half, answering and following up the moment someone reaches out.
A four week plan that actually finishes
Performance work stalls when it turns into an open ended rewrite. Time box it instead, and work in the order that pays fastest.
| Week | What you do | What it usually buys |
|---|---|---|
| Week 1 | Pull field data for your top ten URLs, record the three numbers for each, and name the LCP element on every one | A baseline and a short list, instead of a vague sense that the site is slow |
| Week 2 | Compress and reformat every hero image, set explicit dimensions site wide, preload the LCP image | The largest single LCP drop available, and most of your CLS problem gone |
| Week 3 | Audit third party scripts, remove what nobody uses, defer the rest until after interactive | The bulk of the INP fix, plus a second helping of LCP |
| Week 4 | Self host fonts with swap, inline critical CSS, defer the rest, then re-measure in the lab | The last few hundred milliseconds, and the font driven layout shift |
| Week 8 | Check field data again, once the 28 day window has fully turned over | The verdict that counts |
Add one habit after that: re-check the scorecard whenever you change a template or add a marketing tag. Core Web Vitals do not decay on their own. They decay because someone drops in a script on a Tuesday and nobody measures until the Search Console email arrives six weeks later.
Frequently asked questions
What are Core Web Vitals?+
What is a good Core Web Vitals score in 2026?+
Do Core Web Vitals actually affect Google rankings?+
Why does PageSpeed Insights show two different scores?+
Why did INP replace First Input Delay?+
How long before a fix shows up in my scores?+
The bottom line
Core Web Vitals reward the unglamorous work: right sized images, reserved space, fewer scripts, a server that answers quickly. Do those four things and most sites pass without a redesign. Then remember what a passing score actually earns you, which is a visitor who stayed long enough to ask something. That is where an Intellure AI employee picks up, replying in seconds on WhatsApp, Instagram, and your website, following up on the ones who go quiet, and booking the appointment, around the clock. A fast page and a fast answer are the same promise, made twice.