nginx通过add_header link指令在https+http/2环境下为关键静态资源添加rel=preload，需指定绝对路径、精准as类型（如style/script/font），并避免误用于非html响应或无效路径。
可以通过 Nginx 的 add_header 指令配合 HTTP/2 的 Link 响应头，为关键静态资源（如字体、关键 CSS、JS）添加 preload 提示，让浏览器在 HTML 解析早期就发起请求，提升加载优先级。
配置 Link 预加载头
Nginx 本身不解析 HTML 或自动识别资源依赖，需手动指定要预加载的资源路径。推荐在 server 或 location 块中使用 add_header 添加标准 Link 头：
- 语法格式：
add_header Link "<url>"; rel="preload"; as="type";</url> -
as属性必须准确填写资源类型（如font、style、script、image），否则浏览器可能忽略或降级处理 - 确保 Nginx 启用了 HTTP/2（
listen 443 ssl http2;），因为Link头在 HTTP/1.1 中支持有限，且部分浏览器仅在 HTTP/2 下可靠生效
按资源类型精准设置 as 值
不同资源对应不同的 as 值，错误值会导致 preload 失效或触发安全警告：
- CSS 文件：
as="style"（例如add_header Link "/main.css>; rel="preload"; as="style";";） - 关键 JS：
as="script" - Web 字体（WOFF2 等）：
as="font"，并务必添加crossorigin（字体跨域需匿名请求）：rel="preload" as="font" crossorigin - 首屏图片：
as="image"，但注意避免对非关键图盲目 preload，可能挤占带宽
避免常见陷阱
预加载不是“越多越好”，配置不当反而拖慢页面：
- 不要对所有静态资源统一 preload —— 只针对渲染阻塞、体积大、发现时机晚的关键资源（如字体、核心 CSS）
- 确保预加载路径与实际资源路径完全一致（含协议、域名、路径大小写），Nginx 不会自动重写或校验
- 避免在非 HTML 响应（如 API 接口、图片返回）中误加 Link 头，可能引发客户端解析异常
- 若使用 CDN 或反向代理，确认中间层未过滤或覆盖
Link头（部分 CDN 默认 strip 自定义 header）
验证是否生效
部署后可通过浏览器开发者工具验证：
- 打开 Network 标签页，选中 HTML 请求，查看 Response Headers 中是否存在
Link字段 - 在 Timing 或 Initiator 列观察预加载资源是否出现在 HTML 解析完成前（Initiator 显示
preload） - 检查 Console 是否有警告，如
Failed to find a valid digest in the 'integrity' attribute（若启用了 SRI 但未配 integrity）或Invalid as value
