图片

懒加载把暂时用不到的工作推迟到更合适的时机。对于 HTML 图片，loading="lazy" 允许浏览器按照自己的策略，等图片接近视口时再发起请求。长文章因此可能减少初始传输量，但这个属性只是调度输入，并不保证每一张尚未进入屏幕的图片都绝对不会下载。能否节省请求，需要观察实际浏览器行为。 让浏览器调度普通图片 原生方式直接使用真实的 src 或 srcset，不必把地址隐藏在自定义属性里，也不必仅为基础懒加载编写滚动处理器。加载距离由浏览器决定，还可能随实现及连接条件调整。作者不能通过 loading 属性直接配置原生距离阈值。使用 IntersectionObserver 的应用方案有另一套控制方式，同时也增加了程序需要承担的调度和兼容责任。 首屏必需的图片应保持及时加载，尤其是主要展示图。如果对决定最大可见内容的图片使用延迟加载，真正有用的画面可能更晚出现。反过来，为刻意延迟的图片添加 preload，也可能提前触发下载，抵消预期节省。应根据图片角色和实测结果选择，而不是给页面所有资源统一贴上同一种策略。 明确填写图片原始 width 和 height，可以让浏览器在下载之前预留宽高比例。响应式样式仍然能够缩小实际宽度，并自动保持高度比例。缺少有效尺寸时，图片最初可能几乎不占空间，既影响哪些内容被认为接近视口，也可能在图片到达后把正文突然推开。图片无法显示时，准确的替代文字仍然是阅读体验的一部分，不能只顾请求数量。 坏掉的样子 只等页面 load 事件结束，可能漏掉尚未完成的懒加载图片。浏览器可以在远处图片未下载完时结束页面加载事件，因此应分别检查图片完成状态、自然尺寸、服务端请求及滚动后的真实显示。请求已经失败与请求尚未开始是不同状态；两者最初都可能没有解码后的像素，不能只凭一项尺寸判断根因。 没有编写页面脚本，不等于在浏览器中禁用了脚本。MDN 说明，作为防跟踪措施，图片的这种延迟行为需要浏览器启用脚本。普通静态 HTML 无须额外编写 JavaScript 就可以使用，但把浏览器脚本整体关闭之后，不能继续假定请求时机完全相同。应按站点实际支持的环境验证，不宣称所有配置都能获得一样的节省。 loading 属性只作用于支持它的元素，不能直接控制任意 CSS 背景图。content-visibility 主要用于跳过部分渲染工作，也不承诺相关网络请求全部延后。快速滚动与慢连接组合时，原生调度仍可能来不及让图片及时到达。评估中需要查看空白占位持续多久以及布局是否稳定，不能把初始请求减少当成用户体验必然改善。 快速验证 将下面代码保存为 lazy-images.py，运行 python3 lazy-images.py。Python 3 命令验证本地页面和两张图片都能返回成功响应，但输出中的 native_loading_tested_by_cli 明确为假。普通 HTTP 客户端读取 HTML，并不会执行浏览器图片调度器，因此该命令本身不能证明已经发生原生懒加载。 ...