浏览器必须等所有已声明的CSSOM构建完成才能绘制第一帧，因<link>阻塞渲染且默认media="all"，@import更因串行加载拖慢FCP 300ms+；内联仅限首屏关键CSS（如.hero、.nav），需工具提取并验证覆盖，禁用document.write，defer脚本解耦执行，preload仅限当前页确定资源。
head里为什么会让首屏白屏
浏览器必须等所有已声明的 CSSOM 构建完成，才能开始绘制第一帧。哪怕只有一行 <link rel="stylesheet" href="main.css"> 在 <head> 里，而该文件加载慢或服务器响应延迟，整个页面就卡在白屏——DOM 可能早已解析完，但渲染树（Render Tree）拼不出来。
常见错误现象包括：LCP 指标差、3G 网络下首屏延迟超 3 秒、Chrome DevTools 的 Waterfall 中看到 HTML 解析完成后长时间空转。
-
@import更危险：它在 CSS 文件内串行加载，比<link>多一次网络往返，实测拖慢 FCP 300ms+ - 不加
media属性时，默认media="all"，强制参与当前渲染树构建 - 用
<link rel="stylesheet" media="print" onload="this.media='all'">延迟非关键 CSS，避免阻塞初始渲染
首屏 CSS 内联不是复制粘贴，而是提取+验证
内联目标是让浏览器不用发请求就能构建 CSSOM，但手动把整份 main.css 塞进 <style> 是典型假优化：体积暴涨、无法缓存、后续更新不同步。
真正有效的做法是只提取“首屏可见区域”所需样式，比如 .hero、.nav、.cta-button、字体定义等，通常控制在 10–14KB 内（HTTP/2 帧大小限制）。
立即学习“前端免费学习笔记（深入）”；
- 用工具自动化提取：
critters（Webpack/Vite）、penthouse（配合 Puppeteer 截图分析） - 内联后务必禁用缓存刷新页面，用 DevTools 的 Coverage 面板验证是否真覆盖首屏
- 别把
.modal、.footer或暗色模式相关规则塞进去——它们不属于首屏渲染路径
script 标签放哪儿，关键看有没有 defer
把 <script src="app.js"></script> 放到 </body> 前只是兜底方案，下载阶段仍会阻塞 HTML 解析；真正解耦下载与执行，靠的是属性。
同步脚本（无 async 或 defer）在弱网下尤其致命：HTML 解析停摆 → 下载 JS → 执行 JS → 继续解析 → 用户看到白屏。
- 业务主逻辑 JS 必须用
defer：下载异步，执行时机在 DOM 解析完成后、DOMContentLoaded前，且按书写顺序执行 - 统计类、广告脚本可用
async：下载不阻塞，但执行时机不可控，适合无依赖逻辑 - 绝对禁用
document.write()：现代浏览器已废弃，执行即清空文档流，本地双击打开 HTML 时尤其敏感
preload 加错位置，反而抢带宽拖慢首屏
<link rel="preload"> 是高优先级资源提示，不是“提前加载所有东西”的开关。它只对当前导航中「确定马上要用」的资源生效。
写错最常见后果：关键 CSS 或 HTML 本身被挤出首屏带宽，Network 面板里看到 Priority: high 的图片或字体占满连接，而 index.html transfer size 却排在后面。
- 只对首屏 Hero 图、关键 Web Font（
as="font"+ 必须加crossorigin）、或立刻要import()的模块预加载 - 别
preload普通图片：多数由 CSS 或 JS 控制展示时机，提前加载反而浪费 -
preload和prefetch别混：前者是当前页用（Priority: high），后者是下一页可能用（Priority: low）
defer 的脚本、一行漏掉 media 的 <link>、或一段手撸却漏了 .hero img 宽高的内联 CSS，都足以让 FCP 推迟 300ms 以上。这些不是“配置项”，而是渲染路径上的硬性关卡。 
