Reduce JavaScript Execution Time: How to Fix It

What this means

Why it matters

How to fix it

1. 1

   Profile the page to find what actually runs

   Open Chrome DevTools, go to the Performance panel, and record a page load with CPU throttling set to 4x or 6x to approximate a real phone. Look for long tasks (blocks over 50ms) and expand them to see which scripts they belong to. Run Lighthouse and open its "Reduce JavaScript execution time" and "Reduce unused JavaScript" audits, which name the exact files and the milliseconds each one costs. Use the Coverage tab (Ctrl/Cmd+Shift+P, then "Show Coverage") to see what percentage of each bundle is never used. This tells you whether the problem is your own code, a framework, or a third-party tag.

2. 2

   Ship less code: split bundles and remove dead code

   The most reliable fix is sending fewer bytes of JavaScript. Enable code splitting so each route loads only the JS it needs, and use dynamic import() for components that are not needed on first paint (modals, carousels, editors, charts). Turn on tree-shaking and minification, which are on by default in production builds for Webpack, Vite, esbuild, and Next.js. Audit dependencies: replace heavy libraries like moment.js with date-fns or the native Intl API, and drop utility libraries you use one function from. Every kilobyte you delete is parse and execution time you never pay again.

3. 3

   Defer and lazy-load non-critical scripts

   Add the defer attribute to script tags so they download in parallel but execute after HTML parsing finishes, in document order, keeping the main thread free during initial render. Use async only for independent scripts like analytics that do not depend on the DOM or on each other. For anything below the fold or triggered by interaction (chat widgets, comment embeds, video players, social buttons), load it on scroll or on click instead of at page load. This alone can move several hundred milliseconds of execution out of the critical path.

4. 4

   Rein in third-party tags and tag managers

   Third-party scripts are often the biggest offenders and the hardest to spot, because a tag manager can inject many tags that each run their own JavaScript. Audit every tag, remove the ones you no longer use, and load the rest as late as possible. Consider running third-party scripts in a web worker off the main thread (Partytown, or Cloudflare Zaraz), or self-host and defer analytics. Set a performance budget so no single tag can silently add a second of execution time. Marketing tags are the most common reason a page scores well in the lab but fails INP in the field.

5. 5

   Prefer server-rendered HTML over heavy client hydration

   On a JS framework (React, Vue, Angular), large client-side hydration is a top source of bootup cost, because the browser rebuilds and reattaches your entire component tree in JavaScript. Use server-side rendering or static generation so the HTML arrives ready, and adopt patterns that reduce hydration: React Server Components, islands architecture (Astro), or partial hydration so only interactive widgets ship JS. This cuts execution time and puts your real content in the initial HTML, where AI crawlers and Google's first-pass indexer can read it without running any script.

6. 6

   Re-audit and set a budget to prevent regressions

   After your changes, re-run the audit and a throttled Lighthouse pass to confirm execution time and TBT dropped, then watch field INP in PageSpeed Insights (CrUX) or Search Console over the following weeks, since field data lags real-user traffic. Lock the win in with a JavaScript size budget in CI, for example failing the build if the main bundle grows past a set kilobyte limit, so a future dependency or tag does not quietly undo the fix.

Example

<!-- Analytics: independent, can run whenever it downloads -->
<script async src="/js/analytics.js"></script>

<!-- App code: runs after HTML is parsed, in order -->
<script defer src="/js/app.js"></script>

<!-- Heavy chat widget: don't load it at page load.
     Inject it only when the user is about to need it. -->
<script defer>
  const loadChat = () => {
    if (window.__chatLoaded) return;
    window.__chatLoaded = true;
    const s = document.createElement('script');
    s.src = 'https://widget.example.com/chat.js';
    s.async = true;
    document.body.appendChild(s);
  };
  // Load on first interaction or when the button scrolls into view
  document.getElementById('open-chat')
    ?.addEventListener('click', loadChat, { once: true });
  window.addEventListener('scroll', loadChat, { once: true, passive: true });
</script>

Defer non-critical scripts and lazy-load a heavy third-party widget only when it's needed, keeping it off the main thread during initial load.

Platform-specific steps

Frequently asked