Your Lighthouse score is not the score Google ranks on
Enterprise teams lean on Lighthouse because it runs in CI and prints a green number. The problem is that Google does not rank on Lighthouse. It ranks on the Chrome User Experience Report, which measures real Chrome users at the 75th percentile across a rolling 28-day window. A site can hold a perfect 100 in a simulated lab run and still fail its field assessment every month, because the lab run happens on a fast machine with an empty cache and the field run happens on a three-year-old Android phone on a slow connection.
The gap between those two realities is where performance programs go to die. The score climbs, the ranking does not move, and nobody can say why.
INP replaced FID, and the bar went up
For years the responsiveness half of Core Web Vitals was First Input Delay, which measured almost nothing. It timed the delay before the browser began handling the very first interaction, then stopped caring. A page could freeze for four seconds after that first click and still post a green FID.
Google closed that loophole in March 2024. Interaction to Next Paint replaced FID and measures something harder: the time from a user interaction to the next frame the browser actually paints. It samples nearly every click, tap, and keypress on a page and reports close to the worst one. Anything at or under 200 milliseconds counts as good. Past 500ms it is poor.
That single change turned responsiveness from a metric most sites passed by accident into the metric most sites fail. Field data collected through 2026 shows 43 percent of origins still missing the 200ms bar, which makes INP the most commonly failed Core Web Vital. The three metrics do not fail at the same rate. Largest Contentful Paint passes on roughly 68 percent of origins and Cumulative Layout Shift on about 78. Responsiveness is the one dragging the average down on its own.
Mobile is where it breaks
The failure is not spread evenly. Mobile origins pass all three metrics at roughly 49 percent, against 58 percent on desktop. That nine-point gap shows up in almost every public dataset, and the reasons are mundane. Mobile CPUs are slower, memory is tighter, and the network is worse, so the same JavaScript that feels instant on a MacBook takes several times as long to parse and run on a mid-range Android phone.
A performance program validated on desktop is measuring the wrong half of the audience. If most of a site's traffic arrives on mobile, the mobile field number is the only number worth defending.
The main thread is the whole story
INP is a main-thread problem almost every time. The browser runs JavaScript, style calculation, layout, and painting on one thread. When a long task occupies that thread, everything else waits. A task qualifies as long once it passes 50ms, and every millisecond beyond that threshold is time the page cannot respond to input. A 400ms task means 350ms of dead interface.
Two sources cause most of the damage on enterprise sites: hydration and third-party scripts.
Hydration is the cost of making server-rendered HTML interactive. The browser downloads the framework bundle, parses it, then walks the page attaching event handlers and rebuilding the state the framework expects. The numbers get ugly at scale. Parsing 200KB of compressed JavaScript takes somewhere between 300 and 500ms. Hydrating a moderately complex page of around 1,500 nodes adds another 150 to 300ms. The main thread is blocked the entire time, so clicks land on a page that looks finished but is not.
Framework choice changes the size of that bill. Field data from 2026 puts Next.js at a 58 percent mobile pass rate, with Nuxt near 54 and hand-rolled React single-page apps below 40. The gap is not about React being slow. It is about server rendering and automatic code splitting doing work a client-only app never does.
Third-party scripts are the second source. Chat widgets, analytics, A/B testing tools, and personalization tags all run on the main thread, and each one can block an interaction. A single tag manager can carry a dozen scripts, and no one team owns all of them.
What actually moves the number
The fixes that work are specific, and most are not glamorous.
Cutting JavaScript comes before tuning it, because the cheapest long task is the one you delete. Audit bundle size per route, drop dependencies that duplicate framework built-ins, and push anything non-essential behind a dynamic import. Sites routinely find hundreds of kilobytes that no user ever needed on first paint.
Break up what remains with scheduler.yield(). A long task is any block over 50ms, and the fix is to slice it and hand control back to the browser between slices. The Prioritized Task Scheduling API exposes scheduler.yield(), which pauses an async function, lets the browser process pending input, then resumes where it left off. It beats the old setTimeout approach because the continuation keeps its priority instead of falling to the back of the queue behind every other scheduled task. The usual pattern is to handle the user-visible work first, yield, then do the analytics or logging in the next task.
Let the platform hydrate less. Islands architecture ships static HTML and hydrates only the interactive pieces, so a product page with a single filter widget does not pay to hydrate the whole layout. Progressive and selective hydration do something similar inside one framework: hydrate the parts a user can reach first and defer the rest until they are needed. On content-heavy enterprise pages this is often the largest single win.
Measure the interaction, not the page load. The Long Animation Frames API records which scripts blocked the main thread and for how long, which tells you far more than a single INP figure. Track JavaScript bytes per route in CI so a regression surfaces in code review instead of in next month's field report.
Keep third-party scripts off the critical path. Load them after the first interaction, self-host the important ones, and enforce a tag budget. Every tag should have an owner, and every owner should have to justify the bytes.
Why this now decides AI visibility too
Speed stopped being only a ranking signal. AI Overviews and answer engines pull from pages they can retrieve and render, and slow pages make unreliable retrieval targets. Google's own page experience guidance and several 2026 citation studies point the same direction: pages that pass Core Web Vitals appear more often in AI-generated answers, while slow pages get dropped from the citation pool before content quality is weighed at all.
There is a second-order effect that catches teams off guard. Retrieval systems frequently do not execute heavy client-side JavaScript. A page whose main content only appears after hydration can be effectively invisible to the systems deciding what to quote, even when it ranks well in classic search. Server rendering plus fast responsiveness fixes the ranking metric and the retrieval problem with the same change.
What a slow interaction costs on a store
The damage is easiest to see on revenue pages. A filter, a size selector, or an add-to-cart handler that stalls for half a second reads as a broken site, not a slow one. Shoppers do not check timings. They tap, watch nothing happen, tap again, and leave. Field data from 2026 puts the same story in numbers: 43 percent of origins fail INP, and the mobile pass rate for enterprise storefronts runs well behind their desktop rate, often by ten points or more.
The fix is rarely the checkout flow, which most teams already watch. It is the second interaction, the one nobody tests: applying a facet in a long product grid, switching variants on a configurable item, expanding a shipping estimator. Those handlers frequently rebuild large DOM trees synchronously, and each one is a candidate for a task that runs past 50ms and blocks the thread.
One enterprise retailer rebuilt a product-grid filter that had been rebuilding every tile on each keystroke. Debouncing the input and appending only the changed rows dropped the handler from roughly 320ms to under 60ms, which moved the route from failing to passing inside a single CrUX window. No framework change, no rewrite. The work was finding the right handler and shrinking what it did.
A pragmatic order of operations
Teams that stall usually start in the wrong place. A sequence that holds up in production:
- Pull field data from CrUX or Search Console first, segmented by device, so the work targets the page and audience that actually fail. Ignore lab scores until the field picture is clear.
- Attribute the bad interactions with Long Animation Frames and a real-user monitoring tool, rather than guessing from the aggregate number.
- Fix the largest JavaScript cost on the highest-traffic failing route before touching anything else.
- Introduce yielding around long tasks, then verify the change against the field metric over a 28-day window, not a lab run minutes after deploy.
- Add a bundle-size budget to CI so the fix survives the next feature sprint.
Most enterprise sites do not need a rewrite. They need to stop trusting a number that was never the one that counted, measure the interactions their users actually have, and delete the JavaScript standing between a click and a response.
Where to start
If a site passes Lighthouse and fails CrUX, that is not a mystery to celebrate, it is a diagnostic signal worth acting on. Tech Hub Services audits enterprise Core Web Vitals programs against real field data, isolates the hydration and third-party costs behind poor INP, and ships the fixes with CI guardrails that stop the gains from eroding. If responsiveness is the metric holding your site back, a targeted performance audit is the fastest way to find out why.
