rel="preload"仅预加载CSS而不解析应用，故不改善LCP；需搭配onload切换rel属性、关键样式内联及noscript降级才能真正优化首屏性能。
rel="preload" 本身不能异步加载 CSS，它只负责提前下载；真正实现“不阻塞首屏”的关键是：用 preload 下载 + onload 动态切换 rel 属性 + 关键样式内联。
为什么 rel="preload" 单独写不会改善 LCP
浏览器遇到 <link rel="preload" href="non-critical.css" as="style"> 时，只会高优先级下载文件，但完全不解析、不应用——它压根不是样式表，LCP 元素（比如标题、大图）根本不会等它，也不会受它影响。如果你只写了这一行，CSS 就永远“躺在内存里”，页面样式会直接缺失。
常见错误现象：
- 页面加载后文字无颜色、布局错乱，检查 Network 面板发现
non-critical.css已下载完成但未触发解析 - 误以为加了
preload就等于“异步”，结果 LCP 毫无变化，甚至因抢占带宽而变差
必须搭配 onload 才能生效，且顺序不能错
要让预加载的 CSS 真正起作用，必须在下载完成后手动把它变成可解析的样式表。最稳妥写法是内联 onload 回调，并立即清除自身引用：
立即学习“前端免费学习笔记（深入）”；
<link rel="preload" href="non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
为什么强调 this.onload=null 必须写在最前：
- Chrome/Safari 在某些缓存复用场景下会重复触发
onload，导致rel被反复设为stylesheet，可能引发样式闪烁或计算异常 - 不写这句，
onload可能在后续 DOM 操作中被再次调用（尤其配合 PWA 或 Service Worker 时） - 避免调用外部函数（如
loadCSS()），减少执行延迟和作用域污染风险
非关键 CSS 里藏着的坑比你想象的多
即使你成功用 preload + onload 延迟挂载了样式表，如果它内部包含以下内容，照样会拖慢 LCP：
-
@import规则：会同步阻塞该 CSS 的解析，形成隐蔽二级阻塞链 -
@font-face引用未预加载的大字体（如 2MB woff2），字体下载会在样式挂载后才启动，卡住文本类 LCP 元素 -
background-image指向高延迟 CDN 图片，图片拉取挤占首屏资源带宽
建议操作：
- 用 Chrome DevTools 的 Coverage 面板检查
non-critical.css中实际用到的规则，删掉冗余部分 - 若必须含字体，改用
font-display: optional并单独<link rel="preload" as="font"> - 图片资源统一加
loading="lazy"或用占位符，避免样式挂载后立刻触发大量请求
别忘了 <noscript> 降级和关键 CSS 内联
JS 被禁用时，onload 完全失效。没有降级方案，用户看到的就是无样式的白屏或错乱页：
<link rel="preload" href="non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'"><br><noscript><link rel="stylesheet" href="non-critical.css"></noscript>
更重要的是：LCP 是否达标，不取决于“非关键 CSS 多晚加载”，而取决于“关键样式是否在首次绘制前就位”。所以：
- 把首屏必需的
font-family、color、max-width、margin等控制视觉结构的规则，内联进<head><style>，体积控制在 2–3KB 内 - 服务端渲染（SSR）场景下，需确保服务端已输出这些内联样式，客户端 JS 不再重复注入
- 测试时务必勾选 DevTools 的 “Disable cache” 并硬刷新，否则本地缓存会让
preload表现失真
真正卡住 LCP 的，从来不是“怎么延迟加载非关键 CSS”，而是“有没有把关键样式提前塞进 HTML 里”。preload 只是搬运工，内联才是保险栓。
