>图像不会阻止初始渲染。 我相信这基本上是正确的。 这意味着从网络请求/下载图像不会在主线程上发生。 我假设解码/栅格化图像也发生在某些浏览器的主线程之外(但我可能是错的(。
我经常听到人们简单地说"让图像在后台下载"。 但是，仅使用此信息进行下一个合理步骤时，在查看"交互时间"或"首次有意义的绘制时间"时，图像对 Web 应用的性能的影响应为 0。根据我的经验，事实并非如此。通过在图像繁重的页面上延迟加载图像(使用 IntersectionObserver(与"只是让它们在后台下载"相比，性能提高了 2-4 秒。
加载网页时，解码/绘制图像的哪些特定浏览器内部/步骤会导致性能下降？ 哪些步骤从主线程获取资源？
这有点宽泛，有很多事情会影响页面的其余部分，并且都取决于许多不同的因素。
网络请求不由 CPU 处理，因此此处不应有开销。
解析元数据取决于实现，可以使用相同的过程或一些专用过程，但通常这不是一个繁重的调用。
解码图像数据和光栅化也依赖于实现，一些浏览器会在获取数据时直接执行此操作，而其他浏览器会等到真正需要执行此操作时，尽管有一些方法可以确保同步完成(在同一线程上(。
绘制图像可能是硬件加速的(在 GPU 上完成(或由软件(在 CPU 上完成的(，在这种情况下，这可能会影响一般性能，但现代渲染器可能会丢弃不在当前视口中的图像。
最后，让您的<img>元素按其内容调整大小将导致页面完全重排。在网页中加载图像时，这通常是最显着的性能影响，因此请确保通过CSS设置图像的大小以防止重排。