The INP bill goes to the wrong department: ad script, not RAM

Around 88 percent of that ad weight is JavaScript ^[2], which puts roughly 13 percent of the browser's whole payload in ad script alone ^[6]. Script is the part that occupies the main thread, and the main thread is where INP is measured ^[3]. A heavy image is a different problem with a different owner.

That 13 percent is advertising only. It does not include the tag manager container or the video embed, which the dev.to write-up puts in the same queue for the same reason ^[13]. The two Core Web Vitals that get treated as one metric are not: LCP is mostly a network and asset question, INP is almost entirely a JavaScript architecture question ^[4]. A faster origin sends the HTML sooner and leaves the main thread exactly as busy as it was ^[5].

The inventory in the post is worth reading as a bill of materials. One Google Tag Manager container holding ten tags, three of which attach global listeners across the whole document ^[9]. A chat widget loaded synchronously in the head, because that is what the vendor's documentation said to do ^[10]. A remarketing pixel from a campaign that stopped eight months earlier and was never pulled ^[11]. According to the author, none of this surfaces in a hosting uptime report ^[12], which is why the monthly invoice keeps arriving at the department that cannot fix it.

The evidence path matters more than the accusation. The author's sequence: find the specific URLs with field data in the Search Console INP report rather than stopping at the URL group ^[15], expect contact pages, filtered catalogue pages and checkout to be the offenders because that is where interaction happens ^[16], then reproduce in DevTools with the Performance panel throttled 4x to 6x to imitate a mid-range device ^[17], and read the main thread for long tasks over 50 ms with the third-party filter on ^[18]. Note what the throttle does to the threshold: work that measures 50 ms on a developer laptop lands between 200 and 300 ms on the device the throttle is imitating ^[19]. The 50 ms line is not a lab curiosity, it is a fifth of a second of unresponsiveness on the hardware most visitors are holding.

One claim in the post is asserted rather than measured: that the fix takes a single sprint and moves no bytes to a new server ^[20]. No before-and-after INP delta is published to support it, and the ad weight figures are relayed from adPerf research rather than measured on any of the sites described ^[1][2]. What survives the scrutiny is the direction of causation, which the Search Engine Journal guide the author cites states independently ^[22]: the code runs in the visitor's browser, so that is where the reading has to be taken. The phase breakdown costs an afternoon of DevTools time. The migration costs every month after it.