Reduce JavaScript Execution Time: How to Check and Fix It

What is JavaScript execution time?

Put simply, this is the time the browser's main thread spends parsing, compiling and running your code in the V8 JavaScript engine (or its equivalent). While that thread is busy it can't paint or answer a tap, a state called main thread blocking, so a script-heavy page feels stuck even when every file has already downloaded.

Download time is a separate problem. A small script with a heavy loop can cost more than a large library that mostly sits idle, so JavaScript payload alone tells you little. The cost usually comes from several places: your own bundles, jQuery plugins, a tag manager, ad code, chat widgets, analytics and social embeds.

In PageSpeed Insights you'll meet this topic as the Lighthouse audit called Reduce JavaScript execution time, which Lighthouse knows internally as bootup time. According to the Lighthouse source code, the audit turns orange above about 1.3 seconds and red above 3.5 seconds on its slowed mobile profile. The Lighthouse bootup time audit documentation page was last updated in 2019 and still quotes 2 seconds as the warning point, so don't be surprised when the two sources disagree.

Two neighbouring metrics are easy to mix up with it. Total Blocking Time adds up the part of every long task beyond 50 ms, where a long task is any single stretch of main thread work over 50 ms. Interaction to Next Paint measures how quickly the page reacts after a real click or tap. Execution time is the raw script cost behind both.

How our JavaScript execution time test works

Here is exactly what our report does, so you can judge the result and reproduce it yourself.

The exact rule: the report line called Execution Time shows domContentLoadedEventEnd minus responseStart, in seconds, rounded to two decimals. 1.0 s or less passes, above 1 s up to 3 s is a warning, and above 3 s fails.

The report loads your page in headless Chromium driven by Playwright inside a container, using the default desktop settings with no CPU or network throttling. It waits for the load event with a 20 second limit, then reads the Navigation Timing entry. Because the clock is wall time, the window also holds the time to receive the HTML, to download scripts that block or are deferred, and to wait for blocking stylesheets, not only the CPU time of your code.

What counts is the HTML parse plus every script that runs before the DOMContentLoaded event: classic, defer and module scripts, and async scripts when they happen to land before that event. What doesn't count is anything injected after load, on first interaction or when the browser is idle. That is exactly why postponing a script lowers our number.

What the report measures

The window starts at the first byte of the server response and ends when the DOMContentLoaded handlers finish. The entry comes from the Navigation Timing API (a PerformanceNavigationTiming object), and the domContentLoadedEventEnd on MDN page in the MDN Web Docs documents the property.

What pass, warning and fail mean

The limits are 1.0 s and 3.0 s. A warning shows a warning icon, and a fail shows an error icon, yet both open the same How to Fix button. The score treats each check as passed or not passed, so a warning costs exactly as many points as a fail, and only passed checks add to it.

Why it differs from Lighthouse

The clock and the window are different. Ours is plain wall time from the first server byte to DOMContentLoaded. Lighthouse sums script evaluation time and script parse time for every file, on a throttled phone profile. Treat our result as a quick yes or no, then open PageSpeed Insights for the per script list. Run the check twice, because server response time and third party hosts shift the figure a little between runs.

Scripts that start after load, long tasks, Interaction to Next Paint and per script CPU time are not tested here. When you're ready, run the free report on any page you care about.

What is a good JavaScript execution time?

It depends on which tool produced the number, because the three common ones use different clocks and units. Seconds in our report and milliseconds in Interaction to Next Paint are not interchangeable.

As a rule of thumb, aim for under 1 s in our report, then confirm the page in PageSpeed Insights.

Why JavaScript execution time matters for SEO and users

When the main thread is blocked, the first paint arrives later and taps feel ignored. That shows up as a poor Interaction to Next Paint and a high Total Blocking Time, two measures of how responsive the page really is. Our Core Web Vitals guide covers the wider set.

Your own laptop flatters you. A mid range phone can take several times longer to run the same script, so a desktop pass may still be a miss for real visitors.

Google Search Central treats speed as a light signal, and Core Web Vitals sit inside it, so don't expect a jump in position from one fix. The bigger payoff is fewer people leaving and more of them finishing what they came to do. The post on page speed and SEO explains how the two connect.

How to find which scripts take the most time

You don't need to guess. A short routine points at the files that deserve attention first.

Find heavy scripts in DevTools

1. Run the report. Note the Execution Time value and its status, so you have a baseline to beat.
2. Record a reload. Open Chrome DevTools, choose the Performance panel, start a recording with reload, then read the Bottom Up tab sorted by self time to see the heaviest scripts and functions.
3. Check the Coverage tab. It shows how many bytes of each file never run on this page, which is a quick way to spot unused JavaScript. The Network panel, filtered to JS, shows which files are large and which hosts are third party.
4. Open PageSpeed Insights. Read the Reduce JavaScript execution time table for script evaluation and parse time per file, then write down the three biggest names.

Reproduce the report number in the console

You can read the same entry our report uses. Paste this into the DevTools console after the page has finished loading. Expect a different value, because your browser has extensions and caches.

const nav = performance.getEntriesByType('navigation')[0];
const seconds = (nav.domContentLoadedEventEnd - nav.responseStart) / 1000;
console.log(seconds.toFixed(2) + ' s');

Time one function in code

If you suspect a single function, wrap it with performance.now() from the User Timing API before and after, or use console.time for a quick label. A PerformanceObserver can also log long tasks from the Long Tasks API in Chromium based browsers.

const start = performance.now();
buildMenu();
console.log('buildMenu took', (performance.now() - start).toFixed(1), 'ms');

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Long task', Math.round(entry.duration), 'ms');
  }
}).observe({ type: 'longtask', buffered: true });

A developer machine is much faster than a phone, so treat these timings as a ranking of suspects.

How to reduce JavaScript execution time, step by step

Work through these six fixes in order, since the first two usually deliver the most.

1. Remove scripts you do not need

Old plugins, abandoned tags and dead widgets keep running long after anyone looks at them. Delete what you can't justify, because the script you don't ship costs nothing.

2. Trim or replace third party scripts

Chat widgets, heatmaps, A/B testing tools and social embeds are common offenders, and you don't control their code. Keep the ones that earn their place and load tags only on the trigger that needs them. For video embeds, use a script facade: a static preview image that loads the real player on click.

3. Split bundles and load only what a page needs

A single large bundle makes every page pay for features it never uses, so watch your bundle size. Use code splitting with dynamic import(), let your bundler such as webpack drop dead code through tree shaking, and build route level bundles so each page loads its own code.

Why defer alone isn't enough: our check counts scripts that run before DOMContentLoaded, and deferred scripts do exactly that. Defer only overlaps the download with parsing, so it barely lowers the figure, while loading code after the load event does. Be careful about waiting for first interaction, because that moves the cost into Interaction to Next Paint.

4. Move non-critical work after the load event

Anything the first screen doesn't need can start after the page is ready, which is how you lazy load scripts and delay JavaScript safely. Create the script element inside a load listener, and our report no longer counts it because it begins after DOMContentLoaded. Our number will fall even though the device still runs the script, so a heavy late script still shows up as Total Blocking Time and Interaction to Next Paint in PageSpeed Insights.

<script>
  window.addEventListener('load', function () {
    var s = document.createElement('script');
    s.src = '/js/chat-widget.js';
    s.async = true;
    document.body.appendChild(s);
  });
</script>

5. Break up long tasks

One 400 ms loop blocks everything for 400 ms. Chunk it, and hand control back to the browser between chunks so clicks and paints can happen. The Optimize long tasks guide explains the pattern in depth. For truly heavy calculations, move the work into web workers, which run off the main thread.

The loop below uses the Scheduler API and yields with scheduler.yield where it exists (Chrome and Edge 129 and later, Firefox 142 and later, not Safari) and falls back to setTimeout everywhere else.

async function processItems(items) {
  let lastYield = performance.now();
  for (const item of items) {
    handle(item);
    if (performance.now() - lastYield > 40) {
      if (globalThis.scheduler && scheduler.yield) {
        await scheduler.yield();
      } else {
        await new Promise((resolve) => setTimeout(resolve, 0));
      }
      lastYield = performance.now();
    }
  }
}

6. Minify, compress and cache

Smaller files parse faster, but the gain is modest, so treat it as housekeeping. To minify JavaScript, run files through our free JavaScript Minifier, serve them with Brotli or gzip, and give them long cache lifetimes so repeat visits skip the download. Our JavaScript minification check covers file size, and the guide to minify HTML, CSS and JavaScript walks through the steps.

If scripts in the head hold up rendering as well, check the render blocking resources result next.

How to reduce JavaScript execution time in WordPress, Shopify and frameworks

The principles stay the same everywhere, but the switches live in different places.

WordPress

Audit your plugins and page builder add-ons such as Elementor, and delete anything unused. Then unload plugin scripts on pages that don't use them, using the per page unloading option of an asset manager plugin. Caching plugins usually offer a delay JavaScript execution setting (the label differs), but retest forms and checkout afterwards.

Shopify

Uninstalling Shopify apps often leaves code behind in the theme files. Go to Online Store, Themes, Edit code, then search theme.liquid and the snippets folder for the names of apps you removed, and delete the leftovers. In the theme editor, the App embeds tab lets you switch off embeds you don't need.

Next.js and React

Load heavy components with next/dynamic and keep client components small, which limits React hydration work. For third party scripts, next/script with the lazyOnload strategy waits for an idle browser.

Google Tag Manager

Delete unused tags and keep one tag per vendor. Fire non-essential tags on the Window Loaded trigger.

Common mistakes when cutting JavaScript time

Test after every change: deferring or delaying everything at once can silently break menus, forms and consent banners, and you won't know which change did it.

• Delaying all scripts until first interaction. It hands the cost to Interaction to Next Paint and loses early analytics hits.
• Trusting minification alone. It shrinks bytes, not the work the code performs.
• Testing once, or while logged in as an admin. Admin sessions load extra scripts, and one run can be an outlier.
• Comparing numbers from different tools. Our window from server response to DOMContentLoaded, Lighthouse CPU time and Interaction to Next Paint in milliseconds measure three different things, as the table above shows, so a gap between them is not a contradiction.
• Adding an optimization plugin that ships its own heavy script. A minification or lazy loading plugin can inject its own loader script, so compare Execution Time before and after you install it.