JavaScript size checker. Per-bundle breakdown.
Enter a URL. We pull PSI's script audits and list every JS file with byte size, first-party vs third-party split, and estimated parse + execute time on a mid-tier mobile.
Enter a URL. We pull Google PSI's network-requests audit (script subset), split first-party vs third-party JS, and estimate parse + execute time on a mid-tier mobile.
Sources used
- Google PSI v5 API — network-requests + script-treemap-data audit sources
- web.dev Cost of JavaScript — parse + execute time research
- web.dev INP guide — JS execution → INP impact
- web.dev tree-shaking guide
URL is sent only to Google PSI. Digital Heroes does not log queries.
Privacy: URL is sent only to Google PSI.
JS costs more than its weight.
JavaScript blocks the main thread during parse + execute — not just transfer. 350KB of JS takes 1.5-3 seconds to parse + execute on a mid-tier mobile per web.dev's Cost of JavaScript research. That parse-execute time hits TBT and INP directly. Cutting JS by 30% typically lifts Lighthouse Performance 8-15 points and INP by 50-100ms. The checker above splits first-party vs third-party so you know where the cleanup is yours to do vs which third-party tags need vendor conversations.
Five JS reduction patterns ranked by impact. Code-split routes via dynamic import (only ship JS for current view). Tree-shake unused exports (automatic with ES modules + modern bundlers). Replace heavy libraries (moment.js → date-fns saves ~70KB, lodash → individual lodash-es imports saves ~50KB). Lazy-load on interaction (chat widgets, video players). Audit + remove dormant analytics + tag-manager fragments quarterly. Most production SPAs see 30-50% JS reduction in a focused 2-week sprint.
Tools in the same cluster: Page Weight Analyzer for the full byte breakdown. Render Blocking Checker for the critical-path JS view. Core Web Vitals Checker for the INP impact view.
Five answers.
Why is JavaScript size so important?
JavaScript blocks the main thread during parse + execute, not just transfer. 350KB of JS takes 1.5-3 seconds to parse + execute on a mid-tier mobile (the device profile PSI throttles to). That parse-execute time directly hits TBT (Total Blocking Time, the lab proxy for INP) and degrades INP (one of three Core Web Vitals). Cutting JS by 30% typically lifts Lighthouse Performance score by 8-15 points and INP by 50-100ms.
First-party vs third-party JS — how to split?
First-party JS (your own bundles, your CDN) is yours to optimize. Third-party JS (analytics, ads, chat widgets, A/B testing, tag managers, CRM pixels) typically adds 200KB-1MB of un-budgeted weight that's harder to control. The checker above splits and shows per-file size for both. Third-party scripts commonly account for 40-60% of total JS weight on production sites — auditing them quarterly is high-impact cleanup work.
What's a healthy JS budget?
Total JS under 350KB compressed is the practical mobile budget for fast-feeling sites. Above 500KB, INP starts failing on mid-tier mobiles. Above 1MB, Lighthouse Performance drops below 70 even with everything else optimized. The web.dev Cost-of-JS budget is roughly 170KB compressed for INP-friendly experience. Single-page apps (Next.js, Nuxt, Remix) commonly ship 400-700KB on first load — code-splitting + dynamic imports are the standard fix.
How do I shrink JS without losing features?
Five reduction patterns. One, code-split routes via dynamic import — only ship JS for the current view. Two, tree-shake — remove unused exports (modern bundlers do this automatically with ES modules). Three, replace heavyweight libraries (moment.js → date-fns, lodash → individual lodash-es imports, jQuery → vanilla DOM). Four, lazy-load on interaction — chat widgets, video players, heavy components only when triggered. Five, audit + remove dormant analytics + tag-manager fragments quarterly.
Does this tool save my data?
The URL is sent only to Google's public PageSpeed Insights API. Nothing is logged on Digital Heroes servers.
JS over 500KB?
Our web development engagements ship code-split routes, tree-shaking audit, library replacements, and third-party tag cleanup — typically 30-50% JS reduction in a focused 2-week sprint.
Published · Last updated .