Why File Size Is the Wrong Metric

The default assumption in image optimization is simple: smaller file equals better performance. Engineering teams celebrate when they shave 30% off a JPEG. Marketing dashboards track "bytes saved" as a KPI. DAM systems sort assets by file size, assumiThe default assumption in image optimization is simple: smaller file equals better performance. Engineering teams celebrate when they shave 30% off a JPEG. Marketing dashboards track bytes saved as a KPI. DAM systems sort assets by file size, treating the smallest as the best. This assumption is wrong. It was never fully right, and modern web architecture has made it actively misleading. File size measures storage. It tells you how many bytes an encoder produced. It does not tell you how fast that image reaches a user, what the user sees when it arrives, or whether the image converts a browser into a buyer. An aggressively compressed image at 200KB may have soft edges, banding gradients, and force the browser to spend CPU cycles reconstructing detail that was destroyed in encoding. A moderately compressed image at 400KB may render cleanly, stream efficiently over HTTP/2 multiplexing, and paint to the screen in fewer milliseconds. File size says the first image is optimized. User experience says the second one is. Most users are not on 3G. They are on cable, fiber, or 5G with bandwidth that exceeds what most websites send. The bottleneck is rarely throughput. It is latency, server response time, and render blocking. A 200KB image that triggers a layout shift after loading is worse than a 400KB image that paints instantly in its final position. Core Web Vitals measure this distinction directly. Largest Contentful Paint and Cumulative Layout Shift are user-centric metrics. File size is not. HTTP/2 and HTTP/3 changed the equation further by multiplexing requests, meaning a larger image that streams efficiently alongside other assets may complete faster than a smaller image waiting in a queue. The relationship between bytes and milliseconds is no longer linear. It is not even reliably correlated. The business costs follow from this confusion. E-commerce teams compress product images to hit arbitrary kilobyte targets and find that customers zoom in on soft detail and hesitate. Hero banners get crushed until brand colors shift. Marketing teams optimize for Lighthouse scores that improve file size metrics but show no correlation with conversion rates. DAM systems compound the problem by burying the highest-engagement assets, which are often the richest and most detailed, because they sort for storage efficiency rather than business value. The right frame is different: measure speed index, measure LCP with visual fidelity as a constraint rather than an afterthought, and measure whether an image actually serves its purpose. Optimization is a user experience problem, not a storage problem.The default assumption in image optimization is simple: smaller file equals better performance. Engineering teams celebrate when they shave 30% off a JPEG. Marketing dashboards track "bytes saved" as a KPI. DAM systems sort assets by file size, assuming the smallest is the best. This assumption is wrong. It was never fully right, and modern web architecture has made it actively misleading. What File Size Actually Measures File size measures storage. It tells you how many bytes an encoder produced. It does not tell you how fast that image reaches a user. It does not tell you what the user sees when it arrives. It does not tell you whether the image converts a browser into a buyer. Consider two images. Image A is 200KB. Image B is 400KB. Image A is aggressively compressed. Its edges are soft. Its gradients show banding. It requires a browser to spend CPU cycles deblocking and reconstructing detail that was destroyed. Image B is moderately compressed. It renders cleanly. It streams efficiently over HTTP/2 multiplexing. It paints to the screen in fewer milliseconds. Which is optimized? File size says A. User experience says B. The Latency Problem Most users are not on 3G. They are on cable, fiber, or 5G with bandwidth that exceeds what websites send. The bottleneck is rarely throughput. It is latency, server response time, and render blocking. A 200KB image that triggers a layout shift after loading is worse than a 400KB image that paints instantly in its final position. Core Web Vitals measure this. Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) are user-centric metrics. File size is not. HTTP/2 and HTTP/3 changed the equation further. These protocols multiplex requests. A larger image that streams efficiently alongside other assets may complete faster than a smaller image that waits in a queue. The relationship between bytes and milliseconds is no longer linear. It is not even reliably correlated. The Business Cost E-commerce teams compress product images to hit arbitrary KB targets. The result: customers zoom in on soft detail and hesitate. Hero banners are crushed until brand colors shift. Marketing teams optimize for Lighthouse scores that improve file size metrics but do not correlate with conversion rates. DAM systems compound this. When assets are sorted by file size, the highest-engagement images—often the richest, most detailed ones—are buried. The system optimizes for storage cost, not business value. What to Measure Instead Measure speed index. Measure LCP with visual fidelity as a constraint, not an afterthought. Measure whether the image serves its purpose: does a product photo sell the product? Does a hero banner communicate brand quality? Optimization is a user experience problem. It is not a storage problem. The next article in this series introduces perceptual optimization: how to measure quality the way humans actually see it.ng the smallest is the best.

This assumption is wrong. It was never fully right, and modern web architecture has made it actively misleading.

What File Size Actually Measures

File size measures storage. It tells you how many bytes an encoder produced. It does not tell you how fast that image reaches a user. It does not tell you what the user sees when it arrives. It does not tell you whether the image converts a browser into a buyer.

Consider two images. Image A is 200KB. Image B is 400KB. Image A is aggressively compressed. Its edges are soft. Its gradients show banding. It requires a browser to spend CPU cycles deblocking and reconstructing detail that was destroyed. Image B is moderately compressed. It renders cleanly. It streams efficiently over HTTP/2 multiplexing. It paints to the screen in fewer milliseconds.

Which is optimized? File size says A. User experience says B.

The Latency Problem

Most users are not on 3G. They are on cable, fiber, or 5G with bandwidth that exceeds what websites send. The bottleneck is rarely throughput. It is latency, server response time, and render blocking.

A 200KB image that triggers a layout shift after loading is worse than a 400KB image that paints instantly in its final position. Core Web Vitals measure this. Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) are user-centric metrics. File size is not.

HTTP/2 and HTTP/3 changed the equation further. These protocols multiplex requests. A larger image that streams efficiently alongside other assets may complete faster than a smaller image that waits in a queue. The relationship between bytes and milliseconds is no longer linear. It is not even reliably correlated.

The Business Cost

E-commerce teams compress product images to hit arbitrary KB targets. The result: customers zoom in on soft detail and hesitate. Hero banners are crushed until brand colors shift. Marketing teams optimize for Lighthouse scores that improve file size metrics but do not correlate with conversion rates.

DAM systems compound this. When assets are sorted by file size, the highest-engagement images—often the richest, most detailed ones—are buried. The system optimizes for storage cost, not business value.

What to Measure Instead

Measure speed index. Measure LCP with visual fidelity as a constraint, not an afterthought. Measure whether the image serves its purpose: does a product photo sell the product? Does a hero banner communicate brand quality?

Optimization is a user experience problem. It is not a storage problem.

The next article in this series introduces perceptual optimization: how to measure quality the way humans actually see it.