提示

预加载在资源的普通消费者发现它之前，先告诉浏览器这个资源可能很快需要使用。由 JavaScript 创建的图片，或必须等样式表加载并解析后才发现的字体，都可能因此更早开始获取。它提供的是提前下载的机会，不能推导成所有提示资源都获得全局最高优先级，更不能保证添加之后每个页面都一定变快。 发现、获取与使用是三个阶段 现代浏览器通常能够提前扫描 HTML 中的资源，因此图片写在后面，不代表必须等主解析器逐行走到那里才开始发现；图片位于首屏之外，也不直接证明发现时间很晚。添加提示之前，应查看真实请求发起者和时间。如果资源原本就及时开始获取，额外提示可能收益很小，却与更重要的工作竞争带宽。 rel=preload 且 as=image 的 link 被处理时，会按图片目的发起获取，但不会自动插入 img 元素。同样，预加载样式表不等于应用样式，预加载脚本也不会自动执行脚本。实际消费者仍需要通过正常机制请求或使用该资源。下载提前了，却没有后续使用，只会增加开销，不能算作页面已经完成渲染。 复用依赖请求信息兼容。地址、as 表达的资源用途，以及相关的 CORS 和凭据模式，需要与最终消费者一致。字体预加载通常即使位于同源，也要配置 crossorigin，使模式匹配实际字体请求。media 适合控制条件加载，却不是每一个字体提示都必填的属性。响应式图片还需要匹配真实选择结果，不能仅凭猜测预加载最大的一张，然后假定浏览器肯定使用它。 坏掉的样子 设计调整后，旧提示很容易留下来：页面已经移除主图，head 中的 preload 却继续下载。另一个常见问题是消费者使用不同查询参数或请求模式，导致原本期待的复用没有发生。检查时既要数请求，也要核对最终真正使用的地址。图片能够显示，只说明某次加载成功，不能证明提前下载的那份资源被复用了。 预加载过多资源，还会竞争带宽、连接和处理能力。提前发现不是暂停浏览器其他优先级规则的命令。对可选交互资源的提示，也可能让从不点击该控件的用户承担流量成本。应明确这笔取舍，并在真实受众的测试中移除成本高于收益的提示，而不是把所有资产都提前下载当作默认优化。 很快的本地实验不能建立最大内容绘制或真实响应速度已经改善的结论。性能比较需要页面、缓存状态、设备和网络条件具备可比性。资源时间记录能够说明请求何时开始，但不能单独解释整个用户体验变化，更不能把两次非受控访问的耗时差全归因于一个属性。 快速验证 把下面代码保存为 preload-image.py，使用 Python 3 执行 python3 preload-image.py。命令通过 HTTP 检查三个页面变体和一张图片的可达性，并明确输出 browser_preload_tested_by_cli 为假。服务端检查 HTML 字符串，并没有运行浏览器的资源调度过程，不能据此宣称预加载已经发生。 ...