Compression: confirming it is on, and measuring what you gained

Compression shrinks pages before they travel, and the browser unpacks them at the other end. Because HTML, CSS and JavaScript are text, and text repeats itself a great deal, what travels can be a fraction of the original size. On slow connections and on mobile data, you feel it.

The good news is that here it is already on. Our web server compresses what should be compressed on its own, with nothing for you to configure. So this article is not about switching it on: it is about confirming and measuring, which is the part almost everybody skips.

How to confirm it in ten seconds

1 Open the site in a browser and open the developer tools, usually with F12.
2 Go to the network tab and reload with the option to bypass the cache.
3 Click the first row, which is the page document itself, and look in the response headers for content-encoding. If it says gzip or br, it is compressed.
4 Compare the two size columns. The network tab shows what was transferred and the real size of the file. The gap between those two numbers is exactly what compression saved you, and that is the measurement that matters.
If you prefer the command line, one request with the accept-encoding header, reading only the response headers, is enough: curl -sI -H "Accept-Encoding: gzip" https://yourdomain/ . The content-encoding line in the answer is the proof.

The cPanel screen that confuses people

There is a cPanel screen called Optimize Website, with options to compress everything or to compress certain file types. It is natural to assume that is where compression gets switched on. It is not, and it is worth knowing why: that screen adjusts a piece of software that is not the one serving your site here.

So: if you went there, changed it, and saw no difference at all, you broke nothing and you are not imagining things. Confirm through the network tab as above, and leave that screen alone.

What compresses well, and what does not compress at all

File type Gain
HTML, CSS, JavaScript, JSON, SVG Large. They are text, and text with plenty of repetition. This is where compression earns its keep.
Web fonts Some, depending on the format. Modern formats already arrive compressed.
JPEG, PNG, WebP, AVIF None. They are already compressed formats. Compressing again costs processor and saves nothing.
Video, MP3, ZIP, most PDFs None, for the same reason.
Do not confuse compression with the image problem. Compression handles text, and text is rarely what weighs on a page. What weighs is photographs uploaded exactly as they came off the camera. A large image in a small box makes every visitor download all of it to see almost none of it, and no compression on earth fixes that. Resize before uploading: it is in what actually makes a difference.

If you want to go further

1 On a WordPress site, LiteSpeed Cache. As well as storing finished pages, it handles compression of what it serves, and it is the right piece for our servers.
2 A network in front of the site. Services such as Cloudflare compress with a more efficient algorithm and serve files closer to the visitor. Explained in Cloudflare: when it helps and how to switch it on.
3 Fewer files, rather than smaller files. A page that asks for hundreds of things is slow even with everything compressed. Cutting the number of requests usually pays more than squeezing the bytes harder.

And always the same rule: measure, change one thing, measure again. The tools, and what the numbers mean, are in measuring your site speed.

Measured it and content-encoding is nowhere to be seen? Tell us the exact address and we will look.

Open a support ticket

SEE ALSO

Hosting plans and what each one includes

WordPress hosting

RECOMMENDED PRODUCT

Web hosting with cPanel

Domain and SSL included, daily backups and the panel you already know. from $9.99/mo

See plans
  • 0 Users Found This Useful
Was this answer helpful?