电商抢购页必须preload的资源只有三类：font.woff2（首屏商品名/价格用）、hero-banner.jpg（lcp图）、countdown.js（倒计时逻辑）；其他非首屏脚本不preload，避免挤占带宽导致css解析延迟。
电商抢购页哪些资源必须 preload？
抢购页的“秒开”不是靠压缩体积，而是让关键资源在 HTML 解析完成前就已下载就绪。真正该 preload 的只有三类：font.woff2（首屏商品名/价格用）、hero-banner.jpg（LCP 图）、countdown.js（倒计时逻辑，非第三方 SDK）。其他如商品列表 JS、评论组件、分享按钮脚本，一律不 preload——它们加载时机晚于用户点击行为，preload 反而挤占带宽。
常见错误是把整个 vendor.bundle.js preload，结果它和 main.css 抢 Highest 优先级，导致 CSS 解析延迟，FCP 推后 400ms+。验证方式：Chrome Network 面板勾选 Priority 列，Initiator 是 preload 且 Priority 显示 Highest 才算生效。
-
as属性必须匹配真实类型：as="font"不能写成as="script"，否则字体不会进字体缓存池 -
crossorigin对字体必填，漏写会导致 Chrome 静默失败（无报错、无请求） - preload 必须放在
<meta charset>和<title></title>之后、对应<link rel="stylesheet">或<script></script>标签之前，否则浏览器跳过
prefetch 该预取哪一页？别预取商品详情页
大促中用户路径极短：首页 → 抢购页 → 支付页。商品详情页（/item/123）95% 用户根本不会点进去——预取它只是浪费带宽。真正该 prefetch 的是 /checkout.html 和 /pay.js，因为用户一旦进入抢购页，下一步大概率就是下单。
注意：prefetch 不会提前触发请求，它只在 window.onload 后空闲时发起，所以即使你写了 <link rel="prefetch" href="/checkout.html" as="document">，Network 面板里也看不到请求，除非你手动勾选 “prefetch” 过滤器，并等页面完全加载完再刷新一次。
- 路径必须是绝对或根相对路径：
/checkout.html✅，./checkout.html❌（子目录下解析失败） - 跨域无效：如果支付页在
https://pay.example.com，当前页在https://www.example.com，prefetch 直接被忽略 - 不要和 preload 写同一个 URL：比如同时
preload和prefetch/pay.js，浏览器会发两次请求，且缓存不共享
fetchpriority="high" 对抢购倒计时图有用吗？
没用。fetchpriority 只对 <img> 和 <iframe></iframe> 生效，且仅 Chromium 119+ 完全支持。抢购页常见的“倒计时数字图”如果是用 Canvas 或 SVG 渲染，加 fetchpriority 完全无效；如果是 <img src="countdown.png">，那它本身已是 eager 加载，fetchpriority="high" 不会再提升优先级——浏览器已把它当 Highest 处理。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
真正要干预的是首屏大图（如 banner），但前提是：src 存在、loading="eager"（不能 lazy）、未被 preload 覆盖。否则 Chrome 会直接忽略该属性。Safari 17.2+ 仅部分支持 <img>，Firefox 完全无视，别指望它跨浏览器生效。
- 不要给
loading="lazy"的图片加fetchpriority="high"：lazy 已强制降为 Low，high 提示被丢弃 -
fetchpriority="low"适合底部“客服入口”小图标，主动让权给倒计时、价格等关键元素 - 验证是否生效：Network 面板 Priority 列显示
Highest或High，不是Medium
为什么抢购页加了 preload 还卡在白屏？
白屏卡点往往不在资源没下载完，而在 CSS 或 JS 执行阻塞渲染。典型情况：你 preload 了 app.js，但它里面包含同步 DOM 操作（如 document.write 或未包裹的 querySelector），浏览器解析完 HTML 后立刻执行，而此时样式还没加载完，导致 layout thrashing。
更隐蔽的问题是 @import：抢购页 CSS 里若存在 @import "theme.css";，浏览器必须串行下载并解析 theme.css 后才能继续构建 CSSOM，哪怕你已 preload 主样式表，整个渲染流程仍被拖住。
- 所有第三方统计脚本必须用
async，禁用document.write - 业务 JS 用
defer，确保执行时机在 DOM 构建完成后 - 移除所有
@import，改用多个<link rel="stylesheet">并行加载 - 首屏 CSS 必须内联（≤10KB），避免额外请求阻塞
最易被忽略的点：preload 只解决“下载快”，不解决“执行快”。抢购页性能瓶颈常在 JS 执行耗时，而非网络延迟。测一下 First Contentful Paint 和 Largest Contentful Paint 的时间差，如果超过 300ms，问题大概率出在 JS 执行阶段，而不是 preload 没写对。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
