Reduce JavaScript Execution Time: How to Fix It

What this means

Every script your page loads goes through three steps before it can do anything useful: the browser parses the file into something it understands, compiles it into executable instructions, and then executes it. All of this happens on the main thread, the same single thread the browser uses to render layout, paint pixels, and respond to user input.

The "Reduce JavaScript execution time" audit measures how long that combined parse, compile, and execute work takes. When the total is high, the main thread is tied up running code instead of reacting to the person using the page. Lighthouse breaks the result down per file, so you can see exactly which scripts are the most expensive and where to focus.

Why it matters

JavaScript is the single most expensive resource type a page can ship, byte for byte, because it has to be processed and run, not just downloaded and displayed. While the main thread is busy executing a script, it cannot handle a tap, a scroll, or a keypress. The page appears finished but feels frozen.

That delay shows up directly in two metrics. Total Blocking Time (TBT) sums the portions of long tasks (anything over 50 milliseconds) that block the main thread during load. INP (Interaction to Next Paint), a Core Web Vital, measures how quickly the page responds to real interactions. Long script execution inflates both, so reducing it improves perceived speed, responsiveness, and your Core Web Vitals scores at the same time.

How it gets flagged

Lighthouse runs your page in a simulated environment and adds up the time spent in JavaScript work. It shows a warning when execution exceeds 2 seconds and fails the audit when it exceeds 3.5 seconds. To help you act on it, the report lists each script your page loads alongside the time spent evaluating, parsing, and executing that file, so the heaviest offenders rise to the top.

SEO ProCheck surfaces this as a performance issue when a scanned URL crosses those thresholds. Treat the per-file table as your priority list: the script with the largest execution time is almost always where the biggest win lives.

How to fix it

1. Ship less JavaScript

The cheapest code to run is code you never send. Audit your dependencies, drop libraries you only use for one small feature, and prefer lighter alternatives. Minify and compress everything you do ship so the browser has less to parse.

2. Code-split your bundles

Split one large bundle into smaller chunks so the page only loads and runs the code needed for the current view. Critical above-the-fold code executes first, and everything else loads on demand. This shortens the parse and execute work during initial load, which is when blocking hurts most.

3. Defer and lazy-load non-critical scripts

Add defer or async to scripts that are not needed for the first render so they stop blocking parsing. Lazy-load code tied to interactions or below-the-fold components only when the user actually reaches them, rather than running it all upfront.

4. Remove unused JavaScript

Dead code is still downloaded, parsed, and compiled even when it never runs, so it taxes boot-up time for nothing. Use Chrome DevTools coverage tooling to find unused bytes, then tree-shake and prune. See Remove unused JavaScript for the full process.

5. Optimize hot code paths

Profile execution in the DevTools Performance panel to find the functions eating the most time. Cache repeated calculations, avoid forced layout work inside loops, and break long-running functions into smaller chunks so the browser can yield to user input between them.

6. Move heavy work to web workers

For genuinely heavy computation that does not touch the DOM, web workers run code on a separate thread so the main thread stays free to respond to the user. Note that this moves work rather than removing it, and the messaging overhead means it is best reserved for substantial tasks, not small ones.

7. Trim third-party scripts

Tag managers, chat widgets, A/B testing, and analytics often run more JavaScript than your own app. Audit each one, remove what you do not need, load the rest with async, and delay non-essential tags until after the page is interactive.

Related

This audit is closely tied to Minimize main-thread work. The difference is scope: "Reduce JavaScript execution time" counts only the time spent on JavaScript parsing, compiling, and execution, while "Minimize main-thread work" counts all main-thread activity, including style and layout, rendering, painting, and parsing HTML and CSS on top of scripting. Heavy JavaScript is usually the largest slice of main-thread work, so fixing this audit almost always improves the broader one too.

FAQ