preload本质是声明式提示而非定时器，必须置于<head>中<meta charset>和<title>之后、首个阻塞资源之前，且as属性需精准匹配资源类型（如font需加crossorigin），否则降级为普通fetch；验证需看Network面板Initiator为preload、Priority为Highest/High、请求时间早于自然发现且复用缓存。
没有通用的“提前量算法”——浏览器不接受毫秒级调度指令，preload 的本质是声明式提示，不是定时器。 你没法告诉浏览器“请在解析到第 327 行前 48ms 发起请求”，它只认 HTML 结构位置和资源类型。所谓“提前量”，实际是开发者对解析流、渲染关键路径和网络延迟的经验建模，落地靠的是 preload 的插入时机与 as 值的精准匹配。
preload 必须出现在 <head> 中的什么位置才真正“提前”
浏览器只在初始 HTML 解析阶段（parser phase）读取 <link rel="preload">，一旦开始构建 DOM 树或遇到阻塞脚本，就不再处理新的 preload 指令。
-
<meta charset>和<title>之后、第一个<link rel="stylesheet">或<script>之前 —— 这是唯一能确保它被最早触发的位置 - 放在
<body>里？完全无效，解析器已离开 head 阶段 - 用 JS 动态插入：
document.head.appendChild()？同样无效，此时 parser 早已结束，只剩 DOM API 执行阶段 - 构建工具自动生成时，必须验证最终 HTML 中该标签是否落在上述黄金区间，否则等于没写
as 属性写错等于没写，甚至更糟
浏览器靠 as 值决定请求头、CORS 策略、缓存复用逻辑和优先级。漏写或错写，preload 就会降级为普通 fetch，失去高优调度能力。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 字体必须写
as="font"+crossorigin：WOFF2 同源也强制要求crossorigin，否则 Chrome 静默丢弃，控制台无报错 - CSS 必须写
as="style"：写成as="fetch"或不写，会导致与后续<link rel="stylesheet">重复下载，Network 面板里能看到两个同名请求 - 图片用
as="image"，配合media可条件触发，比如<link rel="preload" href="hero.webp" as="image" media="(min-width: 768px)"> - JS 用
as="script"，但注意：它只下载，不执行；若后续<script src="app.js">没加async或defer，仍可能因阻塞解析导致重复请求
怎么验证 preload 是否真生效，而不是“看起来写了”
别信代码存在，要信 Network 面板里的真实行为。几个关键信号缺一不可：
立即学习“前端免费学习笔记（深入）”；
-
Initiator列显示为preload，不是parser或script -
Priority列是Highest（字体、首屏图）或High（CSS、JS），不是Low或空白 - 请求时间戳明显早于对应资源的首次自然发现时间（比如
main.css的 preload 请求比<link rel="stylesheet">触发早 300ms+） - 同一资源在后续
<link rel="stylesheet">或@font-face中被复用：查看响应头X-Cache: HIT或 DevTools 的 “Size” 列显示from memory cache - 如果看到状态是
cancelled，大概率是用户跳走了；如果是net::ERR_FAILED，检查href路径是否拼错、服务是否返回 404
真正难的不是写对一行 <link rel="preload">，而是判断哪个资源“当前页面马上就要用”——这需要你亲手跑一遍 Lighthouse 的 Performance 报告，盯着 Waterfall 图看哪一帧卡住了渲染，再逆向定位到那个没及时加载的字体或 CSS。所有“算法”都得从这里开始，而不是从公式出发。
