A 2.4 MB portrait, and what unoptimized actually turns off
2026-11-06 · 2 min read · Engineering
One image was larger than the rest of the site combined. The fix was four lines, but the interesting part is why it was that large.
The numbers
The portrait on my about page was 2,507,195 bytes: a 1254 by 1254 PNG at 16 bits per channel, displayed in a circle 320 pixels wide. Every visitor downloaded all of it to look at a thumbnail.
What the prop actually does
The image was rendered with unoptimized set, and quality={100} sitting on the line above it. That pairing taught me something. unoptimized does not mean lower effort - it means the optimizer is skipped entirely, so no resizing, no format conversion, no generated srcset. Which also means quality is never read.
The two props look like they are arguing about compression. In fact one of them had already ended the conversation.
Three reasons it was big
Only one of them was compression. It was four times wider than it needed to be. It was 16 bits per channel where 8 is indistinguishable at that size. And it carried an alpha channel that was uniformly opaque from corner to corner - roughly a quarter of the file storing the same number over and over.
Converted to WebP at 640 pixels, which is twice the display size for high-density screens, it came out at 16,712 bytes. Served through the image optimizer it arrives as 11.6 KB. That is a 99.5% reduction for an image nobody will notice has changed.
The part I nearly got wrong
The sizes attribute is a description of your layout, not a request. The browser uses it to pick a candidate from the srcset before it knows anything about your CSS. My container is a fixed 320 pixels at every breakpoint, so sizes="320px" is the truth. A responsive value copied from a tutorial would have described a layout I do not have, and the browser would have believed it.