JavaScript Minification Test
The JavaScript Minification Test inspects every JS file referenced by a URL and reports whether each is minified for production.
- Results in seconds
- Pass / fail + fix guidance
- No account required
The JavaScript Minification Test inspects every JS file referenced by a URL and reports whether each is minified for production. Un-minified JS contains comments, whitespace, full variable names and dead code that bloat the file by 30-60%. Minification (via terser, esbuild or swc) is a default in every modern build tool — un-minified JS in production usually means the build pipeline is misconfigured or skipped entirely.
What This Tool Checks
- Minification status of every external JS file
- Minification status of inline <script> blocks
- Bytes saved per file by minifying
- Comments and whitespace overhead
- Source maps exposed in production
- Tree-shaking opportunities
Why It Matters for SEO
JavaScript is the most expensive resource the browser handles — every byte must be downloaded, parsed, compiled and executed. Un-minified JS can be 30-60% larger than necessary, directly slowing TTI and INP. Minification is free, universal and compatible with every build tool — un-minified JS in production is an immediate, measurable performance regression.
How to Fix It
Enable JS minification in your production build (esbuild --minify, terser, swc). Strip source maps from production responses (or serve them only with .map filenames behind a header check). Minify inline <script> at build time. Apply tree-shaking to remove dead code from final bundles.
How It Works
We fetch every JS file linked from the page, measure raw byte count, then re-minify with terser at production settings and compare. Each file is reported with the bytes saved and the build-pipeline change needed.
Common Mistakes to Avoid
- Source JS deployed to production (no build step)
- Production source maps exposed (bloat plus security concern)
- Inline <script> blocks not minified
- Multiple competing bundles instead of code splitting + minification
- Build pipeline minifies app code but not vendor chunks
Quick Checklist
- Every external JS file minified in production
- Inline <script> blocks minified
- No source maps exposed publicly in production
- Tree-shaking applied to remove dead code
- Brotli or gzip enabled on top of minification
Put your whole site on autopilot — SEO and AI search
PositionMySite monitors every signal on this page across your entire website 24/7 — plus keyword rankings, competitor moves and AI-search readiness (llms.txt, schema, ChatGPT & Gemini visibility). When something breaks, you know before Google does.
Every feature unlocked · No commitment · Cancel anytimeFrequently Asked Questions
Typically 30-60% on text-based JS assets. Combined with Brotli compression the total reduction is usually 80-90% versus raw uncompressed source.
Yes if you do not have source maps. Use source maps in development for full stack traces and disable or hide them in production.
Yes. Inline <script> blocks count toward HTML byte size on every page request. Build tools can minify them at template-compile time.
Indirectly but powerfully. Smaller JS means faster TTI and INP — and INP is a Core Web Vital ranking input. Minification is one of the cheapest performance wins available.
Yes. Minify edge functions too — they have CPU time limits, and smaller bundles cold-start faster on workers like Cloudflare Workers and Vercel Edge.