图片延迟加载策略；我可能会遇到什么问题？

Question

我正在研究延迟加载图像的缺点，并且我必须非常彻底，因为我们正在考虑loading="lazy"在网站中的许多/大多数图像上实施。原因是我相信我有一个可行的策略。

我们正在使用 browser-nativeloading="lazy"属性，因为我们最近放弃了对 IE 的支持。哇，我知道。

我们在整个网站上将首屏上方的所有图像设置为 eager，将下方的所有图像设置为惰性图像。

然后我们监听页面加载事件并运行一个脚本，将每个图像转换为loading="lazy"(loading="eager"或auto)。因此，在大多数情况下，折叠下方的图像也将被加载，可能在用户滚动时（至少使用现代互联网连接速度）。页面load事件在所有急切加载的图像完成后触发，但可能/应该在延迟加载的图像开始之前触发，因此这是我们触发折叠下方加载的机会。

一个已知的缺点是，延迟加载的图像可能会在用户滚动时导致布局发生变化，因为浏览器在图像开始加载之前不知道尺寸。另一个缺点是，用户可能会对滚动到图像时尚未加载的图像感到恼火。该解决方案通过在加载优先级图像后立即转换剩余的延迟加载图像来解决这两个问题eager，以减少用户遇到这些问题的机会。

还有一种可能是，在某些特定情况下，JavaScript 片段正在等待图像加载以便对其执行某些操作，这有时会阻止渲染。让我们把它当作一个次要问题。我认为我们不太可能在这个网站上遇到这种情况，我们会在出现问题的地方修复它。

附注，我还设计了一个脚本，用于观察外部脚本在 DOM 上填充或操作的元素，并将任何新添加的img元素转换为loading="lazy"（如果它发生在页面加载之前），因此我能够保证延迟加载img页面上的所有元素，它确实使 Lighthouse 加载性能提高了几个点。

到目前为止，我还没有发现延迟加载页面上的每个或大多数图像带来的许多严重和/或可能的问题，因为它是用我设计的策略来处理的。

我的问题是我错过了什么。这个策略会不会有漏洞？

我还需要考虑哪些其他因素？因为我不希望我的决定给我正在工作的网站带来问题。

Answer 1

如果您从未使用过浏览器本机延迟加载，您可能不知道的是，它不一定会改善较短页面上的初始加载大小/时间，因为即使在事件发生之前，它仍然会启动加载距离视口小于 3000 像素的任何内容window load火灾。这才算是太急切了。

有关此问题的信息：https://calendar.perfplanet.com/2019/native-image-lazy-loading-in-chrome-is-way-too-eager

这使得它对于较短页面的 Google Lighthouse 性能指标毫无用处。

因此，我们正在实现老式的非本机延迟加载，我们可以通过 JavaScript 进行完全控制。我们的图像服务如下：

<img data-src="some-image.src" />
<noscript>
    <img src="some-image.src" />
</noscript>

...并且使用与原始问题中描述的类似的 JavaScript 策略，除了交换Image.dataset.src到Image.src属性的常用技术之外，或者我们许多使用lazySizes。

但我对浏览器本机延迟加载的功能一无所知。特别是，为什么浏览器不会优先考虑折叠上方的惰性图像而不是折叠下方的惰性图像，并且不会加载折叠下方的任何惰性图像或触发事件，load直到所有内容都加载到折叠上方。

我不明白为什么不能用 CSS 设置延迟加载。如果我们能够仅通过 CSS 选择器将加载属性应用到页面的各个部分，那就太好了。相反，我们被迫使用 JavaScript 或在服务器上处理它。使用 CSS 就可以像loading: lazy;.

我将调查这些想法是否在任何地方提出。我也可能会发布我们最后使用的代码。