Minify CSS and JavaScript
Strip comments, whitespace, and dead code from CSS and JS to reduce transfer and parse time.
Metrics
This technique can move up to 33% of LCP's share of the Lighthouse score.
This technique can move up to 33% of TBT's share of the Lighthouse score.
This technique does not move CLS.
This technique can move up to 67% of FCP's share of the Lighthouse score.
This technique can move up to 33% of SI's share of the Lighthouse score.
This technique does not move TTFB.
Overview
Minification removes everything from source code that the browser does not need to execute it: comments, indentation, newlines, redundant semicolons, and in JavaScript, local variable name shortening. A well-written 80 KB stylesheet commonly minifies to 55–65 KB. Combined with text compression, the same file reaches 12–18 KB over the wire — 85% smaller than the original source. Every render-blocking stylesheet and parser-blocking script benefits.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: CLS, TTFB.
The Problem
Unminified source files are authored for human readability, not browser efficiency. A WordPress theme stylesheet with 3 000 lines of comments and formatted whitespace adds 20–40 KB of bytes the browser downloads and discards before parsing begins. For render-blocking CSS, those extra bytes directly extend the time before first paint. For JavaScript, extra bytes increase parse and compile time on every page load.
Performance Impact
LCP
smaller CSS downloads and parses faster, reducing the delay before the LCP element is styled and painted
TBT
30–150ms
smaller JS files parse and compile faster on the main thread
FCP
50–300ms
render-blocking CSS reaches the parser faster
SI
50–200ms
all visible content unblocked sooner by faster CSS delivery
Risk: Low
output is functionally identical to source — always test the minified build
How it works
01
Minify CSS
CSS minifiers (cssnano, CleanCSS, PostCSS) remove comments, whitespace, and redundant rules, and optionally merge shorthand properties. Minification is lossless — the rendered output is byte-for-byte identical to the unminified version.
02
Minify JavaScript
JS minifiers (Terser, esbuild, SWC) remove comments and whitespace, then rename local variables to single characters. Advanced minifiers also inline single-use functions, fold constants, and eliminate unreachable code paths.
03
Run minification at build time
Minify once at deployment — not on every request. Build tools (Vite, webpack, Parcel, Gulp) minify automatically in production mode. The minified files are committed or uploaded; the server serves them directly.
04
Use WordPress plugins for zero-build-pipeline setups
W3 Total Cache, LiteSpeed Cache, WP Rocket, and Autoptimize all minify CSS and JavaScript at the application layer and cache the minified output. No build pipeline or server access required.
Limitations
- Aggressive JS minification (dead code elimination, inlining) can break code that relies on function names or property reflection at runtime.
- WordPress plugins that minify on-the-fly add CPU overhead on cache misses — combine with a full-page cache so minification runs once per URL.
- Minification does not remove unused code — combine with PurgeCSS and tree-shaking to remove rules and functions entirely, not just whitespace.
Common Mistakes
Minifying without source maps in production
Minified stack traces are unreadable. Generate source maps alongside the minified files and upload them to your error monitoring service (Sentry, Bugsnag). Source maps are not served to end users unless DevTools explicitly fetches them.
Minifying the same file twice with two different plugins
Running W3 Total Cache minification on top of already-minified Webpack output can corrupt the file. Check whether your bundler already outputs minified files before enabling plugin-level minification.
Need help applying this to your site?
Targeted fixes, not guesswork. We identify which techniques move the needle for your specific WordPress stack.
Start an Engagement