Compression That Was Never Turned On

What it does

Text compresses extremely well, because text repeats itself.

A server can compress each text file before sending it and the browser expands it on arrival, invisibly and automatically.

For the files a page is built from, that typically removes between two thirds and three quarters of the size.

It costs a small amount of processing on both ends and is one of the few improvements with essentially no downside.

What it applies to

• The page itself.
• Stylesheets.
• Scripts.
• Fonts, in some formats.
• Data files a page requests.

It does not apply usefully to images or video, which are already compressed, and attempting it on those wastes processing for no gain. So this is a text improvement, and on a text-heavy site it is a substantial one.

How to check

Since the answer is usually available in a minute.

Run any speed testing tool and look for a compression item, which most report explicitly with the saving available.

Or open the network view in your browser, click the page itself, and look at whether the transferred size is smaller than the actual size.

Where the two numbers are the same, nothing is being compressed.

Where the transferred figure is a fraction of the other, it is working.

That check takes thirty seconds and settles it without asking anybody.

Turning it on

Which is rarely your job and is worth asking about specifically.

On managed hosting it is usually a switch in the control panel or a setting the host applies for everybody.

On other arrangements it is a server configuration change, which is a small task for whoever administers it.

Some caching and performance plugins will also enable it, which is why sites with one frequently have it and sites without do not.

Ask the host directly rather than assuming, since support will usually enable it on request in minutes.

The phrasing that gets a fast answer is asking whether text compression is enabled for your account.

A worked example

A business had a site scoring poorly on speed with no obvious cause: images were sized correctly and there were few scripts.

The network view showed the page and the stylesheet transferring at their full size.

Their host supported compression and had it switched off for that account, apparently since the account was created.

Enabling it took a support message and about ten minutes.

The transferred weight of the page fell by roughly seventy per cent and the load time improved by over a second on a mobile connection.

Nothing on the site was changed at all.

The newer method is better

Worth asking about while you are there.

There are two common compression methods, and the newer one produces smaller files than the older for the same content.

Every current browser supports it, and where it is not supported the server falls back to the older method automatically.

So there is no compatibility question, only whether your host offers it.

The difference between the two is modest against the difference between having compression and not, so this is a refinement rather than the main point.

Ask which is in use and whether the newer one is available.

Watch for it being applied to the wrong things

A rare misconfiguration worth knowing about, since it looks like a different problem entirely.

Compressing files that are already compressed, such as images or downloadable archives, costs processing and saves nothing.

Worse, a badly configured setup can compress something twice or compress a file type that does not tolerate it, which produces a download that will not open.

Where customers report a broken download or a corrupted file after a hosting change, this is worth checking before anything else.

Correctly configured, compression applies to text types only and leaves everything else alone, which is the default on any sensible setup.

Check it again after any change

Since it is a setting and settings get lost.

A hosting migration, a plan change, or a server rebuild can leave it off, and nothing announces that.

Add it to whatever you check after a move, alongside the certificate and the redirects.

The same applies after installing or removing a performance plugin, since one may have been providing it.

The thirty-second check makes this trivial to verify, which is the reason to include it.

Related settings worth asking about

Since the same conversation can cover them.

Whether files are being sent over the current protocol version, which allows many files to share one connection and helps a page with several requests considerably.

What the cache expiry is set to, which decides how much a returning visitor re-downloads.

And where the server actually is, relative to your customers.

Those three plus compression are the hosting-side items, and all four are settings rather than work on the site.

A single message to your host covering all four is a good use of ten minutes.

Minifying is the other half

Worth pairing with it, since the two get confused and both apply to the same files.

Compression makes a file smaller in transit and it arrives as it was written. Minifying removes what was never needed: spaces, line breaks, and comments in stylesheets and scripts.

The two combine rather than duplicating, since a minified file compresses further still.

Minifying is usually a plugin or a build setting rather than a host one, which is why it lives in a different conversation.

Where a speed test lists both as opportunities, do the compression first, since it is a setting and applies to everything without touching the site.

The counter-case

This is usually already on.

Most current hosting enables compression by default, so the check frequently confirms everything is fine and takes thirty seconds.

On an image-heavy site the saving is also a small proportion of the total, since images are the weight and they do not benefit.

And it does nothing for the number of requests or for scripts blocking the page.

Check it in thirty seconds, ask the host if it is off, and cover the other three settings in the same message.

What to do

1. Open the network view on your home page.
2. Compare transferred size to actual size.
3. Ask the host if they are the same.
4. Ask which method is in use.
5. Ask about the protocol version.
6. Ask about cache expiry.
7. Recheck after any migration.

Step two is the whole diagnosis, since two identical numbers mean nothing is being compressed and the fix is a support message rather than a project.

Where the server itself is the limit is covered in hosting that is the bottleneck.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.