preload失效主因是未严格匹配as属性、缺失crossorigin、或未将资源接入渲染流程，如字体需as="font"+crossorigin，CSS需onload切换rel，否则仅下载不生效。
为什么加了 preload 字体还是闪、CSS 还是晚？
因为 preload 不是“加了就生效”，它只改变资源开始下载的时间点，不解决加载逻辑错配问题。最常见失效场景是：漏写 as、没配 crossorigin、或 preload 后没把资源真正接入渲染流程。
比如字体：必须同时满足 as="font" + crossorigin，否则浏览器会拒绝应用；CSS 则需在 onload 中改 rel，否则预加载完也不会参与 CSSOM 构建：
<link rel="preload" href="fonts/Lato.woff2" as="font" type="font/woff2" crossorigin> <link rel="preload" href="css/critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
-
as错写成as="font/woff2"或直接省略 → 浏览器当普通 fetch 处理，Priority 降为 low - 同域字体也建议加
crossorigin—— Chrome 120+ 已默认启用 CORS 检查 - CSS 的
onload必须手动切换rel，否则预加载只是“下完放着”，不触发解析
preload 和 prefetch 混用时谁抢带宽？
答案是 preload 一定赢，但它赢错地方就会拖垮首屏。Chrome 中 preload 请求 Priority 显示为 high，prefetch 是 low，两者不在同一调度队列里。
问题出在误用：把本该 prefetch 的下一页 JS（如 detail.js）写成 preload，浏览器会在当前页就抢占连接和带宽，挤掉 critical.css 或首屏图片的下载机会。
立即学习“前端免费学习笔记（深入）”；
- 验证方式：打开 Chrome DevTools → Network 面板 → 查看每项请求的 Priority 列
- 正确分工：
preload只用于当前导航中「HTML 解析过程中发现太晚」的资源（如 CSS 里引用的字体、JS 动态 import 的模块） -
prefetch适合用户行为可预测的场景，比如首页点击「商品列表」后大概率进详情页，才 prefetchdetail.js
内联 CSS 的临界值到底是多少？
不是固定 KB 数，而是「首次渲染收益」与「HTML 体积惩罚」的平衡点。实测显示：超过 10KB 的内联 CSS 会让 HTML 响应体显著增大，TTFB（Time to First Byte）延迟上升，反而抵消 FCP 提前的优势。
更关键的是内容性质：含 @import 的 CSS 即使只有 5KB 也不该内联，因为浏览器仍需发起新请求；而纯声明式规则（无变量、无嵌套）的 9KB critical CSS 内联后，FCP 可快 200ms+。
- 工具推荐：
critters（Vite/Webpack）自动提取并内联首屏 CSS，比手写更准 - 禁止内联含
@import的文件 —— 它违背内联初衷，且现代构建工具已能自动展开 - 内联后务必删掉对应外部
<link rel="stylesheet">，否则 CSSOM 会重复构建
script 放 <head> 还是 <body> 底部？
都不绝对。关键是看依赖关系和执行时机：同步脚本放哪都阻塞，但 defer 脚本放 <head> 反而更优 —— 它能和 HTML 解析并行下载，且保证按顺序执行、DOM 就绪后立即运行。
而 async 脚本（如统计代码）放 <head> 更合适，因为它不依赖 DOM，越早下载完越早执行，不影响主流程。
- 避免把
defer脚本放<body>底部 —— 下载启动晚，失去并行优势 - 禁用
document.write()：现代浏览器中它会清空整个文档流，不可恢复 - 第三方 SDK（如埋点、客服）建议动态
import()，首次交互或页面可见（IntersectionObserver）后再加载
最容易被忽略的其实是资源类型与 as 的严格匹配 —— 写错一个字母，preload 就退化成普通请求；还有就是把“能预加载”当成“该预加载”，结果带宽被无效资源占满，首屏反而更慢。
