Core Web Vitals repair on ad-funded editorial pages

On an ad-funded editorial page the ad stack owns most of the main thread, and the vital that fails first is INP rather than LCP. Google's bar is 200 milliseconds at the 75th percentile of field data. The pages we get called about sit between 260 and 450, and the code responsible is almost never the code the publisher suspects. Where the milliseconds are: gpt.js is not the problem. A Prebid bundle taken from the hosted default carries adapters for exchanges you hold no contract with, and each adapter you do use adds its own user sync and its own response parsing. Identity modules compound it: every module is a separate network call, a storage write, and a block of parsing that runs inside the window where your reader first taps something. Then there is the code earning nothing at all, the heatmap tool nobody has opened since the redesign, the chat widget on a site with no support team, a tag manager container holding sixty tags of which twelve fire. In the last four editorial repairs we ran, the largest single INP contributor was a non-revenue tag every time. The consent banner deserves its own line. On a large share of European and Turkish mobile traffic the banner is the LCP element, and a CMP served from a third-party origin without a preconnect turns a 1.9 second LCP into a 3.4 second one before a single ad has been requested. How we measure: CrUX at the 75th percentile over the trailing 28 days is the scoreboard, because it is the number Search consumes and the number your actual readers produce. Diagnosis runs on your own real-user data using the attribution build of web-vitals, which returns the interaction target, the phase where the time went, input delay against processing against presentation, and the script that blocked. Lighthouse is a lab tool and we do not optimise against it. A page can score 92 in the lab and fail INP in the field for a reader on a three-year-old Android over a Turkish mobile network, and that reader is the one Search is counting. What the repair usually is: A Prebid build compiled with only the modules you have contracts for. Moving a subset of bidders to Prebid Server so their JavaScript never reaches the device, weighed against the match rate that move costs, and you get that number before we make the change. Breaking the long tasks that sit inside interaction handlers so the browser can paint between them. content-visibility on below-fold sections. Reserved boxes sized from the size map, so layout stability stops depending on which creative wins the auction. Non-revenue third parties moved behind an idle callback or a first interaction. Partytown gets evaluated on most of these engagements and rejected on most of them, because the moment a script needs synchronous DOM access it costs more than it saves. The trade we make explicit: Every fix that costs money is priced before it ships. Dropping an identity module is worth a specific number of milliseconds and a specific loss in addressable inventory, and the decision is yours rather than ours. We have told publishers to keep a module and accept a worse INP, because the arithmetic said so and the arithmetic was on the table. Not included: Server and CDN work, CMS replacement, image pipeline rebuilds. When your LCP turns out to be an unoptimised hero image we will say so and hand it to your team, because it is a different job and it is cheaper done in-house than billed by us. Say no to us if: The site is a single-page application where route transitions are the failure. That is an application rebuild and we are the wrong shop for it. Or if the goal is a green lab score for a board slide, because the field data will not follow the lab number and the gap becomes your problem in the quarter after we leave.