Core Web Vitals Engineering for Mid-Range Android

The only number we work to is the 75th percentile of your CrUX field data over the rolling 28-day window, segmented by device. That single choice decides the whole engagement. A mid-range Android phone on an Indian 4G connection executes JavaScript roughly four to six times slower than the laptop your Lighthouse score was measured on, so a lab score of 92 alongside a failing INP at p75 is not a contradiction, it is the normal condition of a React catalog. We report field data. We do not report a Lighthouse score, and where a contract is written against one we decline the contract. Where the time actually goes on a catalog page: LCP is almost always the first product image in the grid, late for three reasons at once: it sits inside a lazy-loading component, the image CDN transforms it on first request instead of serving a warm variant, and the browser discovers it late because it arrives from a hydration pass rather than from HTML. INP is dominated by the filter and sort interaction, where one long task on the main thread holds off the response to a tap for hundreds of milliseconds. CLS on furniture and marketplace listings is usually a promotional banner injected after paint plus a font swap on the price. What we change: fetchpriority on the first row of images and their removal from any lazy path, explicit width and height everywhere, a preconnect to the image origin, and warmed variants so the first visitor is not paying for the transform. Long tasks broken up so input has somewhere to land. Filter state moved into the URL, which turns the interaction into navigation your framework already optimises rather than a bespoke re-render nobody profiled. Hydration deferred below the fold and removed outright from components that are not interactive. Font strategy decided instead of defaulted. Where the server is the bottleneck we say so and work on cache keys and rendering rather than pretending it is a front-end problem. Third-party scripts: We measure them, we do not unilaterally remove them. Every tag receives an attributed cost in milliseconds of interaction delay and blocking time, taken from Long Animation Frames data in the field rather than guessed in a lab, and that list goes to whoever owns the marketing budget. Keeping a chat widget that costs 240ms is a business decision and it is not ours to make. What we will not accept is a target that can only be reached by removing tags nobody has agreed to remove. How we prove it: web-vitals in the browser with attribution, reporting to your own endpoint, so we can see which element and which handler on real sessions instead of on a throttled emulation of a device nobody owns. A baseline captured before anything ships, then per release, segmented by device class and by template. CrUX moves on a 28-day trailing window, so honest confirmation of a change arrives about four weeks after it lands and we will not claim it sooner. What we refuse: Chasing a hundred. The last fifteen points of a lab score come from work with no measurable field effect and we will not bill for them. Rewriting your framework as an opening move. And engagements where hosting or CDN is locked by somebody else's contract and TTFB is the actual problem: we will diagnose it and put the number in writing, but the fix belongs to whoever can change the contract. Who this is not for: Teams who want a report. This is engineering time inside your repository, reviewed by your own people. The retainer only makes sense where there is a release cadence to attach to, and if you ship quarterly you should buy the project instead.