INP went from 150ms to 400ms the week a marketing tag was added. Marketing says the script is async and cannot be the cause. How do you prove it either way and fix it?
Async controls when a script downloads, not what it does to the main thread once it executes, so an async tag can still block interaction handling. Prove it with field data attributed to the interaction: INP breaks into input delay, processing and presentation, and each points elsewhere. Then move the work off the critical path.
Answer
Short answer
async only means the download does not block parsing. Once the file arrives, it executes on the main thread like any other script, and if that execution takes 300ms nothing can respond to a click during it. The claim confuses fetching with running. Prove it with field data, decomposed into INP's three phases so you can point at which part grew, then move the work off the interaction path rather than arguing about the tag.
Was this answer helpful?
Likely follow-ups
- Which of the three INP sub-parts would a third-party script most likely inflate, and why?
- Lab tests in CI show no regression at all. What is your explanation?
- How would you attribute INP to a specific script rather than to the page in general?
- Marketing will not remove the tag. What can you still do?
- What would you put in place so the next tag cannot do this silently?
Related questions
- Field data says your page has an INP of 400 ms. How do you find the cause and fix it?hardAlso on core-web-vitals and inp4 min
- A page has a poor Largest Contentful Paint. How do you diagnose it and what do you actually change?hardAlso on core-web-vitals7 min
- Users say the page jumps around while it loads, but your synthetic audit reports no layout shift at all. How do you find it and fix it?hardAlso on core-web-vitals6 min
- How do you resolve unacceptable INP degradation caused by massive, synchronous JavaScript execution blocking the main thread?hardAlso on inp3 min