JS Execution Time Test
What is it?
JavaScript execution time is how long the browser spends parsing, compiling, and running the JavaScript on a page while it loads. Heavy execution blocks the main thread and is the primary cause of poor Interaction to Next Paint (INP), the Core Web Vital that replaced First Input Delay in 2024 and that Google uses as part of its ranking algorithms. This test reports the total parse, compile, and execution time for the page being checked.
Why JavaScript execution time matters
JavaScript is the most expensive resource your page ships per byte. The browser has to download it, parse it, compile it, and then run it, and every one of those steps competes for the same main thread that handles user interactions, animations, and layout. When a page ships hundreds of kilobytes of JavaScript, even a fast device can take several seconds before the page becomes responsive, and a mid-tier mobile device can take three or four times longer.
The cheapest JavaScript to execute is the JavaScript you never sent. Auditing your bundle for unused code, switching heavyweight dependencies for lighter alternatives, and splitting code by route so each page only loads what it needs are typically the highest-leverage changes you can make. Beyond that, deferring non-critical work (analytics, chat widgets, advertising) until after main content renders gives the user a usable page faster, which is exactly what INP measures.
Common causes of slow JavaScript execution
- Single large bundle: split by route or feature so the user only downloads and executes the code for the current page.
- Heavy third-party tags: load analytics, ads, and chat widgets after main content with
asyncordefer. - Unused JavaScript: audit with the Coverage tab in DevTools to find code that loads but never runs on the page.
- Long tasks blocking the main thread: break work into smaller chunks; move heavy computation to a Web Worker.
- Polyfills shipped to modern browsers when differential serving could send modern code to modern browsers.
This test measures your page's total JavaScript execution time. The fix guide below walks through bundle auditing, code splitting, deferring third-party tags, and the patterns that keep INP under the 200 millisecond Core Web Vitals threshold.
Pass rate:
-
Top 100 websites: 53%This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
-
All websites: 88%This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.
| 2021 | 79% |
|---|---|
| 2022 | 78% |
| 2023 | 71% |
| 2024 | 53% |
100
75
50
25
0
How do I fix it?
This test fails when the browser spends excessive time parsing, compiling, and executing JavaScript while the page loads. Heavy JavaScript work blocks the main thread and is the primary cause of poor Interaction to Next Paint (INP), the Core Web Vital that replaced First Input Delay in 2024 and that Google uses as part of its ranking algorithms. Fixing this issue means shipping less JavaScript, splitting what remains, and deferring everything that is not needed for the initial interaction.
Where to make the change
- Application code: audit your bundle with a tool such as Bundle Analyzer or Source Map Explorer. Identify the largest dependencies and either remove, replace, or lazy-load them.
- Build configuration: enable code splitting so each route loads only its own chunk. Tree-shake unused exports from libraries.
- Third-party scripts: the biggest INP wins often come from removing or deferring analytics, advertising, and tag-management scripts.
Common causes and how to resolve them
- Single large bundle: split the bundle by route or feature so the user only downloads and executes the code for the current page.
- Heavy third-party tags: load analytics, ads, and chat widgets after main content with
asyncordefer, or move them into Google Tag Manager so they can be controlled centrally. - Unused JavaScript: audit with the Coverage tab in DevTools to find code that loads but never runs on the page. Remove or split it out.
- Long tasks blocking the main thread: break work into smaller chunks with
setTimeout,requestIdleCallback, orscheduler.yield(). Move heavy computation to a Web Worker. - Polyfills shipped to modern browsers: use modern-only bundles for ES2017+ and serve legacy polyfills only when needed via differential serving.
Best practices
- Target sub-200 millisecond INP at the 75th percentile: this is the official "good" threshold for the Core Web Vital.
- Ship less code: the cheapest JavaScript to execute is the JavaScript you never sent. Audit dependencies for lighter alternatives.
- Defer non-critical scripts: use
deferfor scripts that need the DOM,asyncfor fully independent ones. - Move CPU-intensive work off the main thread: Web Workers can handle large data transformations without freezing the UI.
