摘要

  • W3C 在 2013 年的 Resource Priorities 草案中提出 lazyload 和 postpone 等优先级线索；2014 年的工作组说明则明确宣布停止维护、放弃该规范。
  • 后来的 WICG Priority Hints 文件因相关内容并入 HTML 和 Fetch 而退出舞台。现行 fetchpriority 用 high、low、auto 表达同类目标资源之间的相对轻重，Fetch 另为浏览器保留内部优先级。

打开一篇报道时，首屏大图可能就是故事的门面；页面底部的花边图片晚到一会儿，通常没人敲桌子。可浏览器面对的最初只是一批请求。它知道连接状况，也知道机器还能忙到什么程度，却未必知道编辑把哪张图放在标题旁边的用意。网页作者知道内容的主次，却看不到读者此刻的完整执行环境。所谓优先级提示，正是在这两种知识之间开一条窄缝。

W3C 2013 年 10 月 29 日首份公开工作草案把问题叫作 Resource Priorities。草案认为，按文档顺序下载未必符合页面的感知价值，于是提出 lazyload、postpone 和一个 CSS 属性，让作者向用户代理传递资源轻重。其中 lazyload 面向资源紧张时的低优先级处理，postpone 则涉及元素进入或接近视口之前暂缓下载。它是一份提案，不是一张证明当年浏览器普遍照办的验收单。

一份标准草案也会被自己的机构叫停。W3C 2014 年 10 月 23 日工作组说明开门见山：该规范不再维护，工作组已放弃它，并建议读者转看 resource hints。2014 年文本仍讨论 lazyload，2013 年的 postpone 专节已不在。旧草案与今天的 fetchpriority 不能当作同一张说明书。它们面对相似的排队难题，但公开记录没有给出一条从旧属性直通新属性的实施血统。

再看另一条文件线索。WICG 2023 年 2 月 22 日的 Priority Hints 报告将开发者给浏览器的信号描述为“相对优先级”。该页面如今也标着过时，原因却不同：相关规范文字已经并入 HTML 和 Fetch。WICG 的孵化稿退场，核心规则进入持续更新的标准文本。两个“过时”放在一起，恰好说明互联网历史里同一个墓碑词可以指两种结局：一份工作停了，另一份工作换了住址。

现行 HTML 标准把 fetchpriority 的取值列为 high、low、auto。这里的高低，是与目标类型相同的其他资源相比；缺省值或无效值都归为 auto。这个限定很容易被“加急”二字盖过去。网页作者能对同一类请求表达相对轻重，却不能靠一段标记给全站所有下载发放头等舱机票。

Fetch 标准把分工写得更清楚：请求有 high、low 或 auto 的优先级，也有一个单独的内部优先级，后者可以是实现自行定义的对象。编辑知道照片的重要性；浏览器仍有自己的账本。网络拥挤、设备忙碌、不同请求互相争抢时，这个账本决定便条怎样落地。

所以，给报道主图标一个较高的提示，是把编辑意图送进调度过程；给所有图片都标高，则像全班同学同时举手喊“我先来”。这些标准文件定义了信号及其边界，并未给出某个网站提速多少的实测结论。真正值得记住的设计，是让网页说出自己知道的事，同时让承担下载代价的浏览器继续掌握队伍。