Remove Unused JavaScript Without Breaking Your Site

What unused JavaScript means

Unused JavaScript is code downloaded by the browser but not executed during the measured page load. It increases transfer, parse, compile, and execution work. The impact is usually greater on slower mobile devices and can delay interaction even when a fast desktop test appears acceptable.

A coverage report is a snapshot of one user path. Code marked unused may support a menu, checkout step, form, experiment, or route that was not exercised during the test. Measure before deleting.

Find the expensive code

1. Run Lighthouse on a representative page and note the scripts with the largest potential savings.
2. Use the browser Coverage panel, reload the page, and exercise important interactions.
3. Use the bundle analyzer for the application framework to identify large packages, duplicate versions, and modules included in shared chunks.
4. Separate first-party code from tag managers, chat widgets, advertising, analytics, consent tools, and other third-party scripts.
5. Test multiple page types. A script may be necessary on checkout but unnecessary on a blog post.

Chrome documents the audit and its thresholds in Remove unused JavaScript.

Reduce first-party JavaScript

• Remove dependencies and modules that are no longer used.
• Import only the functions or components needed by the route.
• Split route-specific code instead of placing it in the global bundle.
• Lazy-load expensive features that are below the fold or opened after an interaction.
• Prefer server-rendered HTML for static content that does not need client-side behavior.
• Replace heavy libraries when a smaller native or project-standard solution provides the same result.
• Confirm that production tree-shaking and minification are working.

Dynamic import example:

const openChart = async () => {
  const { renderChart } = await import('./chart.js');
  renderChart();
};

Control third-party scripts

Load a third-party script only on pages where its function is required. Use consent-aware or interaction-based loading where appropriate, and review tag-manager containers for old tags. Removing one unused vendor script can be more valuable than micro-optimizing many small modules.

Avoid unsafe shortcuts

Do not defer every script without testing execution order. Do not remove polyfills without confirming browser support. Do not rely on one Lighthouse run or treat all red coverage as dead code.

Verify the change

Test navigation, forms, authentication, checkout, analytics, consent, and error states. Compare transferred JavaScript, main-thread work, Total Blocking Time, Interaction to Next Paint, and real-user data before and after. Roll out large removals gradually when the script supports revenue or authentication flows.