Minifying HTML sounds like an easy performance win: whitespace is bytes, and bytes take time to transfer. The useful question is how much it saves after compression, because that is what a browser usually downloads.
So I measured it. This site, thirteen built pages, an Astro production build, and
a post-build minifier run over dist. Everything below is a real measurement you
can reproduce with wc -c and gzip -9.
The setup
The tool is astro-crunch, a small
post-build integration I wrote: it walks the emitted HTML files after
astro:build:done and rewrites each one only if the result is actually smaller.
It has three settings that matter here — HTML minification, which is on by
default, and minification of inline <script> and <style> blocks, which are
both off by default.
I built the site once, kept the output, and ran the minifier over copies. Sizes are measured raw, gzipped at level 9, and Brotli at quality 11, because raw bytes are not what a browser downloads. Most sites serve compressed HTML, and compression removes much of the repetition that whitespace minification targets. The exact result depends on the server and its configuration.
The result
Totals across all 13 HTML pages:
| Raw | gzip -9 | brotli -q 11 | |
|---|---|---|---|
| Astro build, untouched | 298,979 | 89,296 | 72,331 |
| Minified, default settings | 296,493 (−0.8%) | 88,412 (−1.0%) | 71,570 (−1.1%) |
| Minified, inline JS + CSS too | 272,691 (−8.8%) | 82,679 (−7.4%) | 66,786 (−7.7%) |
The default configuration saves 884 bytes of gzip across the entire site. Not per page — across all thirteen pages. On the homepage it is 78 bytes. On one page, the Dutch homepage, the Brotli-compressed output came out 16 bytes larger after minification than before, because removing whitespace can remove the repetition the compressor was exploiting.
The practical result is simple: collapsing HTML whitespace on this already lean Astro build saves about one percent of the compressed HTML. That is a small saving, and it is unlikely to be the first performance problem to fix.
Where the win actually is
Turning on inline JS and CSS minification changes the picture by an order of magnitude — 6.6 KB of gzip, 7.4%, and the per-page split shows why:
| Page | gzip before | default | + inline JS/CSS |
|---|---|---|---|
/ | 15,227 | 15,149 | 14,690 |
/nl/ | 15,652 | 15,578 | 15,093 |
/privacy/ | 5,442 | 5,322 | 4,909 |
/writing/how-to-fix-slow-lcp/ | 6,952 | 6,859 | 6,434 |
/404.html | 3,581 | 3,558 | 3,117 |
Note /privacy/ and /404.html — the smallest pages get the largest percentage
improvement, because a fixed amount of inline script and style is a much bigger
share of a short document. The markup was never the problem. The code embedded in
the markup was.
This is also why the defaults are conservative. Collapsing whitespace between tags is close to risk-free. Rewriting the inline JavaScript in your document is a real code transform on code that has already been through your bundler, and it should be a decision you make, not one a build tool makes for you. Worth checking after you enable it: this site’s pages came out with identical script counts, identical link counts and byte-identical extracted text before and after, which is the cheap sanity check to run before trusting any minifier.
What this means for your build
- Put the result in context. A one-percent saving on this site’s HTML is not enough to explain a slow page. Images, fonts, third-party scripts and render-blocking resources may deserve attention first, so measure those before spending time on markup minification.
- Measure after compression. “Saved 8.8%” and “saved 7.4%” are the same run; the compressed figure is closer to the transfer a browser makes. Raw bytes are still useful for understanding the build, but they are not the whole result.
- Consider the maintenance cost. A small saving may be reasonable when the minifier is already part of the build. If it adds configuration or transforms inline code, check whether the transfer saving justifies that complexity. Do not expect this change alone to show up in Core Web Vitals.
- Check the inline code, not the markup. If your generated pages carry inline scripts or styles — theme-init snippets, structured data, critical CSS — that is where the bytes are hiding, and it is the setting most build tools leave off.
This result is specific to this tool and this site, but it shows why the measurement matters. Modern static site generators often emit compact HTML, and gzip already removes much of the remaining repetition. Inline scripts and styles were the larger opportunity in this build.
If you want to reproduce this on your own site, the measurement is four commands:
build, copy dist, minify the copy, and compare
gzip -9 -c file | wc -c on both. It takes ten minutes and it will tell you more
than any blog post — including this one — about your own build.
Update, 31 August 2026: this site no longer runs the minifier in its own build. The numbers above are unchanged — they were a one-off measurement, not a claim about this site’s current deploy — but I took my own advice and stopped spending build complexity on one percent.