A JavaScript coverage report shows which code ran during an observation. Code left unexecuted during startup may still power a menu, checkout or another route. Use the report to select an investigation, then verify the affected user journeys before changing the bundle.
Start with the resource and the conditions
Run Milten JS Scanner for the page you want to investigate. Keep the URL, date and selected conditions with the result. The scanner observes one page load without clicking or scrolling. It reports script loading, coverage and JavaScript errors; it cannot prove that a file is unnecessary throughout the site.
Compare a file's loading data with its execution data. A large transfer, a long execution period and a high unexecuted share are different observations. A script can download quickly yet keep the main thread busy. A file that did not load has no useful execution measurement for that run.
Follow an illustrative checkout example
Suppose app.js includes code for both the landing page and checkout. The checkout function does not execute when the landing page opens. This is a teaching example, not a measured customer result.
Find the resource URL and inspect how the page imports it. Open checkout, use the menu and visit other pages that share the bundle. Record which actions were tested. In Chrome DevTools Coverage, recording can continue while you interact with the page. That broader observation answers a different question from a startup-only scan.
If checkout needs the code, removing it would break a useful action. Loading that feature when the user reaches checkout may be worth investigating. The decision depends on the application and the effects on the next interaction.
Use source maps when they are available
A source map can connect a generated bundle to source modules. Milten's module view depends on a valid, supported map that the scanner can read. An absent map leaves that part of the report incomplete. The resource and error findings can still help locate a problem.
Without a usable map, inspect the resource's import path and your build output. Do not treat a missing module view as evidence that all code was executed. The source map guide from MDN explains the relationship between generated and original code.
Make one change and test the affected journey
Choose a confirmed opportunity, such as separating an infrequently used feature or delaying an optional integration. Keep the change small enough to compare. Check that the required feature still works, that no new console errors appear and that the network loads the intended files.
Use Speed Scanner to inspect the loading outcome and INP Scanner to investigate a slow interaction. TBT and long tasks from a startup scan do not measure the same thing as field INP. For objects that accumulate after repeated navigation, use Memory Leaks and reproduce the reported path.
Compare comparable runs
Repeat the same URL under the same device, network and cache conditions. Preserve both reports and record which interactions you tested manually. Verify the production build after publishing the code change; a development bundle can behave differently.
Can I remove every unexecuted byte?
No, the result describes an observation interval, not every possible state of the application. Test the relevant actions and shared routes before removing code.
Does a smaller bundle guarantee a faster page?
No, loading order, server response, execution and subsequent interactions also matter. Compare the user journey as well as the file size.
Analyze a page's JavaScript. For the wider loading context, read website speed and SEO.