Minification

Minification is the removal of characters a browser does not need from HTML, CSS and JavaScript: indentation, line breaks, comments, and in scripts the long names of local variables. The file means the same thing to the browser and is smaller on the wire. It is normally done once, by a build tool, on the files a site deploys. Lighthouse reports the CSS and JavaScript files where it would still save bytes as unminified-css and unminified-javascript.

Common in reports, small after compression

The hint is frequent. In the October 2026 snapshot of our audit base, Lighthouse found unminified CSS on 517 of 1,937 sites (27%) and unminified JavaScript on 487 (25%); 755 sites, 39%, had at least one of the two. The August count on 440 sites, 21% and 27%, is in What Lighthouse tells you to fix. The median estimated saving was 5.5 KB of CSS and 10.7 KB of JavaScript, and Lighthouse’s own estimate of the effect on LCP had a median of 0 ms for both.

The reason is that minification and gzip remove much of the same redundancy. We ran our HTML and inline-style minifiers offline over the stored original markup of 2,064 audited sites. Before compression they cut a median of 8.3 KB per page. After gzip the difference was 1.3 KB, 3.6% of the compressed document, and under 1 KB on 809 of the 2,064 pages. The raw figure overstates the gain several times over.

Hosted builders mostly settle it for the owner. Unminified CSS turned up on 9 of 293 Squarespace sites, 7 of 173 Tilda sites and 3 of 53 Wix sites, against 146 of 407 Elementor sites and 87 of 222 WooCommerce stores, where the build belongs to the site.

How a minifier breaks a page

A minifier decides which characters are insignificant, and some that look insignificant are not. Every case below was a defect in our own minifiers, found on sites in our audit base between July and October 2026:

• Whitespace inside <pre>. Removing spaces between tags joined syntax-highlighted code into <divclass=...> on pages that show code samples. 10 of 349 stored pages had significant whitespace inside <pre>. The score went up, because the document got smaller.
• Comments that a framework reads. Vue and Nuxt mark server-rendered fragments with comments such as <!--[-->. Without them, hydration did not match the markup and the page was rebuilt on load: layout shift of 1.0, and on one site a mobile score of 23 through our proxy against 56 for the original.
• A space that is part of the syntax. In CSS, calc(-50vh + var(--x)) is invalid without the spaces around +, and the browser drops the whole rule. A space before : in a selector is a descendant combinator, so :root :where(...) and :root:where(...) select different elements. The visible result was a smaller heading on the first screen.
• A // inside a string. Our script minifier read the start of "//assets..." as a comment and cut the line, leaving a syntax error that stopped every module of our injected runtime. It affected 35 of 337 audits at the time.

The first and the last of these raised the score while breaking the page, which is why a higher number after minifying is not evidence that it worked.

Where minifying belongs

Minify in the build that produces the files, not on the fly, and test the output in a browser. A build tool knows which files are templates, which are code samples and which framework is in use, and it runs once per deploy rather than on every request. If the server already sends gzip or Brotli, the remaining saving is usually a kilobyte or two per file.

What our proxy minifies

Our proxy minifies the HTML document and the <style> blocks inside it, and leaves <pre>, <textarea> and inline scripts untouched, as well as every comment on a page that uses Vue’s hydration markers. It does not minify a site’s external CSS or JavaScript files, which are served by the site rather than through us. On the pages we measured the saving is a kilobyte or so; most of what changes the score is when and in what order the browser is told about each resource.