Compression.
Compression is the shrinking of text-based resources before they are sent from the server and their expansion in the browser.
HTML, CSS and JavaScript are text files, and text compresses very well — typically down to a quarter of its size. This is the cheapest performance gain there is: it requires no code change and affects every text resource at once.
There are two common algorithms: one older with universal support, the other newer and generally compressing ten to twenty per cent better. The server picks the best algorithm the browser supports.
The measured effect on this site is clear: the main stylesheet is 67,400 bytes at source and 12,415 bytes compressed. The vendor libraries go from 148,307 bytes to 55,733. The data sent, in other words, is about a third of the source.
- Text resources — HTML, CSS, JavaScript, SVG, JSON. All of them compress.
- Already compressed ones — images, video, font files. Compressing again brings no gain.
- Small files — for files under a few hundred bytes the overhead can exceed the gain.
- Static pre-compression — a file can be compressed and stored at publish time; no work is done per request.
The fourth item is ideal for static sites: compression happens once at publish time and is not repeated on every request. The highest compression level can be used and the server cost stays at zero.
And a note on checking: do not assume compression is on, measure it. On custom server configurations it is often left off, and the effect covers every text resource.
Compression and minification are different things and are used together. Minification removes unnecessary characters from the source itself — whitespace, comments, long variable names. Compression then encodes the result separately.
Their order matters: minify first, compress second. A minified file contains less repetition so the compression ratio drops slightly, but the final size still comes out smallest.
On this site the minification of the stylesheet was deliberately kept CONSERVATIVE: only comments, line indentation and blank lines were stripped; nothing inside a selector or a value was touched. Aggressive stripping would have saved only 747 more bytes and carried the risk of breaking descendant-pseudo patterns — the gain and the risk were measured and compared.