All 30 checks Page sent without compression

Page sent without compression

Updated

HTML is text, and text compresses well, so a server that sends it without gzip or Brotli makes every visitor download several times more data than they need to.

Fails: Response with no content-encoding
HTTP/2 200
content-type: text/html; charset=utf-8
content-length: 148230
Fix: Compression enabled
HTTP/2 200
content-type: text/html; charset=utf-8
content-encoding: br
vary: accept-encoding

The fix for your stack

Fix for: Next.js / Vercel

// next.config.ts. Compression is on by default with `next start`;
// make sure nothing sets it to false. On Vercel, the edge compresses responses.
import type { NextConfig } from "next";

const nextConfig: NextConfig = { compress: true };

export default nextConfig;

What compression buys

Browsers announce which compression formats they understand in each request. If the server supports one, it compresses the response and labels it with a Content-Encoding header, and the browser unpacks it. For HTML, CSS and JavaScript the saving is large, often well over half of the size, and it costs the visitor nothing. On a slow mobile connection that is the difference between a page that appears at once and one that waits.

Hosting platforms differ. Most modern hosts and CDNs compress automatically, so a missing header usually means something unusual sits in the path: an old server with the feature switched off, a reverse proxy that strips encoding, or a shared host with default settings. It can also mean the response is tiny, since some servers skip compression below a minimum size.

How Skewcheck detects it

Skewcheck sends its request with an Accept-Encoding of gzip, deflate and br, a set browsers commonly offer, and reads the response headers. If the page comes back with a content-encoding header, the check passes and names the encoding. If it comes back without one, the check warns with low severity and removes 2 points from the score.

The check looks at the HTML document only, not at your scripts, stylesheets or images, and it reads the header rather than measuring the size saved. A very small page that your server chooses not to compress would warn even though compression there would not matter much. Treat the result as a pointer to look at the server configuration, not as a measurement.

Ask for compression the way a browser does
curl -sI -H 'accept-encoding: gzip, deflate, br' https://example.com | grep -i content-encoding

Turning it on

On nginx, enable gzip and list the extra types you serve; HTML is compressed once gzip is on. On Apache, enable mod_deflate and add a filter for text types. WordPress does not compress pages itself, so the web server does, and managed hosts usually switch it on, so ask yours if it is off. The per-stack tabs above show the lines, including the Next.js setting, and what to look for on Webflow and Framer, where a missing header suggests a proxy or CDN rule in front of the site removing it.

After the change, request the page with the command above, and also check your CSS and JavaScript files, which benefit just as much. If you use a CDN, check whether it compresses at the edge, because the setting there can override your server.

Before and after

Before
$ curl -sI -H 'accept-encoding: gzip, br' https://example.com | grep -i content-encoding
(nothing)
After
$ curl -sI -H 'accept-encoding: gzip, br' https://example.com | grep -i content-encoding
content-encoding: br

Check your page

Run all 30 checks on any URL. Free, no account.