JS Execution Time.

Performance Core Web Vitals & Page Load

Heavy JavaScript execution blocks the main thread — keep it under 3.5s

What does this check test?

This check measures the total time the browser spends parsing, compiling, and executing JavaScript during page load. JavaScript execution happens on the main thread, which is also responsible for layout, painting, and handling user input — so heavy JavaScript execution blocks all other main-thread work. Lighthouse flags pages where JavaScript execution exceeds 3.5 seconds total. The cost of JavaScript includes not just execution time but also parsing (converting source text to AST) and compilation (converting AST to bytecode/machine code), which can be significant for large bundles.

Why does it matter?

JavaScript execution time is the primary contributor to Total Blocking Time (TBT) and directly impacts Time to Interactive (TTI). While a large image merely delays its own display, heavy JavaScript blocks the entire page — users cannot scroll, click, or type while JavaScript monopolizes the main thread. JavaScript cost also scales with device capability: code that runs in 500ms on a desktop MacBook can take 3-5 seconds on a mid-range Android phone. This makes JavaScript execution time a critical equity issue for users on lower-end devices.

Who is affected?

Single-page applications with large frameworks (React, Angular, Vue with heavy component trees), sites with complex data visualization (D3, Chart.js), sites performing client-side data processing (sorting/filtering large datasets), and any site that initializes many interactive components on page load are most affected. Sites targeting emerging markets where users primarily use mid-range Android devices are disproportionately impacted.

Where does this apply?

Use Chrome DevTools Performance panel to see JavaScript execution time per script in the Main thread flame chart. The Bottom-Up tab shows total self-time by function. Long yellow bars in the flame chart indicate JavaScript execution. Lighthouse breaks down execution time by script URL in the 'Reduce JavaScript execution time' diagnostic. Common hot spots: framework initialization, component mounting/hydration, third-party analytics scripts, and data transformation code.

How to fix it

Reduce the amount of JavaScript sent to the browser through code splitting and tree shaking. Defer non-critical initialization:

requestIdleCallback(() => {
  initAnalytics();
  initNonCriticalWidgets();
});

Move expensive computation to a Web Worker:

// main.js
const worker = new Worker(
  new URL('./heavy-task.worker.js', import.meta.url)
);
worker.postMessage(largeDataSet);
worker.onmessage = (e) => renderResults(e.data);

Replace heavy libraries with lighter alternatives — e.g., Preact (3KB) instead of React (40KB), vanilla JavaScript instead of jQuery. Use `React.memo`, `useMemo`, and `useCallback` to prevent unnecessary re-renders in React. Debounce expensive event handlers (scroll, resize, input) to reduce execution frequency. Use the `scheduler.yield()` API (or `setTimeout(0)` polyfill) to break up long tasks and let the browser process user input between chunks.

References

AppVet checks JS Execution Time automatically

Run a free performance scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit

← All checks