IntersectionObserver 使延迟加载 变得更加容易 并且比以前更高效，但是要真正正确地执行它，您仍然需要删除src等内容，这很麻烦。 它绝对不像
<img src="celebration.jpg" loading="lazy" alt="..." />
Addy Osmani 说的那样，它将在 Chrome 75 中出现
loading属性允许浏览器延迟加载屏幕外的图像和 iframe，直到用户滚动到它们附近。loading支持三个值
lazy：是延迟加载的理想选择。eager：不适合延迟加载。 立即加载。auto：浏览器将确定是否延迟加载。
我可能会最终为此站点编写一个 WordPress 内容过滤器，该过滤器为该站点上的每个图像添加该属性。 我说哈利路亚，并祝愿其他浏览器一切顺利。
图像的轻松延迟加载将对整个站点产生最大的影响，但是对于使用它们的各个站点而言，iframe的延迟加载将更大。 我很喜欢它。
是的，是的，无论图像的原生延迟加载如何，iframe 的延迟加载都将成为广告技术领域的改变游戏规则： https://#/ADGc1UsVBf
— Laurie Voss (@seldo) 2019年4月8日
我希望这能推动对 原生纵横比 的需求，因为这样做的主要原因是防止内容从稍后加载的内容中重新流动。 不过，我们现在有 方法。
如果您现在正在考虑为站点的媒体添加延迟加载，那么最好包含这些原生延迟加载属性，但是截至此更新（2019年7月），稳定浏览器中的支持仍然不存在。 您需要考虑执行更多
此浏览器支持数据来自 Caniuse，其中包含更多详细信息。 数字表示浏览器在该版本及更高版本中支持该功能。
桌面
| Chrome | Firefox | IE | Edge | Safari |
|---|---|---|---|---|
| 77 | 121 | 否 | 79 | 16.4 |
移动/平板电脑
| Android Chrome | Android Firefox | Android | iOS Safari |
|---|---|---|---|
| 127 | 127 | 127 | 16.4 |
我想知道 JavaScript 添加 loading=”lazy” 是否有效，或者它在加载过程中的时间是否太晚？ 扩展程序，甚至是一个 Tampermonkey 脚本，将所有图像和 iframe 设置为延迟加载可能很不错。
我在该描述中注意到的其他内容。“Chrome 中加载的实现细节是它在页面加载时获取图像的前 2KB。 当用户即将看到它们时，它会获取图像其余的字节。” 这让我认为浏览器将通过获取图像的大小来防止内容重新流动，而无需加载整个图像。
通过 JavaScript 设置 loading=”lazy” 无法正常工作，因为浏览器会立即开始加载图像，即在解析 DOM 节点的那一刻。 另一种方法是通过 JavaScript 将 loading=”lazy” 更改为 loading=”eager”，这可以按预期工作。 是的，“预检”范围请求（获取前 2 KB）用于确定图像的尺寸。
已经有一个关于功能策略的提案，建议将所有图像默认设置为 loading=”lazy”，而无需更改每个 img 标签。
我写了一篇关于此的综合文章，其中包含代码片段和所有请求的响应时间表。 您可以在此处找到它：https://tiny.pictures/guide/native-lazy-loading
背景图像呢？ 我正在使用带有 CSS 背景图像的 div……
你好。 根据您的需要，有时将背景图像用作图像会很方便。 但是，如果您的图像为内容，则不应该这样做。 因为普通图像可打印、可访问且最适合 SEO 等。 在此处阅读有关响应式图像的延迟加载的更多信息：https://www.andreaverlicchi.eu/lazy-load-responsive-images-in-2019-srcset-sizes-more/。 顺便说一句，vanilla-lazyload 脚本还允许您延迟加载背景图像，并在受支持的情况下使用原生延迟加载。 试试看！
此功能是否也适用于基于 Chromium 的浏览器？
好吧，该代码未能显示，让我们尝试一下
<img src="whatever" async>这是个好消息！ 我确实想知道旋转木马或幻灯片放映……浏览器是否足够智能，知道当用户位于幻灯片 5 时，幻灯片图像“x”仍然在 15 个幻灯片之外……因此，不要下载图像，直到它靠近可见窗口……
也许“loading”属性的第四个可能值为“never”……这意味着“永不加载”，然后当幻灯片接近在旋转木马上可见时，您可以（通过 JavaScript）将“loading”属性切换为“eager”……
无论哪种方式，这都是添加到原生 Web 的一项很棒的新功能。
我想现在谈论那个日子还为时过早……
如果我们能够使用几行代码同时使用原生延迟加载和基于 js 的 IntersectionObserver 延迟加载会怎样？ 方法如下
https://www.andreaverlicchi.eu/native-lazy-loading-with-vanilla-lazyload/
如果此功能必须在页面加载时获取所有图像的前 2KB 才能确定哪些图像位于视口中，那么我很难理解它将如何有效。 假设我有 20 张图像堆叠在一起……浏览器将需要发出 20 个图像请求才能确定哪些图像位于视口中，然后才会开始加载视口内的完整图像。 即使视口中只有 2 张图像，这也会导致 22 个服务器请求，这可能会减慢响应速度。 这意味着总共 20 张图像的页面上会有 40 个服务器请求，基本上使请求数量翻倍。
可以在布局中为图像包含正确的内在占位符，但如果浏览器首先从每个图像中预取 2KB 数据，那还有什么意义呢？ 浪费请求和带宽。
目前，现代 JS IntersectionObserver 看起来更有效，只会对视口中的图像造成更少的请求。
我错过了什么吗？
大家好，在网络上找不到答案。
也许我太笨了，但是，现在 Chrome v75 已经发布，原生延迟加载终于得到支持了吗？