关于前端:学习图片1图片简史

3次阅读

共计 2198 个字符，预计需要花费 6 分钟才能阅读完成。

本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi，蕴含一线大厂面试残缺考点、材料以及我的系列文章。

<img>这个元素简直不须要介绍了。它是 1993 年在 Netscape（过后叫“Mosaic”）公布的，并且在 1995 年退出了 HTML 的标准，始终在 Web 平台中扮演着一个简略但弱小的角色。开发人员通过 src 属性增加一个图片文件，并通过 alt 属性提供文字代替，以防图片无奈显示或者辅助技术须要代替内容。从那时起，浏览器的工作只有一件事：获取图片数据，而后尽快渲染。

<img src="https://assets.codepen.io/11355/aquilegia.jpg" alt="A white aquilegia bloom.">

在 web 开发的大部分历史中，解决图像并不简单。只管现代 web 十分复杂，但解决图像的根本准则并没有扭转：应用 web 敌对的图像格式以保障兼容性，应用正当压缩技术来节俭带宽，并使图像的尺寸适宜页面布局中的空间。

在咱们认为咱们对用户体验有更多影响力的时候，应用固定宽度布局使这个过程变得简略易懂。设置图像尺寸特地容易。对于一个宽 500 像素，高 300 像素的图像，只需指定雷同大小的图像就行了。

除了灵便的布局和应用 CSS 媒体查问之外，” 灵便的图像和媒体 ” 是响应式网页设计的三个重要方面之一。为了使图像变得灵便，开发人员开始应用 CSS 将 max-width：100% 设置在图像上（或所有图像，整个站点），通知浏览器的渲染引擎通过缩放图像来避免图像超出其父容器。从视觉上看，这完美无瑕 - 放大光栅图像在视觉上是无缝的。

通过一两行 CSS，放大的图像看起来就像咱们指定了一个图像源，而这个图像源就是要以这个尺寸显示的。当渲染引擎失去的图像数据多于图像在布局中所占据的空间时，它们就能对如何渲染放大的图像做出理智的决定，并且能够在不引入任何视觉伪影或含糊的状况下实现。

事例：https://codepen.io/web-dot-de…

你通常不心愿放大图像，也就是说，把 <img> 显示为比源图像的固有大小更大的大小。显示的图像会显得含糊和有点像颗粒的样子。

事例地址：https://codepen.io/web-dot-de…

应用 img {max-width: 100%} 意味着，当灵便的容器调整大小时，图像将依据须要放大。与设置更严格的 width: 100% 不同，这也确保图像不会超过其固有大小而被缩放。很长一段时间以来，这就是解决图像的规定：应用浏览器能了解的格局，应用正当的压缩级别，永远不要向上缩放图像。

事例地址：https://codepen.io/web-dot-de…

然而，只管这种办法在视觉上简略无效，它也带来了微小的性能代价。因为 <img> 仅反对一个图像数据源，因而该办法要求咱们提供具备尽可能大的外在大小的图像资源。

例如，如果一张图像占据的空间的宽度能够依据用户的视口大小从 300px 到 2000px 不等，则该图像的源图像的外在宽度至多应为 2000px。对于仅通过小视口查看页面的用户，所有都会看起来很失常，因为图像将很好地缩放。在出现的页面中，一个微小但放大的源图像看起来与适当大小的图像没有任何区别。然而，他们依然要传输和渲染 2000px 宽的图像，耗费大量带宽和解决能力，没有任何理论效益。

随着第一款“Retina”设施的呈现，状况变得更加蹩脚，因为显示密度成为了视口大小的关注点。为了适应高密度显示器，图像源须要更大的外在宽度。简略地说，密度是双倍的显示器须要两倍多的图像像素能力尽可能清晰地出现图像。

在这里，开发人员再次能够依附渲染引擎将图像放大的能力。通过在 src 中提供浏览器一个 800 像素 宽的源图像，并在 CSS 中指定它应该以 400 像素 宽显示，后果是以双倍像素密度渲染的图像。

事例地址：https://codepen.io/web-dot-de…

繁多图像源适宜布局中最大的可能空间和高密度显示，当然能够在视觉上适宜所有用户。微小的高分辨率图像源在小的低密度显示器上出现进去就像其余任何小的低密度图像一样，但感觉更慢。用户将接受这个微小的 4000 像素宽图像源的所有性能老本，没有任何益处。

很长一段时间以来，<img> 只做了一件事 –“获取图像数据并将其放在屏幕上”。当然它做得很好，但 <img> 无奈适应咱们正在经验的浏览上下文的巨大变化。当响应式 Web 设计成为支流开发实际时，浏览器对 img 的性能进行了优化，但除了最优越的用户外，页面的图像内容从一开始就是低效的。无论浏览器如何疾速申请、解析和渲染图像源，该资源很可能比用户须要的更大。

代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。

原文：https://web.dev/learn/images/…