Interactions are slow, and much of the page's JavaScript never runs
Updated
What this check looks for
At the 75th percentile, real visitors wait over 500 ms for the page to respond to a tap or click, and much of the JavaScript it loads never runs.
In a report, this finding reads as follows, with each ‹…› filled in from what that scan observed:
Interactions on ‹field scope› take ‹inp value› to respond for real visitors at the 75th percentile, where Google's threshold for poor is 500 ms. The page also downloads ‹total js› of JavaScript, of which roughly ‹unused bytes› never runs during the load — and dead code almost always travels in the same bundles as the code the page does need. That is where we would start.
Why it matters
Your visitors are waiting for the main thread before the page answers a tap. Code that never executes is not the cause on its own, but it is shipped, fetched and queued alongside the code that is, so splitting it out is usually the cheapest way to give the thread back. This costs you no points: the slowness is scored once, where it was measured.
When the check passes, your report says: “The page ships close to the JavaScript it actually uses”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- high
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- Performance
- Module
- Perf lab
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Ship only the JavaScript this page needs to render and respond, and load the rest on demand.
Real visitors wait ‹inp value› for this page to answer an interaction, and roughly ‹unused bytes› of the JavaScript it downloads never runs during the load.
Split the bundle by route, so a visitor to one page does not download the code for the rest of the site.
Load interaction-only code on the interaction — dynamic
import()inside the event handler is enough, and the network cost lands when the user has already committed.Audit third-party scripts against what they earn. In Chrome DevTools, Coverage shows the unused share per file; anything above 80% unused is a candidate for removal or deferral. A script you cannot remove — an ad or consent tag — can nearly always still be loaded after the page is interactive.
Defer everything that is not needed for the first render, so parsing does not compete with the initial paint.
Check for duplicated dependencies across chunks — shipping two copies of the same library is common and invisible without looking.
How to confirm it worked
Re-run this scan and confirm the transferred JavaScript total and the unused share have dropped.
In Chrome DevTools, open Coverage, reload, and confirm the unused bytes figure has fallen.
Watch the field Interaction to Next Paint over the following month: it is a 28-day window, so it moves weeks after the deploy, not days.
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Remediation by platform
// Ship the code for an interaction when the interaction happens.
button.addEventListener('click', async () => {
const { openEditor } = await import('./editor.js');
openEditor();
}, { once: true });
<!-- And keep what does load out of the critical path. -->
<script src="/analytics.js" defer></script>{ once: true }avoids re-importing on every click; the module cache would make that cheap anyway, but the intent is clearer. The win is thateditor.jsis never fetched by the visitors who never open the editor.
Technical detail
Interaction to Next Paint, 75th percentile: **‹inp value›** (‹field level›). JavaScript transferred: **‹total js›** across ‹scripts›; unused on load: **‹unused bytes›** (‹unused percent›%).
‹detail›
This came from **one page load we performed**, not from your visitors. A lab measurement is reproducible and tells you exactly which bytes and which resources are responsible — which is why the numbers below are byte counts and resource lists rather than a score. What real visitors experience is in the field-data section, which is the evidence this report scores Core Web Vitals on.
**Why both numbers, and why neither of them costs you points here.** The unused figure on its own is not a fault. Its certain cost is the bytes your visitors download; the parse and compile cost it is famous for is much smaller than the folklore, because the engine only fully compiles a function when something first calls it, so code that never runs is never compiled. What makes it worth acting on here is that the field data shows this page is measurably slow to respond, and dead code is the commonest reason a bundle is larger and later than it needs to be.
That slowness is scored **once**, in the field-data section, on the rule that measures it. Deducting again here would charge one harm twice — once where it was measured and again where it is explained — and would make a page look worse for having its cause diagnosed. So this finding is prominent and it is free. On a page whose interactions are quick we report the same bytes as a plain observation instead.
**"Unused" means the bytes were never executed during the page load.** Some of that is legitimate — code behind an interaction that has not happened yet — so this is not a demand to delete it, it is a demand to stop shipping it up front. The distinction is code splitting, not code removal.
**The responsiveness number is not ours.** It is the Chrome UX Report's, measured on your visitors' own devices over a 28-day window. The blocking time in the lab section above was measured on our hardware under our throttling and is not on the same scale as Google's published thresholds, which is why it is reported and not scored.
Some of the largest contributors are usually code you did not write. We do not tell you which, because we cannot establish it honestly: the only thing we can see is the address a script was served from, and a site's own bundles frequently live on a different domain from its pages. Read the list above and you will recognise your own.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.