关键CSS必须内联或预加载，否则LCP被阻塞；浏览器需先完成CSSOM构建才能渲染首屏，未优化的CSS文件可使LCP推迟1.8秒以上。
因为浏览器必须等关键CSS解析完才能开始渲染首屏内容，不优先加载，LCP就卡在白屏阶段。
关键CSS不内联或不预加载，LCP直接被阻塞
浏览器遇到 <link rel="stylesheet"> 会暂停HTML解析，同步下载并构建CSSOM；如果这个CSS文件体积大、延迟高，整个首屏渲染就被挂起。LCP元素（比如 <img class="hero-banner"> 或 <h1>）哪怕已下载完成，也得等CSSOM就绪才能绘制——这期间用户看到的是空白或闪烁的回退字体。
- 实测中，一个未优化的 120KB CSS 文件在弱网下可能让 LCP 推迟 1.8 秒以上
- 即使只差几KB，只要它阻塞了
<style>标签之后的第一个<div>，LCP 就无法触发 - Webpack 构建产物里若把所有断点样式打包进单个
main.css，移动端仍要下载全部，哪怕只用到@media (max-width: 768px)部分
内联 vs preload：两种优先加载方式的适用边界
内联关键CSS适用于首屏必需样式极少（< 10KB）且变动不频繁的场景；preload 则适合稍大但确定为LCP必需的CSS文件（如独立的 hero.css）。
- 内联时，把
<style>放在<head>最顶部，确保早于任何<script>或<link> - 用
<link rel="preload" as="style" href="hero.css">替代普通<link rel="stylesheet">，可提前发起请求，但注意：它不会自动执行，仍需配对一个普通<link rel="stylesheet">来应用样式 - 不要对内联CSS再做
preload，无效且浪费HTTP/2流
容易被忽略的CSS阻塞点：@font-face 和 media 查询
这两类声明看似不显眼，却常成为LCP隐形杀手——它们本身不渲染内容，但会拖慢CSSOM构建，间接推迟LCP时间点。
立即学习“前端免费学习笔记（深入）”；
-
@font-face必须写在CSS文件最开头，不能包裹在@media里，否则<link rel="preload" as="font">不生效 - 所有
@media规则（包括未匹配的）都会被浏览器同步解析；把整站断点塞进一个CSS文件，移动端仍要解析全部@media (min-width: 1200px)规则 - 推荐做法：用
<link media="max-width: 768px">让浏览器跳过不匹配的资源加载，而不是靠CSS内部@media控制显示
真正影响LCP的从来不是“有没有响应式”，而是“浏览器要不要为它多等一毫秒”。关键CSS加载策略一旦选错，后续所有图片懒加载、JS分割都救不回那卡住的首屏。
