Core Web Vitals – 2026 Thresholds and Practical Fixes

Core Web Vitals measure how quickly your main content appears, how responsive it feels and how stable the layout stays.

The current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

Most websites still fail that test on mobile. In the HTTP Archive’s 2025 Web Almanac, 48% of websites had good Core Web Vitals on mobile (July 2025 data).

The weakest metric was not INP. Only 62% of sites had a good mobile LCP, against 77% for INP and 81% for CLS.

Our reading of those figures: check loading before assuming responsiveness is your problem. Your own field data decides, not the average.

For Core Web Vitals 2026 planning, use the current definitions and published thresholds. INP replaced First Input Delay on 12 March 2024. It is an established metric, not a new 2026 replacement.

This guide starts with real-user evidence and explains how to test a focused fix. A high score from one automated test does not show that every visitor gets a good experience.

What Are Core Web Vitals?

Core Web Vitals describe three different parts of the experience:

• LCP measures when the largest eligible content element in the viewport becomes visible.
• INP measures responsiveness to qualifying interactions throughout a visit.
• CLS measures unexpected movement of visible page elements.

People often search for LCP INP CLS as one phrase, but each metric has its own cause and its own fix. A page can load its main image quickly and still respond slowly when someone opens the menu.

It can also respond quickly while an appointment button shifts as an image loads.

Each problem needs different evidence. Avoid treating “website speed” as a single diagnosis.

Use Google’s web.dev guide to Web Vitals as the reference for the current metric set. Supporting measures such as First Contentful Paint and Total Blocking Time can aid diagnosis. They do not replace these three.

Core Web Vitals Thresholds for 2026

The core web vitals thresholds have not changed for 2026. Google’s guidance is to measure the 75th percentile of page loads, segmented across mobile and desktop. The good boundaries include the threshold value.

Metric	Good	Needs improvement	Poor
LCP	2.5 seconds or less	Above 2.5 seconds, up to 4 seconds	Above 4 seconds
INP	200 milliseconds or less	Above 200 ms, up to 500 ms	Above 500 milliseconds
CLS	0.1 or less	Above 0.1, up to 0.25	Above 0.25

A page passes the assessment only when all three metrics are good. Google’s PageSpeed Insights documentation says the aggregation passes if the 75th percentiles of all three metrics are good. If INP has insufficient data, LCP and CLS decide the result.

The 75th percentile is the value at or below which 75% of recorded experiences fall. It is not an average.

Consider an illustrative result: mobile LCP is 2.4 seconds, INP is 310 milliseconds and CLS is 0.08. Responsiveness needs improvement even though the other two values are good. These are explanatory numbers, not measurements from a Skymoon website or client.

Where sites actually stand

The same Web Almanac chapter shows how many websites meet each threshold. Read it as context, not as a target. Your competitors’ pass rate does not change what your visitors experience.

Share of websites with a good result, 2025	Mobile	Desktop	Reading
All three metrics (overall)	48%	56%	Fewer than half of mobile sites pass
LCP	62%	74%	Weakest metric on mobile
INP	77%	97%	Mobile lags desktop by 20 points
CLS	81%	72%	Desktop is weaker than mobile

How Core Web Vitals Affect SEO

Google says Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward. It also recommends good scores for Search success and a good user experience.

That is not a promise of higher rankings. Search relevance and the usefulness of your content still matter. A fast page can still fail to answer the query.

Core Web Vitals SEO work should therefore sit beside crawlability, search intent and on-page quality. Use our on-page SEO checklist to review that wider context.

Our guide to building an SEO friendly website gives the site-level view. Avoid assigning a click or ranking change to performance alone.

Performance fixes also need a clear business purpose. Prioritize pages where loading, interaction or layout problems interrupt an important task.

For example, an unstable booking form deserves attention because it can make appointments harder to request. That observation does not predict a specific conversion increase.

Run a Core Web Vitals Test With the Right Evidence

Read the field data first

PageSpeed Insights combines real-user data with a simulated page-load test. Its field data comes from the Chrome User Experience Report (CrUX) and covers the previous 28-day collection period.

Record the tested URL, device, measurement window and whether the data describes that URL or the origin.

Google says PSI falls back to origin-level data when a page lacks enough samples. Origin data covers the whole site, not just your article.

If the origin also lacks enough data, PSI shows no real-user data at all. Insufficient data means the experience cannot be assessed from that dataset. It is not evidence of passing or failing.

Use lab tests to investigate causes

The Lighthouse section gives controlled diagnostics for the tested load. It helps you examine render-blocking resources, image delivery and work that keeps the browser busy.

A standard Lighthouse run does not report INP. As Chrome’s Barry Pollard put it, with no interactions there is no INP to measure. Lighthouse user flows can script journeys that do include interactions.

Google’s Total Blocking Time guidance calls TBT a reasonable lab proxy for INP, but not a substitute. It recommends measuring INP in the field.

Use a Chrome DevTools Performance recording while repeating the interaction you suspect. Examples include opening navigation, choosing a product option or submitting a form. Repeat the same task when comparing fixes.

Check the Search Console report scope

Search Console’s Core Web Vitals report groups URLs with a similar user experience and draws on CrUX data. A reported issue can therefore involve a shared template.

Inspect the group’s example pages before making a site-wide change. The Search Performance report measures search activity and positions. It does not measure LCP, INP or CLS.

A “No data available” screen means the property is new or there is not enough data. Record the affected metric, device and group, and keep one representative URL for each template under investigation.

Lab and field results often disagree. The table explains the usual reasons.

What you see	Likely reason	What to check
Good lab result, poor field result	The lab test skipped real devices, networks or interactions.	Device, network, scope and the interactions missing from the test.
Good field result, poor lab result	The lab test uses a simulated slow environment.	Whether real visitors actually hit the slow conditions.
URL data missing, origin data shown	The page has too few samples.	Treat origin data as site-wide, not page-specific.

How to Improve Core Web Vitals: Prioritize the Actual Problem

Begin with pages that combine poor field results and an important user task. A product template used across your catalog deserves more attention than one rarely visited article. Use this decision table to turn evidence into a development task.

Evidence	First investigation	Validation
Main content appears late	Identify the LCP element and inspect delivery and rendering delays.	Repeat comparable tests, then monitor field LCP.
Menus or forms react slowly	Record the interaction and inspect blocking tasks.	Retest the same interaction, then monitor field INP.
Content or controls move unexpectedly	Locate shifting elements and late content insertion.	Repeat the affected journey, then monitor field CLS.
Good lab result but poor field assessment	Check device, network, scope and interactions missing from the test.	Use representative interaction traces and real-user monitoring.

Write a specific task before changing settings. “Hero image is discovered late on product pages” is actionable. “Improve speed” leaves the developer guessing.

Avoid changing several plugins or delivery settings together. Smaller batches make regressions easier to investigate.

Improve LCP by Finding What Delays the Main Content

Identify the largest content element in the tested viewport. Per web.dev, candidates include images, video poster images, elements with a CSS background image and block-level text. It can differ between mobile and desktop.

Then split the delay into its parts. Google’s LCP optimization guide names four subparts and gives rough proportions as guidelines, not strict budgets.

LCP subpart	Rough share	What to inspect
Time to first byte	About 40%	Redirects, caching, hosting distance and cache misses.
Resource load delay	Under 10%	Whether the browser discovers the image early in the HTML.
Resource load duration	About 40%	File size, format, dimensions and network priority.
Element render delay	Under 10%	CSS or scripts that block rendering after the asset arrives.

A smaller file will not fix a delay caused by late discovery. Google says the LCP resource should be discoverable in the initial HTML response. It also warns that a high time to first byte can make a 2.5 second LCP challenging or even impossible.

Practical actions depend on the trace:

• Improve a slow server response with suitable caching or hosting changes.
• Make the important image discoverable early in the HTML.
• Serve an appropriately sized, compressed image for the viewport.
• Never lazy-load the LCP image. Google says it always adds unnecessary load delay.
• Use fetchpriority=”high” on the likely LCP image, and on only one or two images.
• Investigate CSS or scripts that delay rendering after the asset arrives.

Keep below-the-fold images lazy-loaded where useful. Giving every image high priority removes the benefit of prioritization.

For an illustrative product page, the desktop banner might be the LCP element. On mobile, a large heading could take over. Diagnose both layouts before applying one image fix everywhere.

Improve Interaction to Next Paint by Testing the Slow Interaction

Interaction to Next Paint assesses overall responsiveness. Google says only three interaction types count: mouse clicks, taps on a touchscreen, and key presses. The final value is the longest interaction observed, ignoring outliers.

Scrolling and hovering are not INP interactions. INP also does not measure the full duration of a server-side booking or payment process.

An interface can acknowledge a request quickly while the server keeps working. That feedback matters when someone would otherwise tap the same button repeatedly.

INP Core Web Vitals: find the slow phase

Break the interaction into the three phases that Google’s INP optimization guide describes: input delay before handlers run, processing time inside handlers, and presentation delay until the next frame. Check which phase dominates.

For example, a menu tap may wait behind third-party JavaScript. Another menu may start promptly but trigger expensive layout work.

Possible actions include:

• Remove unnecessary third-party scripts.
• Split long tasks and yield to the main thread so the browser can handle input between them.
• Reduce expensive work inside event handlers.
• Avoid forced reflow, where styles are changed and then read within the same task.
• Keep the DOM small, and consider content-visibility for off-screen content.

Test after consent choices, embedded tools and other delayed scripts have loaded. A clean initial page-load result can miss those conditions.

Also check the task itself. A fast form response is useful only when validation messages and the confirmation process remain understandable.

Improve CLS by Reserving Space and Checking Late Changes

Unexpected movement can send a tap to the wrong link or make someone lose their reading position. Find the elements that move and the content that causes the movement.

Google’s CLS optimization guide is specific. Always include width and height attributes on images and video, so the browser can reserve space. Reserve space for embeds, banners and ads in the initial layout.

Keep that space if the content never arrives, because removing it can cause just as much shift.

Fonts need care too. Both a flash of unstyled text and invisible text can shift layout. The instruction “use font-display: swap” does not guarantee stability.

Google points to font-display: optional and preloading critical fonts. It also describes size-adjust and override descriptors that make a fallback match the web font.

Animate with transform instead of properties such as top and left. Changing layout properties causes shifts, while composited transform animations do not count toward CLS.

An illustrative booking page might shift when a consent banner or scheduling embed appears. Inspect that sequence instead of checking a static screenshot. Then retest the affected journey, including changes after the first screen loads.

If the problem involves page layout, our web design services can support a template review. Healthcare teams can start with our healthcare website design guide.

WordPress Core Web Vitals: Check Settings Against the Template

WordPress Core Web Vitals work should begin with the actual page output. A theme, page builder or plugin can change how resources load.

WordPress itself helps. Since version 6.3, core adds fetchpriority=”high” to the first large image in the response. It also avoids lazy-loading images likely to be in the viewport.

The same release raised the default threshold for skipping lazy-loading from one image to three.

That default can still be overridden. Check whether your optimization plugin applies lazy loading to the main image. Inspect what the browser receives; the setting name alone is insufficient.

Review scripts from forms, consent tools, booking widgets and unused plugins. Confirm that a plugin is unnecessary before removing it.

Test script-delay settings against essential interactions. Delaying a booking widget may improve one test while leaving visitors waiting after a tap.

Use a staging environment for template changes. Retest navigation, forms, consent controls and checkout before release. Keep a record of the setting, template, release date and comparison evidence. It lets your team reverse a change that breaks an important function.

Core Web Vitals Checklist With Owners and Evidence

Core Web Vitals best practices become useful when each action has a reason and a validation method. Use a short worksheet instead of a collection of unexplained plugin settings.

Item	Example task	Owner	Evidence to retain
LCP	Remove lazy loading from the identified hero image.	Developer	Request timing and comparable tests.
INP	Investigate the slow mobile navigation interaction.	Developer	Interaction trace and repeat test.
CLS	Reserve space for the booking embed.	Developer or designer	Before and after journey recording.
Release checks	Confirm forms and tracking still work.	QA or marketing	Functional test results.
Field monitoring	Review the same device and data scope.	SEO or analytics lead	Dated field-data observations.

These are illustrative tasks. Estimate effort after investigation, and prioritize confirmed problems affecting important templates. For a broader review, our SEO services can connect technical findings with search intent and page priorities.

Validate the Fix and Monitor Regressions

Retest the same URL, device setup and user journey after deployment. Save the release date and describe exactly what changed.

Lab results can show an immediate difference under comparable conditions. Field data takes time to reflect the new experience, because its 28-day window includes earlier visits.

Search Console offers a validation process for reported issues. Google says it starts a 28-day monitoring session.

The issue counts as fixed only if it is absent from your URLs during that window. Starting validation does not guarantee the issue will clear.

When a page has insufficient public field data, use real-user monitoring and repeatable diagnostics. Be clear about what each measurement covers.

Review important templates after theme, plugin, analytics, consent-tool or booking-widget changes. Core Web Vitals optimization is easier to maintain when regressions can be tied to a specific release.

Measure appointment or checkout outcomes separately. Improved metrics and improved business results are different observations.

Frequently Asked Questions

Get Help With Your Core Web Vitals Review

If your team needs a focused review of loading, responsiveness or layout stability, talk to Skymoon Infotech. Our SEO services and web design services connect technical fixes with search intent and page priorities.

Bring your field-data screenshots, the affected URLs and your template list. They give the review a concrete starting point.