How to Enable Gzip or Brotli Compression
Your audit found HTML, CSS, or JavaScript being served without HTTP compression. Enabling Gzip or Brotli on your server or CDN shrinks these text files substantially, cutting transfer size and improving load time and Core Web Vitals with no visual change to your site.
What this means
HTTP compression shrinks text-based files (HTML, CSS, JavaScript, JSON, SVG, XML) before the server sends them over the network, and the browser decompresses them on arrival. Your audit flagged one or more of these responses that came back with no Content-Encoding header, meaning they were transferred at full, uncompressed size.
The two relevant algorithms are Gzip and Brotli. Gzip has been the web standard for decades and every browser supports it. Brotli (sent as Content-Encoding: br) is newer, supported by all modern browsers, and typically compresses text 15-25% smaller than Gzip. Compression only helps text. Already-compressed binary formats like JPEG, PNG, WebP, MP4, and WOFF2 fonts should not be re-compressed, because it wastes CPU and can slightly increase their size.
You can confirm the problem yourself. Open your browser DevTools, go to the Network tab, reload the page, and click a .css or .js file. Look at the Response Headers. If there is no content-encoding: gzip or content-encoding: br, that resource is being served uncompressed.
Why it matters
Uncompressed text files are wasted bytes on every request. A large JavaScript bundle can drop to roughly a third of its size with Gzip and slightly smaller again with Brotli. That directly reduces how long the browser spends downloading render-blocking CSS and JS, which improves First Contentful Paint and Largest Contentful Paint (LCP), the metric Google wants under 2.5 seconds. Core Web Vitals are a confirmed ranking signal, so faster delivery of critical resources helps both rankings and real user experience, especially on mobile and slower connections.
Compression is one of the highest-leverage performance wins available. It is a one-time server configuration that speeds up every page for every visitor with no design or code changes.
The payoff for AI answer engines is similar. Crawlers behind ChatGPT, Perplexity, and Google's AI systems fetch pages under time and resource budgets. Serving compressed HTML means your content downloads faster within a crawl, reducing the chance a bot times out or partially fetches a page before it can extract and cite your content. Lighter responses make your site cheaper to crawl, which helps keep it well represented in the sources these engines pull from.
How to fix it
- 1
Confirm which responses are uncompressed
Identify the gap before changing anything. In Chrome DevTools open the Network tab, hard-reload the page, then right-click the column header and add the 'Content-Encoding' column. Any HTML, CSS, JS, JSON, or SVG row without 'gzip' or 'br' is a target. You can also check from the command line:
curl -sI -H 'Accept-Encoding: gzip, br' https://yoursite.com/style.css | grep -i content-encoding. An empty result means no compression is active on that response. - 2
Enable compression at the server or CDN level
Compression is a server setting, not something in your page code. On Apache, enable mod_deflate (Gzip) or mod_brotli. On Nginx, turn on gzip and, if available, the ngx_brotli module. If you sit behind Cloudflare, Fastly, or another CDN, Gzip and Brotli are usually enabled at the edge already, so check the dashboard rather than the origin. Enabling it once covers every page on the domain, which makes this the single highest-value fix.
- 3
Scope compression to text types only
Compress only text-based MIME types: text/html, text/css, application/javascript, application/json, image/svg+xml, and application/xml. Never add JPEG, PNG, WebP, MP4, or WOFF2 fonts to the compress list, since they are already compressed and re-encoding wastes CPU and can grow the file. Most server configs let you list allowed MIME types explicitly, which keeps compression targeted and efficient.
- 4
Handle managed platforms differently
On WordPress you rarely touch server config directly. A caching plugin like WP Rocket, W3 Total Cache, or LiteSpeed Cache has a compression toggle, or your host (SiteGround, Kinsta, WP Engine) may already serve it at the server. Yoast and Rank Math do not control compression, so check your host or caching plugin instead. On Shopify, Wix, and Squarespace, compression is handled automatically on their CDN and cannot be configured by you. If a Shopify audit flags it, the culprit is usually an uncompressed third-party script you added, not the platform's own assets.
- 5
Verify Brotli specifically, then re-test
Browsers advertise 'Accept-Encoding: br' only over HTTPS, so Brotli kicks in when the request is secure, the browser requests it, and the server supports it. If you enabled Brotli but still see 'gzip', confirm your site is fully on HTTPS and the Brotli module is actually compiled in and loaded. After deploying, hard-reload with DevTools open and confirm the 'content-encoding' header now reads 'br' or 'gzip' on your text assets, then re-run the audit to clear the warning.
Example
# --- Nginx ---
# Gzip (built in)
gzip on;
gzip_comp_level 5;
gzip_min_length 1024; # skip tiny files
gzip_types text/plain text/css application/javascript
application/json image/svg+xml application/xml;
# Brotli (requires the ngx_brotli module)
brotli on;
brotli_comp_level 5;
brotli_types text/plain text/css application/javascript
application/json image/svg+xml application/xml;
# --- Apache (.htaccess) ---
# Brotli if available, Gzip as fallback
<IfModule mod_brotli.c>
AddOutputFilterByType BROTLI_COMPRESS text/html text/css \
application/javascript application/json image/svg+xml
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css \
application/javascript application/json image/svg+xml
</IfModule>Enable Gzip and Brotli on Nginx and Apache, scoped to text-based MIME types only.
Platform-specific steps
Compression is a server-layer setting, not an SEO plugin one. Most managed hosts (Kinsta, WP Engine, SiteGround) serve Gzip or Brotli by default. If yours does not, enable it via a caching plugin: WP Rocket, W3 Total Cache, and LiteSpeed Cache all have a compression toggle. Yoast and Rank Math do not control this.
These platforms enable Gzip and Brotli automatically on their CDN and give you no setting to change. If an audit flags uncompressed resources, it is almost always a third-party script or app you added, not the platform's own files. Remove or replace the offending external asset.
Gzip is on by default and Brotli can be toggled in the dashboard (Speed then Optimization, depending on plan). Enabling it at the edge compresses responses for the whole site regardless of what the origin sends. Confirm the site also serves over HTTPS so browsers request Brotli.
Next.js compresses responses by default (compress: true), but in production you usually terminate at Nginx or a CDN and disable Node-level compression to avoid double work. For a raw Node/Express app, add the compression middleware. For static HTML, configure Gzip and Brotli on the web server (Nginx or Apache) as shown in the code example.
Frequently asked
Both compress text files, but Brotli (Content-Encoding: br) usually produces files 15-25% smaller than Gzip at comparable settings. Browsers request Brotli only over HTTPS. The best setup is to enable both: serve Brotli to browsers that request it and fall back to Gzip for everything else. Every major CDN and web server can do this automatically.
No. JPEG, PNG, WebP, GIF, MP4, and WOFF2 fonts are already compressed. Running Gzip or Brotli over them wastes server CPU and can even make them slightly larger. HTTP compression is for text: HTML, CSS, JavaScript, JSON, SVG, and XML. To shrink images, use modern formats like WebP or AVIF and correct sizing instead.
No. Compression is transparent. The browser decompresses files automatically before rendering, so the final HTML, CSS, and JavaScript are byte-for-byte identical to the uncompressed version. There is no visual or functional change, only smaller transfers and faster loads. The only cost is a small amount of server CPU per response, which caching the compressed output largely eliminates.
A few common causes: the flagged resource is a third-party script from another domain you do not control; the response has a missing or incorrect Content-Type so the CDN skips it; the file is below the server's minimum size threshold (many skip files under about 1 KB, which is fine); or the CDN compresses cached HTML but a dynamic response bypassed the cache. Check the specific URL in DevTools to see exactly which response lacks the content-encoding header.
Not directly, but its effect is. Compression speeds up delivery of render-blocking CSS and JavaScript, which improves Largest Contentful Paint and other Core Web Vitals, and Core Web Vitals are a confirmed ranking signal. So compression helps rankings indirectly by making pages measurably faster, which also improves the experience for real users.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.