Unminified JavaScript: how to minify for faster LCP
Unminified JS carries whitespace and comments that bloat transfer and parse time. Find unminified JavaScript files and learn how to minify production JS.
What it means
One or more same-host JavaScript files loaded by this page appear unminified — the fetched body carries a high ratio of whitespace, newlines and comments relative to code. Minification removes those non-functional characters, cutting typical application JS by 30–60% and reducing both transfer and parse time.
Why it matters
JavaScript is a major contributor to LCP delay and Total Blocking Time, both inputs to the Core Web Vitals Google uses as page-experience signals. Unminified files are slower to transfer (whitespace compresses less efficiently even under gzip/Brotli), slower to parse (the engine tokenises every character including whitespace), and carry long identifiers that inflate memory. This is a lab-proxy: Crawlinx reads the whitespace ratio of a bounded sample of the file — a reliable proxy for minification status — not the real browser parse time.
How to fix it
- Minify as part of the build, not by hand. Vite and Webpack
mode: 'production'minify JS automatically; esbuild:esbuild app.js --bundle --minify --outfile=app.min.js. - For raw JS added directly to a CMS with no build step, run it through an online minifier (Terser/UglifyJS) or add a build step before upload.
- Verify by inspecting the served file — production JS should be dense and near-single-line with short variable names.
Example
// app.js shipped straight from source
function addToCart(id) {
// look up the product
const product = catalog.find(p => p.id === id);
cart.push(product);
}function addToCart(t){const e=catalog.find(n=>n.id===t);cart.push(e)}Minify production JS with esbuild, Terser or Vite. Minification removes comments and whitespace and shortens local names; combine it with gzip/Brotli at the server.
When it's not a problem
Source maps, development environments and deliberately human-readable utility scripts don't need minification; this check targets production JS served to users and Googlebot. Very small files (Crawlinx applies a minimum-size floor, ~2 KB) are skipped because the gain is negligible. If a development artifact is accidentally served in production, the right fix may be to stop serving it rather than minify it. Only runs when asset inspection is enabled.
How Crawlinx detects it
For same-host .js assets that were fetched and sniffed, we measure the whitespace/newline ratio. A high ratio indicates source-formatted (unminified) JavaScript rather than a built bundle.
How common is it?
Not yet observed in our audit sample. We publish this explainer because the check runs on every crawl; once an audited site trips it, this page will break the issue down by platform, gatekeeper, vertical and country.
FAQ
- Does minifying JS improve SEO?
- It reduces transfer and parse/compile time, which improves LCP and INP — both ranking-relevant. It won't change your content, but faster pages compete better.
- What's the difference between minifying and compressing?
- Minifying rewrites the source smaller (shorter names, no whitespace). Compression (gzip/Brotli) shrinks the transfer at the HTTP layer. Do both — they compound.
- My bundle is minified but still flagged — why?
- Check whether a specific vendor or legacy file is served unformatted. The check is per-asset, so one unminified script among several minified ones still trips it.
Audit your own site — free
157 checks, internal PageRank, render-diff. No signup, results in ~30s.