Core Web Vitals Work Driven by Field Data, Not Lighthouse

Core Web Vitals are assessed at the 75th percentile of real Chrome users over a rolling 28-day window, which means a Lighthouse score is not evidence of anything and a genuine fix will not appear in field data for roughly four weeks after it ships. That fact decides how the work is sequenced: field measurement first, one change at a time, and no claim about an outcome until the window has turned over. INP is where the properties I see in fintech and energy fail. The threshold is 200 milliseconds, and a page carrying a consent platform, a device-fingerprinting script, a chat widget and a tag manager loading nine vendors will not hold it whatever the framework underneath. How the diagnosis works: Field data first — CrUX at origin and page-group level, then your own RUM. Where there is no RUM I install the web-vitals library with the attribution build, which reports the actual LCP element, the script occupying the main thread during the worst interaction, and the node that shifted. That is the difference between knowing INP is 480ms and knowing which event handler owns it. Two weeks of collection before I recommend anything. Lab tools reproduce a specific finding; they never decide what gets worked on. What usually turns out to be true: Third-party JavaScript is the largest single cost and the hardest conversation, because most tags belong to marketing, one is required by legal, and nobody holds the inventory. I produce that inventory with a measured main-thread cost per tag and hand it to whoever can authorise a removal. Beyond that the recurring findings: hydration on routes that never needed to be interactive, font loading blocking the LCP text, an image pipeline serving one 2400px asset to every viewport, and long tasks from a vendor bundle that only had to run after first input. What I do in the code: Changes land as separate pull requests, each small enough that RUM attributes an effect to it. Route-level splitting, consent-gated and deferred third-party loading, font subsetting with a preload the subset actually needs, responsive image generation in the asset pipeline, main-thread work moved off the critical path where the framework permits. I work in Next.js, Nuxt, Rails and plain server-rendered stacks, and I read the code before proposing anything to it. Not included: Framework migrations. If the honest answer is that your Angular application cannot reach 200ms INP without being rebuilt, you will hear it in week two and we will close the engagement rather than spend a quarter proving it slowly. Server, database and API latency beyond establishing that TTFB is the constraint and where it originates — your backend team owns that fix and I will give them the traces. Removing scripts that fraud prevention or legal requires; I quantify the cost so the trade is made against a number, and the decision stays yours. Who this is not for: Anyone whose brief is a Lighthouse score for a board slide. That number can be reached dishonestly in an afternoon and I have no interest in the exercise. Teams without deploy capacity during the engagement — the method needs changes reaching production every fortnight or it collapses into guesswork. Sites with too little traffic for CrUX to report a page group, where there is no field data to measure against and lab numbers would be the only thing I could sell you.