Core Web Vitals 2026: why INP is the one most fail and almost no one told you

In March 2024 Google changed one of the three metrics that decides whether your site is fast in the eyes of the search engine, and most businesses never found out. It retired FID, the interactivity metric that almost everyone passed, and replaced it with INP, much stricter. Two years later the figure is harsh: 43% of sites fail INP, which makes it the Core Web Vital that most sites flunk in 2026. And around 40% of the sites that passed with FID stopped passing with INP, without touching anything, just because the rule changed beneath them.

There is a second detail that almost no Panamanian agency explains, and it is the one that most confuses business owners: your PageSpeed report can show 98 out of 100 while your real users live in red. Google does not measure your laboratory; it measures your visitors. This guide explains what changed, why it is precisely the type of site the competition sells that fails, and why a site built with the right architecture passes INP without anyone having to optimize anything.

The three Core Web Vitals, in one sentence each

Google evaluates the technical experience with three metrics, and labels each page according to real user data. LCP (Largest Contentful Paint) measures how long the main visible element takes to load; the good threshold is 2.5 seconds or less. CLS (Cumulative Layout Shift) measures how much the content moves unexpectedly while loading —that annoying jump when you go to touch a link and an image pushes it down—; the good threshold is 0.1 or less. INP (Interaction to Next Paint) measures how long the page takes to respond visually to each interaction; the good threshold is 200 milliseconds or less. Of the three, INP is the hardest and the one most sites flunk.

What changed with INP and why it hurt so much

FID was a lenient metric. It only measured the delay of the user's first interaction with the page: the time between the first click and the moment the browser began to process it. It was a narrow window and easy to pass, and that is why almost all sites approved it effortlessly. INP is another thing: it measures the complete journey —from interaction to visible repaint— of all the interactions in the visit, not just the first, and keeps the worst one. It went from measuring the initial greeting to measuring the whole conversation.

The change was not cosmetic. INP punishes what FID ignored: the slowness that appears when the user is already using the site, when expanding a menu, opening an accordion, filtering a catalog or submitting a form. That is why so many sites that lived in green with FID woke up in red with INP without changing a line of code. The threshold stayed at 200 ms for the 75th percentile of visits: if one in four interactions takes more than 200 ms to respond, you fail.

The Lighthouse trap: laboratory versus field

Here is the misunderstanding that costs money. When a provider shows you a PageSpeed Insights of 98 or 100 as proof that your site is fast, they are showing you a laboratory figure. Lighthouse runs in a simulated environment: a powerful machine with a fast connection, in ideal conditions. Google does not use that to rank. It uses field data from the Chrome User Experience Report (CrUX): measurements of your real users, on their real phones —many mid-range in Panama—, with their real connections, taken at the 75th percentile over a 28-day moving window.

The gap between the two worlds can be an order of magnitude. A site can score 98 on the developer's laptop and fail INP in the field because mobile users, with slower devices, live a worse experience. That is why it is worth stopping optimizing for the Lighthouse score and looking at the one that really counts: Google Search Console's Core Web Vitals report, which shows your field data grouped and labeled. Lighthouse is for diagnosing which file blocks; CrUX says whether you are really passing.

Why INP is, at bottom, a JavaScript problem

Almost all INP failures have the same root cause: JavaScript that blocks the browser's main thread. The browser uses a single main thread to respond to user interactions and, at the same time, to execute the page's JavaScript. When a JavaScript task occupies that thread for more than 50 ms, any touch from the user has to wait for it to finish, and that wait is exactly what INP measures and punishes.

That is where the type of site decides the result. A WordPress with a page builder and a dozen plugins typically loads between 200 and 500 KB of JavaScript: the visual builder, the chat widgets, the marketing pixels, the analytics libraries, the sliders, the popups. All that code competes for the same thread that should respond to the touches. Unlike LCP, which you improve by compressing an image, INP is not fixed with a trick: it requires rethinking how the JavaScript is loaded and executed, and in an installation saturated with plugins that is difficult at the root because the owner does not control the code of each extension.

Why a static site passes INP without optimizing

The uncomfortable conclusion for whoever sells heavy sites is simple: if INP fails because of excess JavaScript, a site that barely has JavaScript has nothing to fail. The modern static architecture —like Astro with the islands pattern— sends the browser already-built HTML and CSS and only the minimum essential JavaScript, typically less than 100 KB and sometimes almost zero on content pages. The main thread stays free to respond to interactions immediately.

It is not optimization: it is arithmetic. The problem that sinks 43% of sites simply does not appear when you do not load the code that causes it. This very site is the proof: it is built with a high-performance static architecture, its JavaScript budget is a few KB per page, and that is why it responds below the thresholds with no need for tricks. It is the same logic we explained in the comparison of WordPress against Astro: the architecture choice, made at the start, decides most of the performance problems before they exist. Optimizing a heavy site so it passes INP costs weeks; starting from a lightweight one gives it for free.

The detail that throws teams off: how Search Console groups

There is a Google behavior that surprises even technical teams. Search Console does not evaluate each URL separately: it groups similar pages and assigns the whole group the status of the worst metric in the group. That means a single slow template —say, the product page— can drag dozens or hundreds of pages that share its structure into red, even though individually some work well. The grouping model matters more than most expect, because it changes where it is worth investing the effort.

The practical reading is that you do not optimize page by page, but template by template. Fixing the JavaScript of the product template, or the blog article, or the service page, moves the whole group that uses it at once. That is why a site with few well-made templates passes Core Web Vitals with less work than one with many disparate templates, each with its own cocktail of plugins. Architecture consistency is again the lever: fewer, cleaner templates perform better than many patched templates.

The three phases of each interaction, to understand where the time is lost

INP does not measure a single thing, but the complete journey of an interaction divided into three phases, and understanding them helps to know what to fix. The first is the input delay: the time the user's touch waits because the main thread is busy executing another JavaScript task. The second is the processing time: how long the event handlers that respond to that interaction take to execute. The third is the presentation delay: how long the browser takes to paint on screen the visible result of the change.

Most INP failures are born in the first phase, the input delay, and almost always for the same reason: the main thread was blocked executing third-party JavaScript when the user touched. That is why deferring non-essential scripts pays off so much: it frees the thread so the interaction is attended to instantly instead of queuing behind the analytics or the chat widget. Knowing in which phase the time is lost is what separates a surgical optimization of a month of blind trial and error.

What to do if your site fails INP today

If your current site is in red and rebuilding it is not an immediate option, there are real fixes, although they patch instead of resolve. Defer non-critical JavaScript: chat widgets, analytics and marketing pixels are among the biggest INP killers; load them after the interaction, not at the start. Split the long tasks: any task that blocks the main thread for more than 50 ms pushes the INP to red, so it is worth dividing them into small chunks. Reduce the TTFB with edge computing to serve the content from the point closest to the user. Audit plugin by plugin in WordPress: many times two or three extensions load most of the surplus JavaScript.

But it is worth being honest about the ceiling of that path: on a site built on a heavy base, those fixes bring the INP from "poor" to "needs improvement" more often than to "good". There comes a point where continuing to patch costs more than rebuilding on a lightweight base, and that calculation is exactly what we measure in a web audit: how much it would cost to bring your current site to green versus how much it would cost to start from scratch with the right architecture. Sometimes the patch is the sensible thing; sometimes it is throwing good money after bad.

What's coming: the metric does not stop

It is worth looking ahead. In 2026 Google confirmed on its Search Central blog, on March 18, that INP stopped being a supplementary metric to become a ranking signal equivalent to LCP and CLS, and sites with INP in the "needs improvement" range registered measurable position drops, on average close to one place. Google also began to talk about new metrics, not yet ranking ones, like a visual stability index that observes the whole visit and not just the initial load. The direction is clear: the bar of what Google considers "fast and stable" rises each year, and the cost of dragging a heavy site accumulates.

For a Panamanian business that competes for keywords where everyone's content is similar, INP is often the tiebreaker: between two equivalent pages, the one that responds fast wins the position. And in the era of zero-click, where each visit that does arrive is worth more, losing it because the site responds slowly is a luxury no business can afford. The first step costs nothing: open Google Search Console, go to the Core Web Vitals report and look at how many of your pages are in red for INP. That number is the real size of the problem.

There is a specific aggravating factor in the Panamanian market that makes this more urgent. INP is measured on real devices, and in Panama a large part of the traffic arrives from mid-range Android phones, with less powerful processors than the developer's iPhone or the agency's laptop. A heavy site that barely passes INP on a high-end device can clearly fail on the typical Panamanian client's phone, exactly the device from which most local searches are made. The same code that looks acceptable in the developer's laboratory punishes the business in its client's pocket. That is why measuring in the field, and not on the laptop of whoever built the site, is not a technicality: it is seeing the reality that whoever is going to buy from you lives.