首屏白屏时间长主因是html解析被同步或阻塞；用chrome devtools performance面板看parse html后是否紧接recalculate style/layout，network面板中initiator为parser的css/js即关键阻塞源。
首屏白屏时间长，八成是 HTML 解析被某个 <link rel="stylesheet"> 或同步 <script></script> 卡死了——不是资源没传完，而是浏览器在等它“放行”才敢继续画。
怎么一眼识别哪个资源在阻塞首屏渲染
打开 Chrome DevTools → Performance 面板 → 录制一次完整加载，重点看 Parse HTML 后是否立刻接上长时间的 Recalculate Style 或 Layout；再切到 Network 面板，筛选 css 和 js，检查 Initiator 列：
- 显示为
parser：该资源是在 HTML 解析中途被同步拉取的，属于关键阻塞点 - 显示为
script或other：大概率是异步加载，不拖首屏 - 哪怕 CSS 已下载完成，只要没解析出 CSSOM，
FCP就不会触发
内联关键 CSS 为什么必须做，又为什么不能乱内联
浏览器遇到 <link rel="stylesheet"> 就会暂停 DOM 构建，等 CSS 下载 + 解析完才继续。内联进 <style></style> 能跳过网络请求，让 DOM 和 CSSOM 并行构建——但前提是只塞「首屏像素生成所需最小集合」：
- 登录页只需
.logo、.login-form、.submit-btn的基础尺寸与颜色，响应式断点、动画、主题色全扔外部文件 - 体积控制在 ~1KB 内：超了会显著拖慢 TTFB（尤其弱网），还可能因 TCP 初始拥塞窗口限制多一个 RTT
- 服务端无法缓存内联样式，每次 HTML 更新都得重传全部内容
- 别手写提取——用
critters或purgecss + html-webpack-plugin自动分析真实首屏用到的选择器
<link rel="preload"> 加了却没加速？可能是用错了地方
<link rel="preload"> 不改变阻塞行为，只提前拉取资源。它生效的前提是「精准命中首屏必用」且「后续真用了」：
- 对首屏 Hero 图或关键字体用：
<link rel="preload" href="hero.jpg" as="image">，注意as属性必须准确，否则浏览器无法设置正确请求头 - 非关键 CSS 可这样异步加载：
<link rel="preload" as="style" href="non-critical.css" onload="this.onload=null;this.rel='stylesheet'"> - 别对
main.js或整个vendor.jspreload——它已被defer覆盖，再 preload 属于冗余调度，反而抢带宽 - 没实际使用预加载资源时，Chrome 会报警告：
"The resource … was preloaded using link preload but not used within a few seconds"
为什么把 <script></script> 放
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
