【学习图片】1.图片简史
本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一时间和你分享前端行业趋势，学习途径等等。 更多开源作品请看 GitHub github.com/qq449245884… ，包含一线大厂面试完整考点、资料以及我的系列文章。
<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，缩小的图像看起来就像我们指定了一个图像源，而这个图像源就是要以这个尺寸显示的。当渲染引擎得到的图像数据多于图像在布局中所占据的空间时，它们就能对如何渲染缩小的图像做出明智的决定，并且可以在不引入任何视觉伪影或模糊的情况下完成。
你通常不希望放大图像，也就是说，把 <img> 显示为比源图像的固有大小更大的大小。显示的图像会显得模糊和有点像颗粒的样子。
使用 img { max-width: 100% } 意味着，当灵活的容器调整大小时，图像将根据需要缩小。与设置更严格的 width: 100% 不同，这也确保图像不会超过其固有大小而被缩放。很长一段时间以来，这就是处理图像的规则：使用浏览器能理解的格式，使用合理的压缩级别，永远不要向上缩放图像。
但是，尽管这种方法在视觉上简单有效，它也带来了巨大的性能代价。由于 <img> 仅支持一个图像数据源，因此该方法要求我们提供具有尽可能大的内在大小的图像资源。
例如，如果一张图像占据的空间的宽度可以根据用户的视口大小从 300px 到 2000px 不等，则该图像的源图像的内在宽度至少应为 2000px。对于仅通过小视口查看页面的用户，一切都会看起来很正常，因为图像将很好地缩放。在呈现的页面中，一个巨大但缩小的源图像看起来与适当大小的图像没有任何区别。但是，他们仍然要传输和渲染 2000px 宽的图像，消耗大量带宽和处理能力，没有任何实际效益。
随着第一款“Retina”设备的出现，情况变得更加糟糕，因为显示密度成为了视口大小的关注点。为了适应高密度显示器，图像源需要更大的内在宽度。简单地说，密度是双倍的显示器需要两倍多的图像像素才能尽可能清晰地呈现图像。
在这里，开发人员再次可以依靠渲染引擎将图像缩小的能力。通过在src中提供浏览器一个800像素宽的源图像，并在CSS中指定它应该以400像素宽显示，结果是以双倍像素密度渲染的图像。
单一图像源适合布局中最大的可能空间和高密度显示，当然可以在视觉上适合所有用户。巨大的高分辨率图像源在小的低密度显示器上呈现出来就像其他任何小的低密度图像一样，但感觉更慢。用户将承受这个巨大的4000像素宽图像源的所有性能成本，没有任何好处。
很长一段时间以来，<img> 只做了一件事 - “获取图像数据并将其放在屏幕上”。当然它做得很好，但<img>无法适应我们正在经历的浏览上下文的巨大变化。当响应式Web设计成为主流开发实践时，浏览器对img的性能进行了优化，但除了最优越的用户外，页面的图像内容从一开始就是低效的。无论浏览器如何快速请求、解析和渲染图像源，该资源很可能比用户需要的更大。
代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。
转载自:https://juejin.cn/post/7199474323870122043