Start here
Before You Fix It: What This Check Means
Minification reduces text payload overhead by removing non-executable formatting bloat. In plain terms, this tells you whether users are likely to feel this page as fast, stable, and usable. Scavo combines three signal types.
Why this matters in practice: degraded speed here often compounds into lower conversion and weaker user trust.
How to use this result: treat this as directional evidence, not final truth. Synthetic sampling may not fully match real-user device/network variability. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Ensure production mode enables minification for CSS/JS. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Your CSS and JS files contain development whitespace and comments, making them 20-30% larger than they need to be.
Minification strips whitespace, comments, and unnecessary characters from code without changing functionality — typically saving 20-30% on file size. Every visitor downloads your development comments and formatting. Build tools like Terser (JS) and cssnano (CSS) handle this automatically, and most CDNs offer it as a toggle.
What Scavo checks (plain English)
Scavo combines three signal types:
- Filename conventions (
.min.or min-like patterns) - Inline CSS/JS code density (whitespace/newline heuristics)
- Tiny byte-range content samples for first-party assets when filenames are inconclusive
Heuristic constants in this check:
- Up to 4 external first-party candidates
- Up to 2 sampled external content probes
- Sample size: 8192 bytes
- Minimum bytes for heuristic: 700
- Max whitespace ratio target: 0.22
- Max newlines per KB target: 8.0
How Scavo scores this check
Result behavior:
- Pass: strong minification signal detected (external and/or inline)
- Info: no strong minification signal detected
- Info: analysis unavailable if HTML/URL missing
In your scan report, this appears under What failed / What needs attention / What is working for minification, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
minification - Category:
PERFORMANCE
Why fixing this matters
Unminified JS/CSS increases transfer size and parse cost, especially on mobile connections. Minification is usually low-risk and foundational in production build pipelines.
Because this check is conservative, it’s best used as a "signal to verify" rather than absolute truth in every edge case.
Common reasons this check returns info
- Bundles are minified but filenames do not include
.minand sample probing is limited. - Assets are compressed but not minified.
- Build pipeline outputs readable code in production mode.
- First-party asset sampling cannot retrieve enough content.
If you are not technical
- Ask if production builds run minification in CI/CD.
- Request one before/after bundle-size comparison.
- Prioritize biggest JS/CSS bundles first.
- Re-scan and look for stronger minification signal.
Technical handoff message
Copy and share this with your developer.
Scavo returned CSS/JS Minification info (minification). Please confirm production minification is enabled for first-party CSS/JS, validate output bundle characteristics, and provide build-level evidence.If you are technical
- Ensure production mode enables minification for CSS/JS.
- Keep source maps separate from shipped minified assets.
- Verify critical bundles are minified after tree-shaking/code-splitting.
- Preserve debuggability via sourcemaps, not unminified prod code.
- Add bundle-size budget checks to CI.
How to verify
- Inspect built asset sizes and formatting in production artifacts.
- Compare pre/post minification bundle stats.
- Confirm deployment serves minified bundles, not dev builds.
- Re-run Scavo and track minification signal trend.
What this scan cannot confirm
- It does not parse every full asset body deeply.
- It may miss minification when naming/probe signals are inconclusive.
- It does not measure runtime execution cost directly.
Owner checklist
- [ ] Assign owner for frontend production build config.
- [ ] Add CI guard to prevent non-minified production artifacts.
- [ ] Track JS/CSS bundle sizes per release.
- [ ] Recheck after framework/tooling upgrades.
FAQ
Why does this return info instead of fail?
This check is intentionally conservative and signal-based. Lack of strong signal is not always proof of failure.
Is compression enough without minification?
Compression helps transport size, but minification also reduces raw bytes and parse overhead before compression effects.
Should .min filenames be required?
Not required, but they provide clear signal and operational clarity.
What should we fix first?
Start with largest first-party JS/CSS bundles that block rendering.
Sources
- MDN: Minification glossary
- web.dev: JavaScript payload reduction
- Google Lighthouse performance docs
- esbuild minification docs
Need a production-build audit checklist for your bundler/toolchain? Send support your current build config.
