INP and Core Web Vitals Work on Real Field Data

Google's threshold is 200 milliseconds at the 75th percentile. Sites that reach me usually sit between 320 and 600, and in nearly every case more than half of that figure belongs to three or four scripts that nobody in the building will defend by name. The work is identifying those precisely enough that the decision to remove them can actually be made. Field data or nothing: Lab tooling does not measure INP. Lighthouse reports Total Blocking Time, which correlates loosely and misleads specifically, and a page can score 98 while your customers wait half a second for a filter to respond. I instrument with the web-vitals attribution build, which returns the interaction target, the input delay, the processing duration and the presentation delay as separate numbers, together with the Long Animation Frames entry responsible and the script that occupied it. That split is the whole engagement. An INP of 480ms made of 40ms input delay and 390ms processing is a JavaScript execution problem owned by your front-end team. The same 480ms made of 300ms input delay is a main thread already busy before the user touched anything, which is a loading problem wearing an interaction costume, and it belongs to whoever controls the tag manager. Where it comes from on the sites I work on: Shopify themes carrying a dozen apps that attach listeners to every card in a collection grid. GTM containers with a custom HTML tag running synchronous work on click. React trees that re-render an entire product grid because filter state lives at the page root and nothing is memoised below it. Consent banners that block the thread while the user is trying to dismiss them, which is the only interaction some visitors ever make. Dealer inventory pages where a chat widget and a finance calculator both initialise on scroll. What I change, and what I ask you to change: Breaking long tasks with scheduler.yield where it is supported and a postTask fallback where it is not. Moving state down the tree so the render cost matches the affected subtree. content-visibility on offscreen sections when presentation delay, not processing, is the dominant term. Deferring listener attachment until first interaction. And, most often, a written case for deleting two tags, addressed to the person who owns the marketing stack rather than to the engineers, because that is where the decision actually sits. CLS and LCP: Both are in scope and both are usually simpler. LCP work here means the resource timing chain for the actual LCP element per template, not a generic image advisory. CLS means identifying the shifting element through the layout shift attribution entry rather than guessing at fonts. I do not spend the budget here unless the field data says these thresholds are failing. Not included: CDN selection or migration, server and origin infrastructure work, redesigns, and testing-platform strategy. No implementation on the diagnostic tier. I do not chase a Lighthouse score, and if what you want is a green number in a report for someone above you, I will tell you which two hours of work produce it and decline the rest of the engagement. Who this is not for: Sites without enough traffic to appear in CrUX. If your origin has no field data, instrument RUM yourself and collect a quarter of it before hiring anyone, including me. Teams that cannot remove or defer a third-party script under any circumstance, because on most sites that is where the number lives and the engagement becomes an expensive way to confirm it. And anyone whose vitals already pass at p75, where the honest answer is that further work will not move rankings and you should spend the money elsewhere.