173KB for a 3360x1886px image is already heavily compressed. I’d expect the uncompressed jpeg version to be closer to the 3MB-5MB range for an image that looks like your example with those dimensions.
The following is an overly simplified explanation of how a variant could be larger than an original (or even larger than a larger variant) but it may help explain what’s going on.
Once our compression resizes an image it’s essentially working with different data than the original. The resizing process we use needs to ‘decode’ the jpeg because those 173KB of 1s and 0s encode very specifically that jpeg with those dimensions. It’s like unzipping a .zip file. So even though your image is being stored at 173KB with your compression, it expands to several MB when it runs through our resizing/compression pipeline or is rendered on a screen.
Now Imagine the optimized image you uploaded, lets zoom into the top left corner of the image, and say a block of 8 nearby blue pixels is being represented by fewer 1s and 0s (compressed). eg: instead of listing all 8 pixels
[blue pixel, blue pixel, blue pixel...] it’s been stored as the binary equivalent of
When we resize it we actually render out those 8 blue pixels and delete a couple. Now it’s 6 blue pixels, 1 grey, and 1 black occupying that 8 pixel grid and so when the compression tries to find patterns in 8-pixel blocks to compress the variant it decides to write it out as
[blue pixel(6), grey pixel(1), black pixel(1)]
Now when the compression does a second pass and tries to compress a series of blocks of these 8 pixel blocks, and so on, you can see how something that had large easy to find patterns would be smaller than something with less of a pattern.
Because the uncompressed variant has fewer pixels than the uncompressed original, it’s harder for the compression algorithms to find as many patterns, so it can take more data to represent the compressed variant than the compressed original or a larger variant in those cases.
Our compression is designed to find a balance between filesize and quality. It uses algorithms not only to do the compression but to visually inspect the result and define where that line is for each variant. It’s likely that there are specific images where a human can hand-tweak lossy jpeg compression to look good and get the smallest possible size, but it’s a time-consuming process that we automate to save designers time.
You can find all the details on our resizing / compression tools and configuration in the responsive image faq. The faq also describes how to use the
cmd + shift + o keyboard shortcut which lets you disable responsive images for a specific inline image element.
We’re transparent about our tools and provide a way to turn it off so that in cases when you prefer to use your own hand-compressed images you can.
We’re considering ways to give designers more control over our compression settings for your images. Until then if our compression doesn’t meet your needs I’d recommend using
background-images + media queries to define your own responsive behavior which will let you fine-tune the compression for each variant in the same app/tool used to compress your original.
I hope that helps clarify