The Carpenter's First Glossy Finish: On the Hidden Fragility of Over-Optimized Compression
We are told, relentlessly, to squeeze our assets. To compress every last byte from our images, our scripts, our very markup. The Core Web Vital of Largest Contentful Paint demands a lean payload, and we oblige with a mechanic’s fervor, applying compression algorithms with ever-increasing aggression. A high score on the lighthouse report feels like a perfectly smooth, flawless finish on a piece of furniture. But what if this glossy surface is hiding a flaw in the wood beneath? What if, in our quest for speed, we are building websites that are paradoxically slower for the people who need speed the most?
The common mantra is simple: smaller file size equals faster download. This is a truth, but not the whole truth. It ignores the computational tax levied on the device receiving this compressed payload. Highly compressed assets, particularly images using formats like WEBP or AVIF at their most extreme quality settings, are not free to unpack. The same goes for minified and gzipped JavaScript. The decompression and parsing of these files requires CPU cycles, and CPU time is a resource as finite and precious as network bandwidth.
The Unseen Labor of the Device
On a high-end desktop computer, this tax is negligible. The powerful processor pays it without the user noticing. But venture away from this privileged environment, and the balance shifts dramatically. Consider a budget smartphone, a device with a processor several generations behind, or a device already burdened by running multiple apps. For these machines, the computational cost of decoding a heavily compressed image can be significant. The moment saved in downloading the smaller file can be entirely lost—and then some—in the time it takes the device’s struggling CPU to render it to the screen.
We’ve been optimizing for the network at the direct expense of the processor, a calculation that assumes a strong CPU and a weak connection. This is an increasingly outdated assumption. With the spread of 5G and robust Wi-Fi, network latency and throughput are improving for many, while the computational power of the vast ecosystem of devices in use worldwide remains staggeringly diverse. We are, in effect, building for the strongest devices on the weakest networks, while a large portion of our audience may be on weaker devices with perfectly adequate networks.
This creates a perverse inequality of experience. The user with the latest phone gets the benefit of both a fast download and instant decompression. The user on an older, cheaper device suffers a double penalty: they wait for the computational grind, having already been underserved by our one-size-fits-all performance model. Our obsession with file-size metrics blinds us to the total time to interactivity, the true moment when the page becomes usable.
The craft, then, lies not in applying maximum compression by rote, but in understanding the trade-off. It demands a more nuanced approach, one that considers the entire pipeline from server to painted pixel. Perhaps a slightly larger JPEG, which decodes with far less CPU effort, delivers a faster LCP on a broader range of devices than a highly compressed AVIF. It requires testing on real, low-end hardware, not just the throttled simulation in a browser’s dev tools. It asks us to think of performance not as a single number to be gamed, but as a delicate balance between network and processor, a balance that changes with every person who loads our page. The strongest construction is not always the lightest; sometimes, it’s the one that bears the load most gracefully.
Notes & further reading
A few pages I came back to while writing this: