At a glance
Total JavaScript execution time on the main thread, in milliseconds, not bytes downloaded but wall-clock CPU time spent parsing, compiling, and evaluating JS. High execution time is the single biggest cause of bad INP scores on mobile: when the main thread is busy, every tap, scroll, and click waits for JS to yield. Cutting JS execution time is one of the highest-leverage performance fixes for ecommerce because it directly improves interactivity, which directly affects bounce rate and conversion. A page can have moderate weight but high execution time if the JS is parse-heavy or runs expensive synchronous work on load.
| What it counts | Cumulative milliseconds of main-thread work attributed to JavaScript execution during the audit (parse + compile + evaluate + execute), as measured by Lighthouse’s bootup-time audit. Excludes idle time and non-JS main-thread work. |
| Sample type | Lab data from per-page Lighthouse audit; emulated 4× CPU throttle + slow 4G network. |
| Why JS execution time matters | Mobile devices run typical site JS 4-6× slower than the desktop machines on which the JS was written. A 400ms JS execution on the developer’s MacBook is 1.6-2.4 seconds on a typical mobile shopper’s phone. This time is the dominant contributor to TBT (Total Blocking Time) and INP (Interaction to Next Paint), the two CWV metrics where ecommerce stores most often fail. |
| Reading the value | (1) Compare against thresholds: under 1,000ms is healthy, 1,000-2,500ms needs attention, above 2,500ms is critical. (2) Decompose by script source via the Lighthouse audit row, first-party theme JS, jQuery, vendor bundles, third-party widgets each show their contribution. (3) Cross-reference psi_unused_js to see which bytes are dead weight that could be removed entirely. (4) Cross-reference psi_third_party_cost to see how much execution belongs to third parties. |
| Currency | milliseconds. |
| Time window | T/7D (per-audit). |
| Alert trigger | js_execution > 2500ms (severe main-thread blockage; INP and TBT will fail). |
| Sentiment key | lower-is-better. |
| Roles | owner, operations |
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store, mobile homepage audit, Wednesday 15 May 26.| Script source | JS bytes (KB) | Parse + compile (ms) | Evaluate + execute (ms) | Total exec (ms) | Share of total |
|---|---|---|---|---|---|
| Theme bundle (first-party) | 480 | 280 | 540 | 820 | 28% |
| jQuery 3.x | 88 | 40 | 60 | 100 | 3% |
| GTM container | 18 | 20 | 60 | 80 | 3% |
| Yotpo reviews widget | 220 | 180 | 380 | 560 | 19% |
| Klaviyo onsite SDK | 110 | 90 | 220 | 310 | 11% |
| Hotjar heatmap | 60 | 40 | 140 | 180 | 6% |
| Meta pixel + helpers | 40 | 30 | 110 | 140 | 5% |
| Recombee recommendations | 70 | 50 | 130 | 180 | 6% |
| Shopify Checkout SDK polyfills | 90 | 80 | 200 | 280 | 10% |
| Other (theme widgets, A/B test) | 75 | 60 | 200 | 260 | 9% |
| Total | 1,251 | 870 | 2,040 | 2,910 | 100% |
- Total JS execution at 2,910ms is in the critical zone. Above 2,500ms threshold; INP and TBT will fail by definition. The main thread is blocked for the better part of three seconds during page load, which is why every interaction during that window feels sluggish.
- Theme bundle is the single largest contributor (820ms, 28%). This is first-party code, fully within the merchant’s control to fix. Likely causes: jQuery dependency (88KB on its own), unminified or unsplit bundle, expensive synchronous initialisation, hero carousel and modal frameworks loaded eagerly. Code-splitting + tree-shaking + jQuery removal could realistically cut this to 250-350ms.
- Yotpo reviews widget at 560ms (19%) is a major third-party tax. Reviews are a critical conversion driver but reviews don’t need to render for first paint. Defer Yotpo until user scrolls below the fold or until idle. Cuts 400+ms off the critical path while preserving the feature.
- Klaviyo onsite SDK at 310ms (11%). Powers popup/embed forms, live shopping widgets, abandonment tracking. Defer initialisation, Klaviyo’s modern SDK supports lazy initialisation. Saves 200ms on critical path.
- Shopify Checkout SDK polyfills at 280ms (10%). Loaded site-wide for a homepage that doesn’t show checkout, wasted on every non-checkout pageview. Conditionally load on checkout-adjacent pages only. Saves 280ms on homepage and other non-checkout templates.
- Hotjar, Meta pixel, Recombee combine for ~500ms. Tracking and recommendations infrastructure. Server-side tagging (Meta CAPI, server-side recommendation injection) shifts this off the browser entirely. Saves 400ms on critical path.
-
Recommended ship sequence:
- Week 1: Defer Yotpo + Klaviyo until idle/scroll. Saves ~600ms.
- Week 2: Conditional load Checkout SDK polyfills. Saves ~280ms.
- Week 3: jQuery removal + theme bundle code-split. Saves ~500ms.
- Week 4: Server-side tagging migration for Meta/Hotjar. Saves ~400ms.
- Result after 4 weeks: 2,910ms → 1,100-1,300ms. INP and TBT move from failing to passing. Mobile interactivity feels noticeably faster.
- Why this card matters for INP specifically. INP measures the time between a user interaction (tap, click) and the next visual frame. Long JS execution starves the main thread, so even a brief tap during page load waits hundreds of milliseconds for JS to yield. Cutting JS execution time directly improves INP and field CWV pass rate.
- Read total JS execution time. Anything above 1,500ms warrants action.
- Decompose by script source. Identify the top 3 contributors.
- Apply pattern-based remediation: defer (third parties), conditional load (per-route polyfills), code-split (first-party bundle), server-side (tracking).
- Re-audit to confirm execution drops below 1,500ms.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify top 3 script-source contributors. |
| First week | Defer non-critical third parties. |
| Day 14 | Code-split first-party bundle. |
| Re-audit | Confirm execution under 1,500ms. INP/TBT pass. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_unused_js | JS bytes shipped but never executed; remove to cut both bytes and execution time. |
psi_lab_tbt | Total Blocking Time; direct downstream of JS execution time. |
crux_inp_p75 | Field INP; high JS execution causes high INP. |
psi_third_party_cost | Third-party tax; identifies which third parties are most expensive. |
psi_render_blocking | Render-blocking resources; subset of JS execution. |
psi_total_weight | Total page weight; complements but distinct from execution. |
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights → “Reduce JavaScript execution time” diagnostic, lists each script with its execution time on a 4× CPU-throttled emulated mobile device.
- Chrome DevTools → Performance panel, record a page load, look at the “Bottom-Up” tab grouped by script source for actual main-thread time.
- Lighthouse audit JSON →
bootup-timeaudit, array of script URLs withtotal,scripting, andscriptParseCompilefields.
| Reason | Direction | What to do |
|---|---|---|
| Device CPU. Lighthouse uses a 4× throttle to emulate slow mobile. A manual run on a fast desktop (no throttle) shows much lower numbers. | Vortex IQ higher | Apply CPU throttling in DevTools when reconciling. |
| Network throttle. Lighthouse uses Slow 4G; this affects script download timing which can shift execution timing. | Variable | Match throttle profile when reconciling. |
| Run-to-run variance. Lighthouse JS execution ±15% is normal due to V8 optimisation phases. | Either direction | Use 7-day rolling. |
| Browser version. V8 changes between Chrome releases can shift JS execution by ±10-15%. | Either direction | Note the Chrome version used. |
psi_unused_js, psi_lab_tbt, psi_third_party_cost).
Quick rule for support tickets: when a merchant disputes the JS execution number, run their PageSpeed Insights URL and compare directly. The Vortex IQ value should match the PSI “Reduce JavaScript execution time” diagnostic within ±15% on the same audit cycle.
Known limitations / merchant FAQs
Q: Our JS execution time is 2,800ms in Lighthouse but our real users say the site feels fine. Should we worry? Probably yes, but check field data first. Lighthouse simulates a slow mid-tier mobile device. If your audience is mostly desktop or premium iPhone, your real users may not feel the pain. Look atcrux_inp_p75 field data, if INP is below 200ms in field, you’re fine; if INP is above 200ms, real users are feeling the JS execution cost.
Q: We deferred all third parties and execution time only dropped 600ms. Why not more?
Because much of the JS execution is first-party theme code that runs on every page regardless of third parties. Inspect the per-script breakdown, if theme bundle is 800ms+, that’s the next target. Code-splitting the theme bundle and removing jQuery typically cuts another 300-500ms.
Q: Removing jQuery sounds risky. Is it worth it?
Almost always yes for ecommerce. jQuery adds 88KB and 80-150ms execution time on mobile. Modern themes (Catalyst, Stencil 2.0) ship without jQuery. Most jQuery uses (DOM selection, AJAX, animations) have native equivalents (querySelector, fetch, CSS animations). The migration takes 1-2 sprints of focused work but pays back permanently in execution time.
Q: GTM container shows only 80ms execution time. Why is server-side tagging worth the investment if GTM is so cheap?
Because the GTM container itself is cheap, but the tags it loads aren’t. A typical GTM container fires 30+ tags, each running its own JS, Meta pixel, Google Ads pixel, Hotjar, conversion tracking, abandonment tracking. The 80ms is just the dispatcher; the dispatched tags often add 600-1,000ms of cumulative execution. Server-side GTM moves the tag execution off the browser entirely.
Q: Our Yotpo widget execution is 560ms. Yotpo is essential for conversion. What can we do?
Defer initialisation. Yotpo (and most review widgets) support lazy-loading, they don’t need to render until the user scrolls to the reviews section. Setting data-deferred="true" or wrapping in an IntersectionObserver pattern keeps the feature but moves the execution off the critical path. This is a configuration change, not a feature removal.
Q: We code-split our bundle but execution time barely moved. Why?
Code-splitting reduces the bytes downloaded on initial page load, but if the split chunks still fire synchronously on load (rather than on-demand), execution time stays the same. The fix is dynamic import() triggered by user action or visibility, not just splitting the file. Verify in DevTools that the split chunks are actually loading lazily.
Q: How does this card differ from psi_total_weight and psi_unused_js?
psi_total_weight measures bytes downloaded. psi_unused_js measures bytes downloaded but unused. This card measures CPU time spent executing the bytes. All three are needed: bytes affect download time, unused bytes are pure waste, and execution time affects interactivity. A page can be light on bytes but heavy on execution if the JS is parse-intensive (e.g., minified but not tree-shaken).
Q: We reduced JS execution by 1,000ms and our Lighthouse score barely moved. Why?
Lighthouse Performance Score weights LCP (25%), TBT (30%), CLS (25%), FCP (10%), Speed Index (10%). JS execution improvements feed into TBT primarily. If your TBT was already passing, further reductions show diminishing score returns even though field INP improvement may be substantial. Track field INP (crux_inp_p75) for the real-world payoff.