EMZETT.Compressing
In short: Re-encoding data so it takes up less storage space.
In more detail: Lossless compression (e.g. with ZIP) reconstructs exactly the original data when decompressing — used for programs, documents, archives. Lossy compression (e.g. with MPEG or JPEG) sacrifices some information for even smaller file sizes, which is often barely perceptible for image/video/audio.
In Depth
Lossless compression algorithms (e.g. DEFLATE, the basic method behind ZIP and PNG) exploit the fact that real data is rarely truly random — it contains repetitions and patterns that can be encoded more briefly. A simple basic principle: if a string of characters occurs several times, the second time it’s only stored as a reference to the first occurrence, instead of being written out again. Text and source code therefore usually compress very well (lots of repetition), while already-compressed data (JPEG images, zipped archives), by contrast, barely compresses further, since there’s hardly any redundancy left there.
Lossy compression (e.g. for JPEG, MP3, MPEG) takes a different approach: instead of just removing redundancy, information barely perceptible to humans is deliberately discarded (e.g. frequencies outside the human hearing range for audio, fine colour nuances for images). This allows considerably higher compression ratios than lossless methods, but it can no longer be undone.
Common algorithms compared
Besides DEFLATE (ZIP, gzip, PNG), there are several more modern lossless algorithms with different trade-offs between compression speed and ratio: LZMA (used by 7-Zip) usually achieves considerably better compression ratios than DEFLATE, but needs more computing time and memory for it — well suited when archives are created once and downloaded often, less suited for real-time compression. Brotli (developed by Google, specifically optimised for web assets) and Zstandard (by Facebook/Meta) are newer algorithms that try to combine the best of both worlds — very good compression together with high speed, which is why they’re increasingly replacing gzip on web servers (e.g. Content-Encoding: br in HTTP responses).
Compression in web development
Servers practically always compress text content (HTML, CSS, JavaScript, JSON API responses) before transmission, since text compresses very well (often 70-80% smaller) — the browser decompresses transparently in the background, without the application noticing. Next.js/Vercel enable this by default via the Accept-Encoding header, which the browser sends along to signal which compression methods it understands. Already binary-compressed formats like JPEG images or video, by contrast, barely benefit from additional transport compression, since there’s hardly any redundancy left there — a second compression pass just wastes computing time with no meaningful size gain.
See also: Decompressing, ZIP, Archive