响应式图像_为什么我们需要响应式图像

响应式图像

The topic of responsive images has been one of the most hotly debated topics amongst web developers for what feels like forever. I think Jason Grigsby was perhaps the first to publicly point out that simply setting a percentage width on images was not enough, you needed to resize these images as well. He showed that if you served appropriately sized images on the original responsive demo site, you could shave 78% off the weight of those images (about 162kB) on small screens.

响应式图像的主题一直是Web开发人员中争议最大的主题之一。 我认为Jason Grigsby也许是第一个公开指出仅在图像上设置百分比宽度是不够的，您还需要调整这些图像的大小。 他表明，如果您在原始的响应演示站点上提供了适当大小的图像，则可以在小屏幕上将这些图像的重量减少78％(约162kB)。

The discussion has evolved since then with debates over what sort of solution we need (server-side, client-side), new markup (srcset vs picture) and even, in some cases, wondering whether we really needed to worry about it at all.

从那时起，讨论一直在演变，围绕着我们需要哪种解决方案(服务器端，客户端)，新标记(srcset与图片)进行辩论，甚至在某些情况下， 我们都在怀疑我们是否真的需要担心它 。

It’s a messy issue for sure. The current solutions for responsive images do come with some complexity and overhead. If you’re using a client-side solution and don’t want to make more than one request per image, then you end up breaking the preloader. As Steve Souders explained rather well, this can have a very negative impact on the time it takes for those images to actually start appearing to your visitors.

当然，这是一个麻烦的问题。 当前用于响应图像的解决方案确实具有一些复杂性和开销。 如果您使用的是客户端解决方案，并且不想对每个映像提出多个请求，那么最终会破坏预加载器。 正如史蒂夫·索德斯(Steve Souders)很好地解释的那样 ，这可能会对这些图像真正开始显示在您的访问者身上的时间产生负面影响。

No doubt there are trade-offs. Complexity of solutions, preloader versus file size—these each have to be considered when making the determination of what solution to use. Eventually we’ll have a native solution which will take care of the preloader issue, but browsers sure seem to be dragging their feet on that.

无疑存在权衡。 解决方案的复杂性，预加载器与文件大小的关系–在确定使用哪种解决方案时，必须分别考虑这些因素。 最终，我们将有一个本机解决方案来解决预加载器的问题，但是浏览器肯定会对此感到拖延。

In the meantime, I was curious just how much page weight could be saved with a responsive image solution in place. I know that on the projects I’ve worked on, the savings has often been huge, but I wanted to see how consistent my experience is with the web as a whole.

同时，我很好奇采用适当的响应式图像解决方案可以节省多少页面重量。 我知道在我从事的项目上，通常可以节省很多钱，但是我想看看我的经验与整个网络的一致性。

实验时间！ (Experiment time!)

Yoav Weiss created a bash script called Sizer-Soze that, with the help of ImageMagick and PhantomJS, determines just how much you could save in file size by serving optimized and resized images. The script is built for one url at a time, so I modified it slightly to let me loop through a list of 471 URLs (the same list used by Guy Podjarny for his analysis of responsive performance). My bash scripting skills are minimal (read: nearly non-existent), but thankfully Yoav is far more skilled there than I and was happy to help out and make the whole thing run much more efficiently.

Yoav Weiss创建了一个名为Sizer-Soze的bash脚本，该脚本在ImageMagick和PhantomJS的帮助下确定了通过提供优化和调整大小的图像可以节省多少文件大小。 该脚本一次仅针对一个网址构建，因此我对其进行了少许修改，以便让我遍历471个网址的列表(与Guy Podjarny用于分析响应性能的列表相同)。 我的bash脚本编写技能很少(阅读：几乎不存在)，但是值得庆幸的是，Yoav在那里的技能比我高得多，并且很乐意提供帮助并让整个事情更有效率地运行。

The script looped through the 471 urls, spitting out the results into a CSV. Each site was tested at widths of 360px, 760px and 1260px. Numbers were collected for total original image size, size of images if they weren’t resized but were optimized, and size of images if they were both optimized and resized to match the size they actually displayed at (so if a 1200px image was displayed at 280px wide, the script resized the image to 280px and compared the two file sizes).

该脚本遍历了471个URL，将结果分散为CSV。 每个站点的宽度分别为360px，760px和1260px。 收集了以下数字：原始图像的总大小，未调整大小但已优化的图像大小，以及经过优化和调整大小以匹配其实际显示大小的图像大小(因此，如果显示1200px图像，则为脚本宽度为280像素，将图像大小调整为280像素，并比较了两个文件的大小)。

If Sizer-Soze came across an image set to “display:none” it would re-check the dimensions every 500 milliseconds (for a maximum wait of 25 seconds) to see if things had changed. This was done to account for image-based carousels where images may have been hidden initially but then later revealed. If the image became visible during that time, then the dimensions were used to process the file savings normally. If the image was never displayed, the entire weight of the image was counted as wasted.

如果Sizer-Soze遇到设置为“ display：none”的图像，它将每500毫秒(最多等待25秒)重新检查尺寸，以查看情况是否已更改。 这样做是为了解决基于图像的轮播，其中图像可能最初是隐藏的，但随后又被隐藏。 如果在此期间图像变得可见，则使用尺寸来正常处理文件节省。 如果从未显示图像，则将图像的整个重量计为浪费。

Even with that tweak, there are few caveats about Sizer-Soze:

即使进行了这种调整，关于Sizer-Soze的注意事项仍然很少：

• It does not make a distinction between 3rd party images and images served by the site itself. So some of the weight can be attributed to things like ads.
  它不会区分第三方图像和站点本身提供的图像。 因此，某些权重可以归因于广告之类的东西。
• It does not analyze background images. That’s fine because that’s not what we want here anyway, but its worth noting that potentially even more bytes could be saved.
  它不分析背景图像。 没关系，因为那不是我们想要的，但是值得注意的是，可以节省更多的字节。
• It won’t be able to pickup some clever lazy-loading techniques, so again, its possible that some sites would actually be able to save even more than the reported numbers.
  它将无法采用某些聪明的延迟加载技术，因此，有可能某些站点实际上可以节省甚至超过报告的数量。
• It doesn’t include data-uri images in the totals as the file name exceeds the length limit for the script.
  由于文件名超出了脚本的长度限制，因此总计中不包含data-uri图像。

After looping through, the list shortened to 402 different responsive sites. Some of the original 471 moved to new URLs or apparently went AWOL so Sizer-Soze couldn’t follow along. Others had no images in the source code—either as a result of some sort of lazy-loading mechanism or by design. Still, 402 sites is a pretty good base to look at.

遍历之后，列表缩短到402个不同的响应站点。 最初的471中的一些移至新的URL或显然是AWOL，因此Sizer-Soze无法跟进。 其他人的源代码中没有图像，这是由于某种延迟加载机制或设计导致的。 尽管如此，还是有402个站点值得一看。

结果：总节省 (Results: Total Savings)

On to the results! First up, the totals.

关于结果！ 首先，总计。

Viewport Size	Sum of Original Sizes	Sum of Optimized Savings	Sum of Resized Savings
360	237.66MB	12.86MB	171.62MB
760	244.39MB	13.30MB	129.34MB
1260	250.08MB	13.70MB	104.31MB

视口大小	原始大小的总和	优化储蓄总和	调整后的储蓄总额
360	237.66MB	12.86兆字节	171.62MB
760	244.39兆字节	13.30兆字节	129.34兆字节
1260	250.08MB	13.70兆字节	104.31兆字节

It’s not too surprising to see that the original size (what’s being served now) is pretty consistent from screen size to screen size. Guy’s research, and many others, have already demonstrated this pretty well.

看到原始大小(现在要提供的内容)从屏幕大小到屏幕大小非常一致也就不足为奇了。 Guy的研究以及许多其他研究已经很好地证明了这一点。

What is staggering is just how massive the savings could be if these sites served appropriately sized images. At 360px wide, these 402 sites combine to serve 171.62MB of unnecessary weight to their visitors . That’s a whopping 72.2% of image weight that could be ditched by using a responsive image technique.

令人惊讶的是，如果这些站点提供适当大小的图像，则可以节省多少费用。 这402个网站的宽度为360px，可以为访客提供171.62MB的不必要重量。 通过使用响应式图像技术，可以减少72.2％的图像重量。

It’s not just small screens that would benefit. For 760px and 1260px sized screens, 52.9% and 41.7% of image weight is unnecessary.

受益的不仅是小屏幕。 对于760px和1260px大小的屏幕，图像重量的52.9％和41.7％是不必要的。

结果：平均储蓄 (Results: Average Savings)

Let’s look at the savings in terms of per-site averages.

让我们看一下按站点平均节省的费用。

Viewport Size	Avg. Original Size	Avg. Optimized Savings	Avg. Resized Savings
360	603.89kB	32.68kB	436.08kB
760	622.53kB	33.88kB	329.47kB
1260	635.43kB	34.81kB	265.06kB

视口大小	平均 原始尺寸	平均 优化储蓄	平均 调整后的储蓄
360	603.89kB	32.68KB	436.08kB
760	622.53kB	33.88kB	329.47kB
1260	635.43kB	34.81kB	265.06kB

Looking at it from the perspective of an individual site, the numbers feel even more impactful. For each screen size, sites on average would shed about 5% of the weight of their images (from 32-34kb) by simply doing some lossless optimization. Considering that this could be automated easily into a build process, or manually done with tools like ImageOptim with little effort—that’s an easy 5% improvement.

从单个站点的角度来看，数字的影响甚至更大。 对于每种屏幕尺寸，只需进行一些无损优化，站点平均就可以减少其图像重量的5％(从32-34kb)。 考虑到这可以轻松地自动构建到构建过程中，或者不费吹灰之力就可以使用ImageOptim之类的工具手动完成-轻松提高了5％。

Unsurprisingly, the gains are much more significant if those images get resized to an appropriate size as well. At 360px, the average site would drop 436.08kb. Consider that for a second. One optimization (resizing images) dropping that large of a chunk of weight. That takes image weight for a page from 603.89kB to a mere 167.81kB. That’s a huge difference that shouldn’t be dismissed.

毫不奇怪，如果将这些图像也调整为适当的大小，则收益将更为显着。 如果像素为360px，则平均网站大小为436.08kb。 考虑一下。 一种优化(调整图像大小)降低了很大的重量。 一页的图像权重从603.89kB降至仅167.81kB。 这是一个不容忽视的巨大差异。

While the improvements are slightly smaller for larger screen sizes (as you would expect), using some sort of responsive image technique would still save 320kB for sites displayed at 760px and 265kB for sites displayed at 1260px.

尽管对于较大的屏幕尺寸(如您所料)的改进略有减少，但对于760px显示的网站，使用某种响应图像技术仍然可以节省320kB，对于1260px显示的网站，则可以节省265kB。

结论 (Conclusion)

We spend a lot of time talking about responsive images online—debating the approaches, trying out new solutions. Sometimes it can be a little discouraging that we still haven’t gotten it ironed out (I know I feel that way frequently).

我们花了大量时间在网上谈论响应式图像-讨论方法，尝试新的解决方案。 有时我们还是没有消除它可能会有些令人气our(我知道我经常感到这种感觉)。

But the web needs us to be diligent. It needs us to not settle for seemingly simple solutions that sacrifice performance. It is extremely rare where one optimization lets us knock off such a significant amount of page weight, but here we are staring one such technique right in the face.

但是网络需要我们勤奋工作。 它需要我们不要为看似简单的解决方案而牺牲性能。 一种最优化使我们无法实现如此大的页面重量的情况极为罕见，但在这里我们正盯着这样一种技术。

72% less image weight.

图像重量减少72％。

That’s why we need a responsive image solution.

这就是为什么我们需要一个响应式图像解决方案。

翻译自: https://timkadlec.com/2013/06/why-we-need-responsive-images/

响应式图像