Why Is Your Website Sending 3-5x More Data Than It Needs To? Text Compression Explained
If your audit flagged missing text compression, the fix is usually a single server setting - but it's worth understanding what's actually happening first, because this is one of the few speed findings where the browser is fully capable of loading a much lighter page and the server is simply choosing not to send it that way.
What text compression actually does
Every browser knows how to decompress files using standard algorithms called gzip and its newer, more efficient successor brotli. When a server has compression turned on, it runs your HTML, CSS, and JavaScript through one of these algorithms before sending it, and the browser unpacks it instantly on arrival - no visible delay, no plugin, no setting on the visitor's end. Because code and markup are highly repetitive (the same tag names, class names, and syntax patterns over and over), this routinely shrinks those files to a fifth or a quarter of their original size. A 200KB JavaScript bundle can become 40-50KB on the wire for the exact same page.
Why this is ever left off in the first place
Compression enabled for HTML, but never extended to CSS/JS/JSON
Most server software compresses HTML out of the box, but the list of file types it compresses is a separate setting - and it's common for that list to never get extended to stylesheets, scripts, and JSON responses, especially on older configurations that predate modern JavaScript-heavy sites.
A CDN or security layer stripping the header before it reaches the visitor
A CDN or reverse proxy in front of the site is often responsible for compression - but a WAF rule, an overly aggressive caching layer, or a security plugin can strip the content-encoding header on the way out, silently undoing what the origin server already did correctly.
Older server software missing the module entirely
Some legacy hosting stacks never had the compression module installed or enabled, and because the page still loads and looks fine, nobody has a reason to notice - it just costs every visitor extra bytes on every single request, indefinitely, until someone checks for it directly.
Not the same as image optimization
This is the most common mix-up with this finding, so it's worth being direct about it: images and video already ship in compressed binary formats - JPEG, WebP, MP4 - and running gzip or brotli over them again does nothing useful, and can occasionally make the file a hair larger. Text compression only ever applies to text-based files: HTML, CSS, JavaScript, JSON, SVG, and web fonts. If your audit also flagged oversized photos, that's a genuinely separate problem covered in our image optimization guide - fixing one doesn't fix the other, and a site can easily have one problem without the other.
How to check your own site
This one is checkable with a single terminal command:
curl -sI -H "Accept-Encoding: gzip, br" https://yoursite.com
Look for a content-encoding line in the response headers. If it says gzip or br, compression is working. If that header is missing entirely, your text files are going out uncompressed, and every visitor - especially anyone on mobile data or a slow connection - is downloading several times more than they need to for the same page.
How the free audit catches this
Missing text compression is one of the checks in our free audit, alongside the other causes covered in why your website is slow and our full website audit checklist. The report flags it directly rather than leaving it buried in a generic performance score.
Frequently asked questions
What does "text compression" mean for a website?
It means the server shrinks text-based files - HTML, CSS, JavaScript, JSON, SVG - before sending them to a visitor's browser, using an algorithm like gzip or the newer brotli. The browser decompresses it instantly on arrival. Because code and markup are highly repetitive, this routinely cuts those files to a fifth or a quarter of their original size, for zero visible change to the page.
Why would a website ever have this turned off?
Three common ways it happens: the server's default configuration only compresses HTML and someone never added CSS/JS/JSON to the list of compressed file types; a CDN or reverse proxy in front of the site is supposed to add compression but a security plugin, WAF, or misconfigured caching rule strips the header before it reaches the visitor; or older server software is missing the compression module entirely and no one has ever had a reason to notice, because the page still loads - just slower and heavier than it should.
Does compressing my images help the same way?
No, and this is the most common mix-up with this finding. Images and video already ship in compressed binary formats (JPEG, WebP, MP4) - running gzip or brotli over them again does nothing, sometimes even makes the file slightly larger. Text compression only applies to text-based files: HTML, CSS, JavaScript, JSON, SVG, and web fonts. Fixing oversized images is a separate, real problem covered in our image optimization guide, not this one.
How do I check if my own site has compression enabled?
Run curl -sI -H "Accept-Encoding: gzip, br" https://yoursite.com in a terminal and look for a content-encoding header in the response. If you see content-encoding: gzip or content-encoding: br, it's working. If that header is missing entirely, your text files are going out uncompressed and every visitor is downloading several times more data than necessary for the exact same page.
Is this really as easy a fix as it sounds?
Usually yes - on most hosting setups it's a single server or CDN setting with no design or content changes needed, which is why it's often called the cheapest speed win available. The one exception is a host that genuinely can't support it (rare on modern infrastructure), where the workaround is moving static assets behind a CDN that compresses on your behalf.
The cheapest way to find out
Run the free audit below. We check speed - including this exact compression test - alongside SEO, accessibility, and security, using the same tooling Google itself uses, and email you a plain-English report the moment something's wrong. If something needs fixing, it's a flat $149 for your fixable speed/image/SEO/broken-link issue, or $299 for everything, with before-and-after proof once it's done.