Streaming live at 10am (PST)

Webflow generated variant is larger than original



Original image: 3360x1886 @ 173kb

Webflow generated variant: 3200x1796 @ 1.6mb

Is this a bug or is this how responsive images is supposed to behave?


Hi @thewonglv,

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 [blue pixel(8)].

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 :sunny: :star2:


@YoavGivati thanks for the technical explanation of image compression.

but I cannot think of any situation where a responsive variant of an image benefits from being larger than the original – especially when the entire point of this feature is to generate smaller resolution AND smaller weight images.


The image you started with was already really compressed.

Our stack should throw out variants we generate when they're larger than the original. That's definitely something we're looking into, and I'll see if we can ship a solution for that sooner rather than later.

In this case though the 800px variant (likely to be used on retina mobile screens) is 180KB. And so you'd get the same effect by disabling responsive images for that image element.

If you hadn't already manually compressed and optimized the original image it would be 3-5MB in size and the 1.2MB 3200px variant would appear really small, instead of comparing it to the manual compression you put the original through which makes it look large in comparison.

As I explained above, when resizing we need to 'decompress' the original, then resize it, and then apply our compression to that decompressed data.

Until we can finish assessing the need and/or best way to implement configurable compression settings, I'd recommend disabling responsive image's for that image element if you'd prefer to manually compress just the orignal, or using the background-images + media queries trick if you'd prefer to manually resize and compress your own variants as some of our designers had previously been doing.


You can always disable responsiveness for specific images

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.


Unfortunately, the background image workaround isn't possible with dynamic data.


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.