Why smaller assets win
After you've removed unused resources entirely, the next biggest performance win is shrinking what remains. For text-based assets, there are essentially two levers: eliminate redundant or needless content before it hits the wire, and apply generic compression at the server level.
These approaches are complementary. Preprocessing catches what a generic compressor cannot—redundancy in code structure and syntax—while transport compression like gzip or Brotli squeezes the bytes that remain.
How compression actually works
Data compression merely encodes information using fewer bits. There is no single best algorithm; efficiency depends on the data. Eliminating unnecessary data always gives the largest gains.
To see why, imagine a simple text message format that consists of comments (# prefix), headers (key-value pairs), and a text payload. A 200-character example contains comments that don't affect behavior, verbose headers, and a payload with visibly repeated characters.
Compression here uses three techniques:
- Drop the comment entirely.
- Leave headers alone if you can't assume a fixed schema.
- Replace runs of repeated characters with shorter forms, such as turning
"AAA"into"3A".
Applying these steps yields a 56-character output, a 72% reduction. Real-world algorithms are far more sophisticated, but the principle holds: text-based resources contain patterns and repetition that compressors can exploit to shorten download times.
Minification: content-aware preprocessing
Minification is not itself a compression algorithm. Rather, it strips characters from source code, formatting clarity that browsers don't need and that users never see.
Best applied during a build step, minification dramatically shrinks payload size. Consider the three content types in a typical HTML document:
- HTML markup defines page structure.
- CSS controls presentation.
- JavaScript drives behavior.
Each has different syntax and comments. All share removable ballast:
- Comments (
/* ... */,<!-- ... -->,// ...) do nothing for browsers. - CSS rules can sometimes be collapsed. For instance, two declarations for the same selector can merge into one. This is tricky: selectors are often duplicated intentionally, such as inside media queries, so aggressive consolidation isn't always safe.
- Whitespace in source formatting is rarely needed on production. Spaces and tabs are safe to remove from code, but not from visible text runs in HTML, where spaces affect user-facing layout and readability.
In one example, applying these changes brings an HTML page from 516 down to 204 characters, roughly a 60% savings. The result is dense, but usable—and paired with source maps, you keep readable development code while shipping optimized production code and staying able to debug issues.
A generic text compressor cannot know to strip <!-- comments --> or consolidate CSS. These content-specific optimizations require context. The same idea extends beyond text: image files embed metadata like camera settings, location, and settings, which can add tens of kilobytes per image depending on the source. If your application doesn't need this data, removing it before upload keeps your assets lean.
Putting text optimization into practice
- Inventory your asset types. List the content types your site serves and ask what is redundantly structured or removable without breaking functionality.
- Automate. Add minification and similar preprocessing to your build and release pipeline so that every production deployment carries the same optimizations.
- Confirm the result. Check that stripped comments and collapsed rules haven't altered site behavior. Testing after optimization prevents shipping subtle regressions.
Optimization is a war of attrition, and for text, preparation matters more than generic techniques. First remove what's unnecessary, then pre-process structure, and transport-level compressors will handle the remainder.
Compression: the second lever for text assets
Where minification strips redundancy within a file, compression targets repetition across the whole payload. Applying gzip or Brotli to text-based resources before they hit the wire, then decompressing them in the browser, typically yields another dramatic size reduction and faster transfer.
Two algorithms dominate: gzip and Brotli. Both are supported by every modern browser, which advertise their availability in the Accept-Encoding HTTP request header. The server must be configured to honor that header and serve a compressed variant. Many web servers enable this for text assets by default, and CDNs commonly automate it with a good balance of speed and ratio.
Both compressors scan a byte stream for repeated fragments and replace them with shorter references. They excel on text; on binary formats like images that already use their own compression, there is little or nothing to gain. On CSS, JavaScript, and HTML, both commonly achieve 70–90% compression on larger files.
The algorithms are tunable. gzip levels range from 1 to 9; Brotli's range is 0 to 11, with the highest numbers giving the best compression but costing the most CPU. For responses compressed dynamically at request time, a mid-range setting is the usual sweet spot. However, if you compress assets statically ahead of time, the most aggressive setting is free at request time and preferable. Wherever possible, prefer Brotli over gzip.
| File | Algorithm | Uncompressed size | Compressed size | Compression ratio |
|---|---|---|---|---|
| angular-1.8.3.js | Brotli | 1,346 KiB | 256 KiB | 81% |
| angular-1.8.3.js | gzip | 1,346 KiB | 329 KiB | 76% |
| angular-1.8.3.min.js | Brotli | 173 KiB | 53 KiB | 69% |
| angular-1.8.3.min.js | gzip | 173 KiB | 60 KiB | 65% |
| jquery-3.7.1.js | Brotli | 302 KiB | 69 KiB | 77% |
| jquery-3.7.1.js | gzip | 302 KiB | 83 KiB | 73% |
| jquery-3.7.1.min.js | Brotli | 85 KiB | 27 KiB | 68% |
| jquery-3.7.1.min.js | gzip | 85 KiB | 30 KiB | 65% |
| lodash-4.17.21.js | Brotli | 531 KiB | 73 KiB | 86% |
| lodash-4.17.21.js | gzip | 531 KiB | 94 KiB | 82% |
| lodash-4.17.21.min.js | Brotli | 71 KiB | 23 KiB | 68% |
| lodash-4.17.21.min.js | gzip | 71 KiB | 25 KiB | 65% |
The table above shows realized savings of 65% to 86% for several well-known JavaScript libraries.
To see compression in action, open Chrome DevTools, go to the Network panel, and load any page. Look at the bottom of the panel.
That summary shows:
- Requests: the count of resources loaded for the page.
- Transfer size: the total bytes sent over the network, which reflects the compression applied.
- Resource size: the total decompressed size of those resources.
Impact on Core Web Vitals
Core Web Vitals are user-centric metrics, so the effect of these optimizations depends on which resource you improve. Several concrete cases stand out.
Compressed HTML improves the delivery of the document itself, which means the preload scanner finds its subresources sooner. That faster discovery can help Largest Contentful Paint (LCP), whereas piling on rel="preload" hints can backfire by causing bandwidth contention.
Some LCP candidates are text-based. SVG images that qualify as LCP candidates, for instance, benefit from compression just like any other text payload—unlike raster formats that are already compressed. And if your LCP text uses system fonts instead of web fonts, smaller compressed CSS removes one more delay before that text can paint. With web fonts, font optimization best practices take precedence.
Make it automatic
These two steps—minification and compression—are baseline performance work, but they pay off disproportionately. The key is to not leave them manual. Bundlers automate minification for eligible files. For compression, configure your server correctly, then prefer a CDN that handles it for you at the best speed-to-ratio trade-off.
Locking in these basics puts your performance efforts on a solid foundation, so more advanced optimization work has something stable to build on.
