Compression

Back when connections were narrow, a slow page had an obvious explanation. There was a lot to send and very little room to send it through. What was less obvious, until someone looked closely, was how much of that payload was waste. Nearly every file behind a web page is text. The document describing the structure of the screen, the stylesheet describing colors and spacing, the script describing behavior — all of them are written for a person to read and edit. And inside them the same strings repeat hundreds of times. A single stylesheet can contain the word margin three hundred times over.

If the receiving end can reconstruct the original text exactly, then replacing every repeat with a short marker changes nothing about the result. That observation is where compression comes from. The shrinking happens right before sending and the restoring happens right after arrival, so nobody on the receiving end ever notices that anything was shrunk.

Teams that don't have this word still play out the same scene. At Pagedeck, Theo spends a day hunting through the codebase for things to delete so the script file gets smaller. He gets it from 1.2 MB down to 1.1 MB, and the next feature pushes it straight back to 1.2 MB. Meanwhile Mia keeps asking why the app is still slow. That same file could have gone down to 300 KB through one line of server configuration, without a single line of code changing.

Turning it on runs in four beats: measure, choose a method, decide where the shrinking happens, and measure again. None of it touches application code — it's server or build configuration — which is why one engineer can usually finish the whole thing in half a day.

1. Measure what's going over the wire today. The network tab in a browser's developer tools shows the transferred size of every file. If a response carries a content-encoding header, it's already being compressed; if it doesn't, the file is leaving the server at full size.
2. Choose a method. gzip is the default that works everywhere. Brotli shrinks the same file another 15 to 20 percent but takes longer to do the shrinking.
3. Decide where the shrinking happens. Files that never change get compressed once at build time; responses that differ per user get compressed as they go out. The first kind only costs build minutes, so the compression level can go to the maximum. The second kind costs work on every request, so it stops somewhere in the middle.
4. Decide what's eligible. Put text-based files on the list and leave photos and video off it. The next section explains why.
5. Measure again. Check that transferred sizes dropped, and check that time to first byte (TTFB) — the delay before the server returns the first byte of a response — didn't rise. Smaller files with a later first byte means the level in step 3 was set too high.

Pagedeck's own numbers show the shape of the win. The script that came out of the bundler, the tool that packs many source files into deployable ones, weighed 1.1 MB. Turning on gzip brought it to 320 KB and switching to Brotli brought it to 270 KB. A download that took about seven seconds on a slow mobile connection dropped under two, and largest contentful paint (LCP) — the time until the biggest block on screen is drawn — came down with it.

The wins live in text files. Scripts, stylesheets, documents, and the data responses a server returns typically fall to somewhere between a third and a quarter of their original size.

The places it barely helps are just as clear. Photos and video arrive in formats that are already compressed, so there's nothing left to squeeze out of them a second time. Shrinking image weight is a separate job, handled by image optimization rather than here.

Three limits are worth knowing.

1. Very small files aren't worth it. For a few hundred bytes, the savings come out below the cost of doing the work, so most setups skip anything under about 1 KB.
2. It costs computation. Responses that differ per user have to be compressed on every request, and the first byte arrives that much later. Pairing it with caching, which stores a result once and reuses it, or a content delivery network (CDN), which serves assets from a location near the user, removes the waste of compressing the same response over and over.
3. It doesn't reduce what you're sending. Three hundred kilobytes of code nobody uses becomes ninety kilobytes and still ships. Deleting dead code, and deferring what isn't needed yet with lazy loading, remain separate pieces of work.

"Is this actually compressed? I'm not seeing anything in the response headers."

The server is sending the original at full size. Most likely one configuration line is missing.

"Brotli would save another 50 KB, but it adds two minutes to the build."

An offer to trade build time for transfer size. Whether it's worth taking depends on how many times a day the team deploys.

"Compressing images gets you nothing. That one needs a different approach."

A correction to a setup that was applied without distinguishing file types.

At Pagedeck this sequence runs whenever someone raises first-load speed. Mia brings the numbers and says the screen takes five seconds to appear on mobile; Theo opens the network tab and looks for the heaviest thing on the list. If a script is over a megabyte with no compression header, it gets turned on that day. If it's already on, the team moves to the next candidate.

The most common belief is that compressing something degrades it. Anyone who has shrunk a photo and watched it go blurry will assume the same thing happens here. But the compression used to send web files is the kind that restores the original byte for byte. Left uncorrected, this belief turns a one-line setting into something that feels risky enough to postpone.

Almost as common is treating a smaller transfer size as proof that a heavy page has been fixed. The network tab now reads 320 KB instead of 1.1 MB, which certainly looks like progress. But the browser restores the file and then parses and executes the full 1.1 MB. What got shorter is the time spent on the wire, not the work the device does. Leave it there and the app stays fine on office wifi while an older phone still doesn't respond to taps.