The number that actually affects load time is not the file size on disk, it is the compressed size that travels over the network. Servers gzip or brotli your text assets before sending them, so the gzip size of a file is what your users really download. Here is how to estimate it and read the result correctly.
Why compressed size is the number that matters
When a browser requests an HTML, CSS, JS, JSON, or SVG file, the server compresses it on the fly and sends the smaller version. The browser decompresses it before use. So a 120 KB stylesheet might leave the server at 22 KB. That 22 KB is what costs the user bandwidth and time, which is why the compressed size, not the raw size, is the figure to optimize.
You can estimate it without deploying anything using the Gzip / Deflate Size Calculator, which compresses your input locally in the browser and reports the result.
What compresses well and what does not
Compression works by finding repetition, so the answer depends entirely on the content:
- Text assets compress a lot. HTML, CSS, JS, JSON, and SVG are full of repeated tags, keywords, and whitespace. They commonly shrink 60 to 80 percent.
- Already-compressed binaries barely move. JPG, PNG, WebP, AVIF, MP4, and most web fonts are already compressed internally. Running gzip over them saves almost nothing and can even add a few bytes, so servers usually skip compressing them.
The practical takeaway: focus your compression effort on text, and do not expect gzip to rescue a heavy image. For images, resize and re-encode instead.
Minify first, then compress
Minifying and compressing solve different problems, and you want both. Minifying removes comments, whitespace, and dead code from the source. Compression then encodes whatever is left. The real payload is the minified, compressed size, so always measure in that order. Estimating gzip on an unminified file overstates the savings minification would give you, and estimating on minified-but-uncompressed output overstates what ships.
A reliable workflow:
- Minify your CSS or JS.
- Paste the minified output into the Gzip / Deflate Size Calculator.
- Read the gzip size, the brotli size, and the percentage saved.
- Compare against the raw size to confirm the asset is worth optimizing further.
Gzip vs brotli
Most modern browsers and CDNs support both. Brotli is newer and usually produces a smaller result than gzip on text, often a few percent to over 10 percent tighter at comparable settings, which is why it has become the default for static text assets. Gzip remains the safe, universal fallback. If your host offers brotli, enable it. Either way, estimate both so you know the real range your users will see, and remember the tool runs entirely in your browser, so nothing you paste is uploaded.
Related tools
- HTML Minifier - strip whitespace and comments before you measure compressed size.
- CSS Minifier - shrink stylesheets so gzip has less to work with.
- Page Size & Request Analyzer - see the full transferred weight of a real page.
Minify it, compress it, measure the over-the-wire number, and ship the smallest payload your users will actually download.