Core Web Vitals 2026: Why INP Is Getting Worse and How to Fix It

In August 2026 only 55.6% of websites worldwide passed all three Core Web Vitals. INP, the metric that measures how quickly a site responds to user actions, has been slipping for several months in a row: from 87.2% of sites with a “good” INP in March to 85.3% in August. In its Chrome UX Report release notes, Google admits it has no definitive explanation for the decline yet.

For a business owner this is no reason to panic. It is, however, a good reason to check how your site behaves on a phone and fix what really affects visitors.

55.6%

of sites pass all three metrics

August 2026

85.3%

of sites have a "good" INP

87.2% in March

48%

of mobile sites pass Core Web Vitals

44% in 2024

Three metrics and the thresholds worth remembering

Core Web Vitals are three measurements of user experience. Google assesses them at the 75th percentile of real visits, separately for mobile and desktop. A page passes when all three metrics are in the green.

Metric	What it measures	”Good”
LCP (Largest Contentful Paint)	How fast the main element of the page appears	2.5 s or less
INP (Interaction to Next Paint)	How fast the site responds to a click, tap or keypress	200 ms or less
CLS (Cumulative Layout Shift)	Whether the layout jumps while loading	0.1 or less

Google states that the definitions and thresholds will change no more than once a year, with advance notice. That makes this a stable target rather than a moving one.

What the data shows

Two independent sources paint the same picture from different angles.

Chrome UX Report (CrUX), August 2026. Among more than 18 million sites, 68.1% have a “good” LCP, 81.5% a good CLS and 85.3% a good INP. All three together are passed by 55.6%. INP is the only metric that has visibly declined since the start of the year.

HTTP Archive Web Almanac 2025. The mobile pass rate is 48% (44% in 2024) and the desktop rate is 56%. The weakest link on mobile is LCP:

2025 2024 (where available)

• LCP 62 %
• INP 77 %
  74 %
• CLS 81 %
• All three together 48 %
  44 %

Source: HTTP Archive Web Almanac 2025, Performance chapter

There is one practically important detail: home pages do worse than inner pages, 45% versus 56% on mobile. And home pages are often where visitors land from ads and brand searches.

The sources do not contradict each other: the Almanac describes 2025, while CrUX gives the current monthly snapshot. Different samples and methodology mean the numbers differ, so comparing them figure for figure is not advisable.

Does it affect Google rankings?

The honest answer: partly, and not directly. Google does not promise that good scores will lift a site in search. It “highly recommends” passing Core Web Vitals and treats them as part of a wider set of page experience signals, not as a standalone lever.

So think of speed first of all as convenience for people. A slow site converts worse even when its rankings are fine.

LCP: almost always an image

According to the Web Almanac, the largest element on mobile pages is an image in 76% of cases (85% on desktop). Most of those are older JPG and PNG files, with little modern WebP:

• JPG 57 %
• PNG 26 %
• WebP 11 %

Source: HTTP Archive Web Almanac 2025

That leads to a practical order of work, in line with web.dev guidance:

1. Don’t lazy-load the main image. loading="lazy" above the fold delays the request and hurts LCP.
2. Give the browser a priority hint. Add fetchpriority="high" to one or two key images. Mark ten images that way and it stops working.
3. Make the image visible in the HTML. If JavaScript injects it or it lives only in CSS, the browser finds out late.
4. Compress and size correctly. WebP or AVIF at the size actually displayed, not a 5000-pixel camera original.
5. Look at what LCP is made of. That tells you where to put the effort.

• Server response (TTFB) ≈ 40%
• Resource load duration ≈ 40%
• Delay before loading starts under 10%
• Render delay under 10%

Source: web.dev, Optimize Largest Contentful Paint

INP: why it is slipping and what to do

INP consists of three parts, and each can be sped up separately:

1. 1
   Input delay
   from the user action to the start of processing
   ↓ →
2. 2
   Processing
   running the event handlers
   ↓ →
3. 3
   Presentation
   the next frame with the result appears

Source: web.dev, Optimize Interaction to Next Paint

Typical causes of poor INP, according to web.dev:

• long tasks on the main thread, most often from parsing and running scripts during load;
• “heavy” event handlers that do more than needed before the next frame;
• forced layout recalculation;
• a large number of DOM elements;
• rendering a large amount of HTML on the client with JavaScript.

What to do in practice:

• Break up long tasks. Hand control back to the browser between chunks of work, even with a plain setTimeout. web.dev puts it bluntly: yielding indiscriminately is better than not yielding at all.
• Keep the click handler to what changes the picture on screen. Defer the rest.
• Shrink the DOM. A complex page with thousands of elements is always more expensive to update.
• Move heavy computation into web workers.
• Use content-visibility so the browser does not render what is off-screen.

And a tip of our own, not from the documentation: review which third-party scripts you have added. Chat widgets, pixels, counters and analytics collectors each add work for the main thread. Removing the unnecessary is often cheaper than optimising your own code.

CLS: the cheapest fix

According to the Web Almanac, most pages do not specify image dimensions. Setting width and height, or an aspect ratio, is one of the simplest ways to stop layout jumps. Likewise, most pages lack hints for loading fonts (preload, preconnect), even though they help LCP too.

How to check your site in 10 minutes

1. Open PageSpeed Insights and enter the address of your home page and one or two inner pages.
2. Look at the real-user data block (CrUX, the last 28 days). That is what decides whether a page passes Core Web Vitals. The Lighthouse lab test is useful for finding causes, but it is not the assessment.
3. Switch to mobile: it is worse.
4. If there is no real-user data, PageSpeed Insights shows data for the whole site. If there is none of that either, traffic is not yet sufficient for an assessment, so rely on the lab results.
5. Write down the three values (LCP, INP, CLS) and repeat the check in a month.

What to do next

If your site is built on a heavy template with a dozen plugins, it is sometimes smarter not to patch it but to build a business website again on clean code. If the foundation is fine and the problems are isolated, a few fixes will do.

Want to know what exactly is slowing your site down? Get in touch: we will look at the numbers and tell you what to fix first.

Author: Sergey Filatyev, founder of the Veb-Dev boutique studio.