Content Compression with Brotli and Gzip: Halving Your Page Weight

Content compression shrinks the text files your server sends to the browser, such as HTML, CSS, JavaScript, and JSON, by roughly 60% to 80% before they cross the network. The two algorithms in wide use are Gzip, supported everywhere for years, and Brotli, the newer one from Google that compresses text about 15% to 25% better than Gzip at comparable settings. In practice a page weighing 400 KB of HTML, CSS, and JS can drop to around 90 KB, so it arrives faster and consumes less of your bandwidth allowance. The only cost is a small slice of vCPU time per response, and that cost is tiny next to the load-time savings, especially on mobile networks.

The short rule: serve Brotli to browsers that support it with Gzip as a fallback for older clients, and split your levels so static files are pre-compressed once at build time while dynamic responses are compressed on the fly at a moderate level. Do not compress images, video, or already-compressed archives, because they will not shrink and you will only waste CPU. The rest of this guide explains the difference between the two algorithms, how levels affect the processor, what is worth compressing and what is not, then a practical nginx setup with real numbers.

Why compression is the cheapest performance win

Most of a first page's weight comes from text: the HTML template, CSS stylesheets, JavaScript bundles, and sometimes JSON API responses. These files are highly repetitive, with class names that recur, language keywords, and whitespace. Compression algorithms build a dictionary of repeated patterns and replace them with shorter tokens, so the file shrinks dramatically before transfer, then the browser expands it instantly on arrival. The visitor sees only the speed.

The benefit is double: lower load time for the visitor and lower bandwidth use on the server. When your origin sits in Riyadh with a response time near 8ms for Saudi visitors, cutting the number of bytes transferred shows up directly in how fast the page paints, because transfer time scales with size. This win costs you nothing in application code. It is purely a web-server setting.

Gzip vs Brotli: the practical difference

Gzip has been around since the 1990s and is supported almost everywhere. It compresses and decompresses fast and gives excellent results. Brotli is newer, built by Google, and ships with a built-in dictionary based on common web patterns, so it edges out Gzip on text. The gap is clearest on large static files such as heavy JavaScript bundles, where Brotli at its top level saves meaningful extra bytes.

Property	Gzip	Brotli
Browser support	Universal (every browser)	All modern browsers
Text compression ratio	Good	15% to 25% better
Compression levels	1 to 9	0 to 11
Decompression speed	Very fast	Very fast
Cost at top level	Reasonable	Heavier on CPU
Best for	Universal fallback + dynamic content	Pre-compressed static files

The smart strategy combines both rather than picking one. The browser sends in its request header which encodings it accepts, so the server offers Brotli when supported and falls back to Gzip otherwise. That way you get the best compression for modern visitors without breaking any older client.

Levels and their effect on vCPU

Each algorithm has levels: higher levels mean a better ratio and more processor time. The key is to separate two kinds of content. Static files such as CSS and JS are built once at deploy time, so you can pre-compress them at the highest level (Brotli 11, for example) and store the compressed copy on disk, and nginx then serves it ready with no per-request cost. Dynamic content such as HTML generated per request is compressed live, so you pick a moderate level that balances size against speed, usually Brotli 4 to 6 or Gzip 5 to 6.

On an Asas cloud server plan with one vCPU and 2GB of RAM, dynamic compression at a moderate level is barely noticeable in CPU use under normal load. If you push the level to its maximum on every dynamic request, you may see vCPU climb at peak traffic, which is exactly why pre-compressing static files pays off: you get the best ratio with no repeated cost. Per-plan resources are listed on the cloud server page, and pricing is on the plans and pricing page.

What is worth compressing and what is not

The rule is simple: compress text, and leave whatever is already compressed alone. Images in JPEG, PNG, WebP, and AVIF are internally compressed, and trying to Gzip or Brotli them will not shrink them. It only wastes CPU and can even grow them slightly. The same is true for video, audio, and archives such as ZIP and modern PDFs.

• Compress: HTML, CSS, JavaScript, JSON, XML, SVG, uncompressed fonts, text files in general.
• Do not compress: JPEG, PNG, WebP, AVIF, video, audio, archives, woff2 fonts (already compressed).

In nginx you control this through the list of MIME types included in compression, so you add only the text types. That gives you the full benefit with no waste.

A practical nginx setup with before-and-after numbers

To enable Gzip in nginx you add directives that turn compression on, name the file types, and set the minimum file size worth compressing (there is no point compressing a 200-byte file). To enable Brotli you need the brotli module added to nginx, then similar directives, plus the option to serve pre-compressed files from disk when they exist. The idea is to build compressed CSS and JS files with an extra extension at each deploy, and the server serves them directly.

The numbers speak. A typical app page with a bundled JS and CSS stack might look like this:

File	Original	Gzip	Brotli
JavaScript bundle	320 KB	96 KB	82 KB
CSS stylesheet	85 KB	18 KB	15 KB
HTML page	45 KB	11 KB	9 KB
Total transferred	450 KB	125 KB	106 KB

The transferred weight drops from 450 KB to about 106 with Brotli, less than a quarter of the original. On an average mobile connection that is a felt difference in how fast the page appears, and at the server level it means roughly a quarter of the bandwidth for the same number of visits.

Rollout steps

Work through this order on your server. First, enable Gzip at a moderate level, since it is available immediately and covers everyone. Second, add the Brotli module and enable it for supporting browsers. Third, wire your build pipeline to emit pre-compressed copies of static CSS and JS at the top level, and enable serving them from disk. Fourth, make sure the type list includes text only and excludes images and video. Fifth, measure the difference with the browser network panel before and after.

Cloud's managed hosting ships with server-level compression already on, so if you run a site on cloud hosting the basics are set for you. If you manage your own VPS, the setup above gives you full control. Either way, compression is the first and cheapest performance win to claim before any other optimization.