Core Web Vitals and INP fixed against CrUX p75 data

Chrome UX Report publishes the 75th percentile of your real users' Interaction to Next Paint over a trailing 28-day window. The earliest honest read on anything I ship is therefore four weeks after it reaches production, and the settled read is eight. If you need a number for a board meeting next Tuesday, buy a Lighthouse screenshot from somebody else. What this engagement decides: Which templates are failing, for which device class, and whether the cause is code you control. INP failures cluster in three places: a consent platform binding its own handlers ahead of yours, a tag manager container that executes on first interaction, and a client framework re-rendering a whole route in response to a keystroke. Only the third one lives in your repository. The other two are procurement and marketing decisions, and I will say that in the room where those people are sitting. Who does the work: I do, and nobody else. Ten years on production front ends, the last four on nothing but field performance. The decision I am most often hired to make is the one nobody internally can make alone. In 2024 I told a DTC client that their session replay tool had to come off logged-in pages. They liked the tool, the growth team had bought it, and it was worth 340ms of p75 INP on the cart. That is the shape of the work. How the evidence is gathered: Field first. The PageSpeed Insights API for the current CrUX record on each URL group, and the CrUX BigQuery tables for the month-by-month history behind it, so we argue about a trend rather than about a Tuesday. Then Long Animation Frames in your own RUM, through the web-vitals attribution build, sending to whatever pipeline you already have. No new vendor. Attribution returns the interaction target selector, the script that blocked, and the phase, whether input delay, processing duration or presentation delay, so the fix is aimed instead of guessed. DevTools traces come last, only to reproduce what the field data already proved. The thresholds: INP at or under 200ms and LCP at or under 2.5s at p75, on mobile, on the templates that carry revenue. Not the mean. Not desktop. Not the homepage, unless the homepage is where your money actually is, which for most catalogues it is not. What you may not want to hear: Around a third of the engagements I take end with the largest single win being the removal of something the client is paying for. The next most common finding is that a framework upgrade is the honest fix and a six-week one. Hydration cost on a route that streams badly is not something I can patch around with scheduler.yield sprinkled over event handlers. When that is the answer, I write it as the answer and give you the sequencing, rather than shipping cosmetic work to fill out the contract. Not included: No design changes, no copy, no experiment implementation, no backend re-architecture, no CDN or CMS procurement. I do not chase Lighthouse scores and I will not report on them. I do not run your release train either. If your deploy cadence is monthly, the calendar of this engagement is your calendar, not mine. Not a fit if: Your URL groups carry too little traffic to appear in CrUX at page level. Then there is no field record to move, and an origin-level engagement is the only honest version of this. Also not a fit if the front end is owned by an agency you are not allowed to instruct, or if a redesign lands inside the measurement window, which invalidates every reading taken before it. Working arrangement: English, Czech or German. Central European hours, with overlap into US Eastern time on request. I work on your branch conventions, with pull requests reviewed by your engineers before they merge. Every change ships behind whatever flag system you already run, so any one of them can be reverted on its own and the field data can show which one mattered.