响应式图像
*Big fat disclaimer: The stats below come from tests on Chrome and IE11, because their developer tools expose this sort of information. The impact on other browsers may be less…or more.*
* 免责声明：以下统计数据来自Chrome和IE11的测试，因为它们的开发人员工具公开了此类信息。 对其他浏览器的影响可能较小或更多。*
Way back in June, I wrote a post about the need for responsive images. The post discussed the topic from the typical point of view: the impact on page weight. But serving large images and then relying on the browser to scale them has other downsides as well.
早在六月，我写了一篇关于需要响应式图像的文章 。 该帖子从典型的角度讨论了该主题：对页面重量的影响。 但是提供大图像，然后依靠浏览器缩放它们还有其他缺点。
记忆 (Memory)
Shortly after the first post, I chatted with Ilya Grigorik a little and he brought up the toll inappropriately sized images can have on memory.
在第一篇文章发表后不久，我和Ilya Grigorik聊了一点，他提出了收费过高的图像可能在内存中存储的费用。
Once the browser decodes an image, each pixel is stored in memory as an RGBA value:
浏览器解码图像后，每个像素将作为RGBA值存储在内存中：
- 255 values for red 255个红色值
- 255 values for green 255个绿色值
- 255 values for blue 255个蓝色值
- 255 values for alpha 255个Alpha值
This means that for every pixel of an image, it’s taking up 4 bytes of memory. It’s pretty easy to see the impact that this can have when you serve large images to the browser. Here’s an example: let’s say we provide a 300px by 300px image and the browser scales it down by 100px and displays it at 200px by 200px. Those excess pixels are essentially wasted, yet they take up 40,000 (100 x 100 x 4) bytes in memory. That’s about 39kb of useless information in memory.
这意味着对于图像的每个像素，它将占用4个字节的内存。 当您向浏览器提供大图像时，很容易看到这种影响。 举个例子：假设我们提供了一个300px x 300px的图像，浏览器将其缩小100px，并以200px x 200px的比例显示。 这些多余的像素实际上是浪费的，但它们占用了40,000(100 x 100 x 4)字节的内存。 内存中大约有39kb的无用信息。
Ilya also pointed out that this makes it pretty obvious which images developers should target first with an appropriate responsive solution. Let’s look at two more images. This time, we’ll only require the browser to scale them down by 50px—a seemingly innocent number
Ilya还指出，这使得很明显哪些图像开发人员应该首先针对适当的响应解决方案。 让我们再看两个图像。 这次，我们只要求浏览器将其缩小50像素(看似无害的数字)
- 600px by 600px, downscaled by 50px to 550px by 550px 600px x 600px，缩小50px至550px x 550px
- 200px by 200px, downscaled by 50px to 150px by 150px 200px x 200px，缩小50px至150px x 150px
At first glance, it seems like these two images would have a similar impact in terms of memory—after all, each are only being scaled down by 50px. But some simple math shows that’s not at all the case:
乍一看，这两个图像在内存方面将产生类似的影响，毕竟每个图像仅缩小了50px。 但是一些简单的数学运算却并非如此：
- (600x600) - (550x550) = 57,500px (600x600)-(550x550)= 575.00像素
- (200x200) - (150x150) = 17,500px (200x200)-(150x150)= 17,500px
The difference is huge: the larger image is taking up 3.3 times as much pixels in memory—a difference of about 156kb!
两者之间的差异是巨大的：较大的图像占用的内存像素是原来的3.3倍-大约156kb！
So first rule of responsive images: hit those big images first.
因此，响应式图像的第一条规则是：先击打那些大图像。
解码 (Decoding)
Another area frequently overlooked in regards to the performance of responsive images is the time it takes for browsers to decode them.
关于响应图像的性能经常被忽略的另一个领域是浏览器解码它们所花费的时间。
To test this, I set up super crude and simple test pages, purposely keeping layout as simple as possible. On each page, the browser displays a set of images at 200px wide. The actual size of the images themselves varies from page to page. On one page, the images are 1200px wide (6x). On another, they are 400px (2x). Finally, there is one page where all images are appropriately sized at 200px.
为了对此进行测试，我设置了超级粗糙和简单的测试页 ，目的是使布局尽可能简单。 在每个页面上，浏览器显示一组200px宽的图像。 图像本身的实际大小因页面而异。 在一页上，图像为1200px宽(6倍)。 另一方面，它们是400px(2x)。 最后，在一页中，所有图像的大小都适当地设置为200px。
Each page was loaded 10 times per browser. Unfortunately, developer tools are still in the infant stage when it comes to this kind of analysis. So for decoding times, I used Chrome on the desktop as well as IE11 because those browsers have tools to see this sort of information. I also tested Chrome for Android, but decodes are not logged as a separate event and a bug results in their timeline not properly recording image resizes so I didn’t include the data here for the time being.
每个页面在每个浏览器中加载10次。 不幸的是，在进行此类分析时，开发人员工具仍处于起步阶段。 因此，为了解码时间，我在台式机和IE11上都使用了Chrome，因为这些浏览器具有查看此类信息的工具。 我还测试了Android版Chrome浏览器，但解码未作为单独的事件记录下来，并且由于错误导致其时间轴无法正确记录图像大小调整，因此我暂时不在此处包含数据。
The impact on decoding varies drastically depending on the size of images being passed to the browser.
根据传递给浏览器的图像大小，对解码的影响差异很大。
| Image Size | Number of Decodes | Decode Time | % Difference in Time from Resized |
|---|---|---|---|
| Resized (200px) | 28 | 6.65ms | -- |
| 2x (400px) | 49 | 20.59ms | + 209.6% |
| 6x (1200px) | 277 | 163.08ms | + 2352.3 % |
| 图片大小 | 解码数量 | 解码时间 | 调整大小后的时间差异百分比 |
|---|---|---|---|
| 调整大小(200像素) | 28 | 6.65毫秒 | - |
| 2x(400px) | 49 | 20.59毫秒 | + 209.6％ |
| 6x(1200px) | 277 | 163.08毫秒 | + 2352.3％ |
When images were appropriately sized (200px wide), decoding was relatively light. From the 10 runs on Chrome, the median was 28 decode events making up a grand total of 6.65ms.
当图像尺寸适当(200px宽)时，解码相对较轻。 在Chrome的10次运行中，中位数为28个解码事件，总计6.65ms。
When images were sized at two times (400px wide) the intended size of display, those decoding times take a sizeable jump. The median for Chrome was now 49 decodes and 20.59ms (209.6% increase).
当将图像大小调整为显示的预期大小的两倍(400像素宽)时，这些解码时间将发生可观的跳跃。 Chrome的中位数现在为49个解码和20.59ms(增加了209.6％)。
{{ table of impact here for Chrome, Chrome Android, IE11 on 6x}}
{{适用于Chrome，Chrome Android和IE11(6x版)的影响力表}}
Decoding times for images that were six times (1200px wide) their intended display size was, of course, much worse. The median for Chrome was 277 decodes taking up a total of 163.08ms. This represents an incredible 2352.3% increase over appropriately sized images and a 692% increase over double-sized images! Honestly, the increased number of decodes seems a little bizarre and unneeded—to the point where I wonder if there’s not a bug somewhere.
当然，图像的解码时间是预期显示尺寸的六倍(1200像素宽)，要糟糕得多。 Chrome的中位数是277个解码，总共需要163.08ms。 与适当大小的图像相比，这代表了令人难以置信的2352.3％的增加，而与双倍大小的图像相比，则增加了692％！ 坦白说，解码数量的增加似乎有些奇怪并且是不必要的，以至于我怀疑某个地方是否没有错误。
Update: After some digging, Ilya Grigorik discovered what is going on here with the number of decodes. Chrome is decoding chunks of image data as its received—not decoding the same images repeatedly. The time increase is still legit, but at least we have a nice explanation regarding the number: larger images means more chunks of data to decode.
更新：经过一番挖掘后，Ilya Grigorik发现了解码数量在这里发生了什么。 Chrome会在接收到图像数据时对其进行解码，而不会重复解码相同的图像。 时间的增加仍然是合法的，但是至少我们对数字有一个很好的解释：更大的图像意味着更多的数据块需要解码。
While some of the decoding time can be attributed simply to the large sized images, it does appear the scaling (combined with the layout) has an impact as well. A quick test of the same large sized images scaling only about 50% to 600px still showed ~80 decodes and 118ms of decode time.
虽然某些解码时间可以简单地归因于大尺寸图像，但它的缩放比例(与布局结合使用)确实也有影响。 对仅放大约50％到600像素的相同大尺寸图像的快速测试仍然显示约80个解码和118ms的解码时间。
| Image Size | Number of Decodes | Decode Time | % Difference in Time from Resized |
|---|---|---|---|
| Resized (200px) | 10 | 6.2ms | -- |
| 2x (400px) | 10 | 21.35ms | + 244.4% |
| 6x (1200px) | 10 | 101.37ms | + 1535% |
| 图片大小 | 解码数量 | 解码时间 | 调整大小后的时间差异百分比 |
|---|---|---|---|
| 调整大小(200像素) | 10 | 6.2毫秒 | - |
| 2x(400px) | 10 | 21.35毫秒 | + 244.4％ |
| 6x(1200px) | 10 | 101.37毫秒 | + 1535％ |
Looking at IE11 found similar results. For the resized images, IE11 showed 10 decode events (one per image) with a median total decode time of 6.2ms. For the 2x images, IE11’s decode count stayed at 10 but the total time for those decodes jumped to 21.35ms (244.4% increase). Once again, the 6x increase was staggering. While still reporting 10 decodes, the decode time increased to 101.37ms—a 1535% jump from the time spent on appropriately sized images.
查看IE11，发现类似结果。 对于调整大小的图像，IE11显示10个解码事件(每个图像一个)，中值总解码时间为6.2ms。 对于2x图像，IE11的解码计数保持为10，但这些解码的总时间跃升至21.35ms(增加244.4％)。 6倍的增长再次令人increase舌。 虽然仍报告10次解码，但解码时间增加到101.37毫秒，比在适当大小的图像上花费的时间增加了1535％。
I expected that this would be noticeable in someway (other than the slower time to load and display the images), but after adding 70-80 additional images, there wasn’t really a sizeable dip in FPS as you scrolled down the page on either Chrome or IE11.
我希望这在某种程度上会很明显(除了加载和显示图像的时间较慢)，但是在添加了70-80个附加图像之后，当您向下滚动任一页面时，FPS并没有真正下降Chrome或IE11。
Even though the tools aren’t there, I fired up Firefox for a visual spot check and there the FPS took a noticeable hit for large images. That fact that we’re able to get better scrolling performance by hacking things together in JavaScript, I’m willing to call say the browsers are missing something here and this a bug that should be fixed.
即使没有工具，我也启动了Firefox进行视觉检查，并且FPS在处理大型图像时表现出色。 我们可以通过将JavaScript一起黑客入侵来获得更好的滚动性能，我愿意这样说，浏览器在这里丢失了一些东西，这个错误应该得到修复。
Still, that’s not an excuse to ignore the issue. Scrolling performance has a huge impact on the user experience (something both Facebook and Etsy have seen first hand). In many scenarios this FPS hit can be really harmful. Any image heavy page with infinite scrolling, for example, would be a prime candidate for jank caused by long decodes. I’m also willing to bet there is a hit here on battery life as a result of all the extra work.
不过，这并不是忽略该问题的借口。 滚动性能会对用户体验产生巨大影响( Facebook和Etsy都已经亲眼目睹了这一点)。 在许多情况下，这种FPS击中可能确实有害。 例如，具有无限滚动的任何图像繁重的页面将是长解码导致的垃圾的主要候选对象。 我也敢打赌，由于进行了所有额外的工作，因此电池续航时间受到了影响。
调整大小 (Resizing)
But wait, there’s more! As part of the process of getting large images to display at their appropriate scale, Chrome resizes the images. IE11 showed no image resizes, so it’s either not taking this step, including the resizing information as part of the decode in their tool, or simply not exposing the resizing information at the moment for whatever reason.
但是，等等，还有更多！ 在获取大尺寸图像以适当比例显示的过程中，Chrome会调整图像大小。 IE11没有显示图像调整大小，因此它要么不采取此步骤，要么将调整大小的信息作为其工具中解码的一部分，或者只是出于某种原因暂时不公开调整大小的信息。
Those image resize times (unsurprisingly) are also impacted significantly by the size of the image being passed down.
这些图像调整大小的时间(毫不奇怪)也受到传递的图像大小的显着影响。
| Image Size | Number of Resizes | Resize Time |
|---|---|---|
| Resized (200px) | 0 | 0 |
| 2x (400px) | 19 | 16.06ms |
| 6x (1200px) | 31 | 115.77ms |
| 图片大小 | 调整数量 | 调整时间 |
|---|---|---|
| 调整大小(200像素) | 0 | 0 |
| 2x(400px) | 19 | 16.06毫秒 |
| 6x(1200px) | 31 | 115.77毫秒 |
Of course when all the images are appropriately sized, no image resizes are necessary. When the image is double sized, Chrome recorded 19 resizes, taking up a total of 16.06ms. For the page with images that are six times the displayed size, the total of resizes was now 31, taking up 115.77ms—an increase of 620.86% from the time to resize the 2x images.
当然，当所有图像的大小都适当时，就不需要调整图像大小。 当图像放大一倍时，Chrome记录了19次调整大小，总共耗时16.06ms。 对于图像大小是显示大小六倍的页面，现在调整大小的总大小为31，占用115.77毫秒-与调整2倍图像大小的时间相比增加了620.86％。
摘要 (Summary)
One thing to come out of this testing: we need better tools. From what I can tell, only Chrome and IE11 provide this information, and each of them has things to improve on here. IE11 and Chrome Mobile seem to lack any resize information. Chrome doesn’t attempt to link their decodes to the actual image (whereas in IE11, if you hover over a decode it tells you the url of the associated image). And whatever is causing the exponential growth in decode count on Chrome sure seems fishy.
此测试产生的一件事：我们需要更好的工具。 据我所知，只有Chrome和IE11可以提供此信息，并且每个都有待改进的地方。 IE11和Chrome Mobile似乎缺少任何调整大小信息。 Chrome浏览器不会尝试将其解码器链接到实际图像(而在IE11中，如果将鼠标悬停在解码器上，它将告诉您相关图像的网址)。 不论是什么原因导致Chrome上的解码数量呈指数增长，这似乎都是可疑的。
There’s also a great deal of follow-up that could be done here:
您还可以在此处进行大量后续操作：
- How do other browsers handle image decoding and resizing? 其他浏览器如何处理图像解码和调整大小？
- How do these results change as file weight is adjusted up or down (important for compressive images, for example)? 随着文件权重的增加或减少，这些结果如何变化(例如，对于压缩图像很重要)？
- Does file format impact decoding and resizing times? 文件格式会影响解码和调整大小时间吗？
Those questions aside, it’s already apparent that serving large images to the browser has some potentially series side effects from a rendering perspective. On the test page with 6x images (not unusual at the moment on many responsive sites), the combination of resizes and decodes added an additional 278ms in Chrome and 95.17ms in IE (perhaps more if we had resize data) to the time it took to display those 10 images. That much time spent on decoding and resizing can not only delay rendering of images, but could impact battery life and scrolling behavior as well.
除了这些问题，从渲染的角度来看，向浏览器提供大图像已经很明显了一些潜在的系列副作用。 在具有6x图像的测试页上(目前在许多响应站点上并不罕见)，调整大小和解码的组合使Chrome浏览器和IE分别增加了278ms和95.17ms(如果我们调整了数据大小，则可能还要更多)以显示那10张图像。 花在解码和调整大小上的大量时间不仅会延迟图像的渲染，还会影响电池寿命和滚动行为。
While page weight and load time are the most commonly cited examples, those clearly aren’t the only metrics suffering when we serve images that are too large to the browser.
虽然页面权重和加载时间是最常引用的示例，但是当我们为浏览器提供过大的图像时，显然不是唯一的度量标准。
翻译自: https://timkadlec.com/2013/11/why-we-need-responsive-images-part-deux/
响应式图像
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
