Minify HTML, CSS & JS for Page Speed
The same minifier as our developer tool, framed around what it actually saves on the wire.
width and
height on images to stop layout shift, and serving fewer render-blocking resources.What the minify HTML, CSS & JS for Page Speed does
This is the same conservative minifier as the one in our developer tools, presented with the question a page-speed audit actually asks: how many bytes does this save on the wire, and is that worth anything?
The honest answer is usually “a little”. Minification removes comments, indentation and unnecessary whitespace, typically cutting 25–40% from a stylesheet. But almost every server also applies gzip or Brotli compression, and compression is extremely good at exactly the repetition that minification removes. The extra saving of minifying on top of compressing is often only a few percent, which is why this tool shows both the raw and the estimated post-gzip figures side by side rather than quoting the flattering number alone.
Where minification still earns its place is parse time rather than transfer. A browser has to tokenise every byte it receives after decompression, and on a low-powered phone that work is measurable. Smaller files also mean fewer bytes held in memory and a slightly faster first paint when CSS is render-blocking.
If your goal is a better Core Web Vitals score, minification is not where the wins are. Largest Contentful Paint is usually dominated by an unoptimised hero image or a render-blocking font. Cumulative Layout Shift is usually images without width and height attributes, or ads and embeds injected after paint. Interaction to Next Paint is usually third-party JavaScript. Minify by all means — it is free and safe — but fix those first.
How to use it
- Choose the file type and paste your source.
- Read both the raw saving and the estimated post-gzip saving; the second is the one that reaches the user.
- Test the minified output in your project before deploying it.
- If the saving is negligible, look at images, fonts and third-party scripts instead.
A worked example
A commented 178-byte CSS component:
| Measure | Before | After |
|---|---|---|
| Raw size | 178 B | 68 B |
| Estimated after gzip | ~131 B | ~59 B |
| Transfer time on 4G | difference under 1 ms | |
The raw saving looks impressive at 62%. After compression it is 72 bytes, and on any real connection the difference is unmeasurable. Scale that up to a 240 KB stylesheet and the post-gzip saving becomes perhaps 8–12 KB — genuinely worth having, and still smaller than a single unoptimised photograph on the same page.
Frequently asked questions
Is minification worth it if my server already gzips?
Yes, but the gain is smaller than the raw percentage suggests. Compression already removes most of the repetition minification targets. The remaining benefit is real but modest: fewer bytes to decompress and parse, which matters most on low-powered phones.
Will minifying improve my Lighthouse score?
Marginally at best. Lighthouse flags unminified resources, so the audit item will pass, but the score is dominated by image weight, render-blocking resources and third-party JavaScript. Fix those for a real change.
Is this the same tool as the developer minifier?
Yes, the same conservative engine, framed around transfer size and load time rather than code hygiene. Use whichever page fits the job you are doing; the output is identical.
What actually helps Core Web Vitals most?
Compressing and correctly sizing images, preloading the LCP image, setting explicit width and height on images and embeds to stop layout shift, self-hosting or preloading fonts, and deferring or removing third-party scripts. Those four things account for most real-world failures.