重访压缩图像-CSDN博客

2012 was a dark time for responsive images. Standards work had begun, but there was no consensus and many angry people (myself included). Some remained unconvinced that responsive images were even a problem that needed to be solved.

2012年是响应式图像的黑暗时期。标准工作已经开始，但是没有达成共识，并且有许多愤怒的人(包括我自己)。一些人仍然不相信响应式图像甚至是需要解决的问题。

But there was still a glimmer of hope in these dark days. In July of that year, Daan Jobsis discovered a technique that the Filament Group would later dub “compressive images”. The technique became pretty popular and worked quite well in lieu of an actual standard.

但是在这些黑暗的日子里仍然充满了一线希望。那年7月，大安·乔布斯(Daan Jobsis) 发现了一项技术，细丝小组后来将其复制为“压缩图像” 。该技术变得非常流行，并且代替了实际标准，效果很好。

Now, fast forward to today. We have a set of standards for responsive images, browsers have improved image loading—does the compressive images technique still have a place in our workflow? I’ve been threatening to write this post for a long time, but just kept putting it off. But when Dave Shea offers you a like, you take it (there…happy Dave?).

现在，快进到今天。我们为响应图像制定了一套标准，浏览器改善了图像加载-压缩图像技术是否仍在我们的工作流程中占有一席之地？我一直在威胁要写这篇文章很长一段时间，但一直都推迟发布。但是，当Dave Shea为您提供喜欢时，您就接受了(Dave高兴吗？)。

什么是压缩图像？ (What are compressive images?)

The compressive images technique relies on you sizing a JPG image to be larger than the size it ultimately is displayed at and then compressing it to an incredibly low-quality setting. This cuts the image weight dramatically, but also makes the image look absolutely terrible. However, when the browser sizes the image down to be displayed, it looks fantastic again. In fact, it even looks fantastic on high-resolution displays. Magic! (Warning: Not actually magic.)

压缩图像技术取决于您将JPG图像的大小设置为大于最终显示的大小，然后将其压缩到令人难以置信的低质量设置。这样可以大大减轻图像重量，但同时也使图像看起来绝对糟糕。但是，当浏览器缩小图像尺寸以进行显示时，它再次看起来很棒。实际上，它甚至在高分辨率显示器上看起来也很棒。魔法！ (警告：实际上不是魔术。)

The benefit in weight can be substantial. In the Filament Group’s article, the example image was a whopping 53% lighter (from 95kb to 44kb).

重量方面的好处可能很大。在Filament Group的文章中，示例图像的亮度降低了53％(从95kb减少到44kb)。

The trade-off for compressive images is primarily the memory cost (there used to be scaling and decoding risks, but browsers have improved in that area).

压缩图像的权衡主要是内存成本(过去存在缩放和解码风险，但浏览器在该方面有所改进)。

Let’s consider the Filament Group’s example image again. The original image is a 400px by 300px image. The compressive image is 1024px by 768px.

让我们再次考虑细丝组的示例图像。原始图片是400px x 300px的图片。压缩图像为1024px x 768px。

When a browser stores a decoded image in memory, each pixel is represented by an RGBA value which means that each pixel costs us four bytes (a byte each for the red, green, blue and alpha values). The memory footprint of decoded images is only reported by Edge and Firefox at the moment, but it can be calculated easily enough.

当浏览器将解码后的图像存储在内存中时，每个像素都由RGBA值表示，这意味着每个像素要花费我们四个字节(红色，绿色，蓝色和alpha值每个字节)。解码图像的内存占用量目前仅由Edge和Firefox报告，但可以很容易地计算出来。

Take the height of the image and multiply it by the width of the image to get the total number of pixels.
取图像的高度，然后乘以图像的宽度，以得到像素总数。
Multiply the total number of pixels by 4.
像素总数乘以4。

With that in mind, let’s calculate the memory impact for both the original image and compressive image in Filament Group’s post:

考虑到这一点，让我们在Filament Group的帖子中计算原始图像和压缩图像的内存影响：

Resized image: 400 x 300 x 4 = 480,000 bytes
调整大小后的图片： 400 x 300 x 4 = 480,000字节
Compressive image: 1024 x 768 x 4 = 3,145,728 bytes
压缩图像： 1024 x 768 x 4 = 3145728字节

For the example provided, though the weight of the compressive image is less than 50% of the original weight, the memory allocated for the compressive image is roughly 6.5 times the size needed for the original image.

对于所提供的示例，尽管压缩图像的权重小于原始重量的50％，但分配给压缩图像的内存大约是原始图像所需大小的6.5倍。

另一个难题：GPU (Another wrinkle: The GPU)

Sounds terrible, right? Thankfully a few browsers have made some improvements in how images impact memory. Microsoft Edge (and IE 11+) and Blink-based browsers (Chrome + Opera) support GPU decoding of images in certain scenarios. There’s a lot of interesting fallout, but the memory impact is pretty straightforward. Since the final decoding happens on the GPU, JPG’s can now be stored in YUV values instead of RGBA values. Now each pixel only costs us three bytes:

听起来很糟糕，对吧？值得庆幸的是，一些浏览器在图像对内存的影响方面进行了一些改进。 Microsoft Edge(和IE 11+)和基于Blink的浏览器(Chrome + Opera)在某些情况下支持图像的GPU解码。有很多有趣的后果，但是对内存的影响非常简单。由于最终的解码发生在GPU上，因此现在可以将JPG存储在YUV值中，而不是RGBA值中。现在，每个像素仅花费我们三个字节：

Resized image: 400 x 300 x 3 = 360,000 bytes
调整大小后的图片： 400 x 300 x 3 = 360,000字节
Compressive image: 1024 x 768 x 3 = 2,359,296 bytes
压缩图像： 1024 x 768 x 3 = 2,359,296字节

That reduces the memory footprint a little, but it gets even better.

这样可以稍微减少内存占用，但效果会更好。

Since we’re storing the values before they’re finally converted to RGBA, browsers can also take advantage of subsampling to reduce the memory footprint even more. Subsampling isn’t the easiest thing to wrap your head around, but Colin Bendell wrote a good post going into detail and you can also read about it High Performance Images.

由于我们在将值最终转换为RGBA之前先进行存储，因此浏览器还可以利用子采样的优势来进一步减少内存占用量。进行二次采样并不是一件容易的事，但是Colin Bendell撰写了一篇很好的文章，对细节进行了详细介绍，您也可以阅读有关High Performance Images的文章。

For the context of the article, it’s enough to say that subsampling reduces the file size of the image by not necessarily including information about each and every pixel in the image. The savings don’t just apply to the file size. If a browser is storing data in YUV format, then it gets to ignore those pixel values as well based on whatever subsampling level is applied.

就本文的上下文而言，足以说明的是，二次采样可以通过不必包含有关图像中每个像素的信息来减小图像的文件大小。节省的费用不仅仅适用于文件大小。如果浏览器以YUV格式存储数据，则基于所应用的子采样级别，它也将忽略那些像素值。

Any image saved at a low-enough quality to take advantage of the compressive images technique will be using 4:2:0 subsampling. As a result, the browser only has to store a couple pixel values per section of the image. The math is slightly trickier, but the basic idea is that fewer pixel samples mean fewer pixels stored in memory.

以低质量保存的任何图像都将利用压缩图像技术，将使用4：2：0二次采样。结果，浏览器仅需在图像的每个部分存储几个像素值。数学上有些棘手，但是基本思想是更少的像素样本意味着更少的像素存储在内存中。

Resized image: 400 x 300 x 3 = 360,000 bytes
调整大小后的图片： 400 x 300 x 3 = 360,000字节
Compressive image: 1024 x 768 x 3 - (1024 x 768 x .75 x 2) = 1,179,648 bytes
压缩图像： 1024 x 768 x 3-(1024 x 768 x .75 x 2)= 1,179,648字节

GPU decoding reduces the memory cost quite a bit. Without GPU decoding, the memory footprint for the compressive image was around 6.5 times the size of the original image. With GPU decoding in place, the memory footprint is closer to 3.3 times the original.

GPU解码大大降低了内存成本。如果不使用GPU解码，则压缩图像的内存占用量约为原始图像大小的6.5倍。借助GPU解码功能，内存占用空间接近原始内存的3.3倍。

我们应该怎么做呢？ (What should we do instead?)

By now the trade-off is pretty clear. Compressive images give us a reduced file size, but it greatly increases the memory footprint. Thanks to the standards that have been developed around responsive images, it’s a trade-off we no longer need to make.

到现在为止，权衡已经很明显了。压缩映像使我们减小了文件大小，但是却大大增加了内存占用。感谢围绕响应图像开发的标准，这是我们不再需要进行的权衡。

For selectively serving images to higher resolutions, the solution could be as simple as using the srcset attribute with a density descriptor.

为了选择性地以更高的分辨率提供图像，解决方案可能与将srcset属性与密度描述符一起使用一样简单。

<img src="/images/me.jpg" alt="Image of me" srcset="/images/me-1x.jpg 1x, /images/me-2x.jpg 2x" />

The snippet above:

上面的代码段：

Provides an image (me.jpg) for the default. Any browser not supporting the srcset attribute will load this.
提供默认图像(me.jpg)。任何不支持srcset属性的浏览器都将加载此属性。
Provides two alternative images (me-1x.jpg and me-2x.jpg) that browsers can choose from based on the screen resolution. The density descriptors (1x and 2x) help the browser determine which is the appropriate one to use.
提供两个替代图像(me-1x.jpg和me-2x.jpg)，浏览器可以根据屏幕分辨率从中选择。密度描述符(1x和2x)可帮助浏览器确定使用哪种适当的描述符。

This allows you to serve a lower quality image for older browsers (me.jpg), something appropriately sized but slightly better quality for 1x screen resolutions (me-1x.jpg), and a large high-resolution image for double-density displays (me-2x.jpg). No one pays a higher memory cost than necessary and the network costs can still be kept mostly in check.

这样一来，您可以为较旧的浏览器提供质量较低的图像(me.jpg)，为1x屏幕分辨率(me-1x.jpg)提供尺寸适当但质量稍高的图像，并为双密度显示提供较大的高分辨率图像( me-2x.jpg)。没有人会付出比必要更高的内存成本，并且网络成本仍然可以控制下来。

That’s a straightforward use-case, but even if your situation is more complex you can likely navigate it with some combination of srcset, sizes or picture. Jason Grigsby’s ten-part (yes, 10) series of posts on responsive images is still my favorite go-to for anyone who would like to read a bit more. Just don’t tell Jason I said that—it would give him a big head.

这是一个简单的用例，但即使你的情况比较复杂，你可以有可能与某些组合导航它srcset ， sizes或picture 。贾森·格里斯比(Jason Grigsby) 关于响应式图像的十篇文章(是的，十篇) 系列仍然是我想要阅读更多内容的人的最爱。只是不要告诉杰森我说的那样—它会让他大胆地接受。

All of this isn’t to say we should never use compressive images—never is a word that rarely applies in my experience. But it does mean that we should be cautious.

所有这一切并不是说我们不应该使用压缩图像，从来都是很少适用于我的经验，一个字。但这确实意味着我们应该谨慎。

If you’re considering the approach for a single image on a page, and that image’s memory footprint will be reasonable (i.e. not a massive hero image)—you can likely use the compressive images technique without much of a problem (if you go that route, check out Kornel’s post from a few years back where he mentions modifying quantization tables to get better compressive images).

如果您正在考虑在页面上使用单个图像的方法，并且该图像的内存占用量是合理的(即不是庞大的英雄图像)，则可以使用压缩图像技术而不会出现很多问题(如果您这样做，路线，请查阅几年前Kornel的帖子，他提到修改量化表以获得更好的压缩图像。

More often than not, though, your best approach is probably to make use of the suite of responsive images standards we now have available to us.

不过，您最好的方法通常可能是利用我们现在可以使用的响应式图像标准套件。