白屏时间长主因是资源加载阻塞或渲染逻辑混乱，需控制HTML解析流、预加载关键资源、避免主线程卡顿；首屏CSS内联、JS用defer/async、字体图片preload；服务端流式输出骨架HTML；第三方脚本异步延迟加载；监控聚焦FP/FCP而非仅LCP。
白屏时间长，通常不是因为网络慢，而是资源加载阻塞或渲染逻辑没理清。关键在控制 HTML 解析流、提前触发关键资源获取、避免主线程卡顿。
关键资源必须内联或预加载
浏览器遇到 <script></script> 或未优化的 <link rel="stylesheet"> 会暂停 HTML 解析，导致白屏延长。首屏依赖的 CSS 和 JS 必须优先保障。
- 首屏所需 CSS 提取为内联样式，用
<style></style>放在中；非首屏 CSS 用rel="preload"+onload动态插入 - JS 脚本按需加
defer（DOM 构建完成后执行）或async（下载不阻塞，但执行时机不可控），禁止在中使用同步<script></script> - 字体、关键图片可加
<link rel="preload" as="font">或as="image"，避免 FOIT/FOUT 前的空白等待
<head> <style>/** 首屏 CSS 内联 **/</style> <link rel="preload" href="fonts/inter.woff2" as="font" type="font/woff2" crossorigin> <link rel="preload" href="logo.png" as="image"> </head>
服务端要输出有意义的首帧 HTML
不要等所有数据就绪再吐 HTML。服务端应尽快返回带骨架结构的 HTML，哪怕内容是占位符，也能触发浏览器解析和资源发现。
- Node.js / PHP / Java 后端开启流式响应（streaming response），在
开始后立即 flush 骨架 DOM - 避免在服务端模板中做耗时计算（如复杂 JSON 序列化、未缓存的数据聚合）
- 首屏数据尽量随 HTML 一起注入
window.__INITIAL_DATA__，减少客户端首次 API 请求
避免 render-blocking 的第三方脚本
统计、广告、客服 SDK 是白屏延长的常见元凶。它们往往同步加载、自执行、还附带额外请求。
立即学习“前端免费学习笔记（深入）”；
- 所有第三方脚本默认用
async，且延迟到DOMContentLoaded后再加载（例如通过setTimeout(..., 0)或requestIdleCallback） - 用
iframe加载非核心第三方（如评论框、嵌入视频），隔离其资源竞争和 JS 执行影响 - 检查是否误用了
document.write()—— 现代浏览器中它会清空整个文档，直接造成白屏重绘
<script async src="https://cdn.example.com/analytics.js"></script>
<script>
// 延迟加载客服 SDK
document.addEventListener('DOMContentLoaded', () => {
const script = document.createElement('script');
script.src = 'https://widget.chat.com/sdk.js';
script.async = true;
document.head.appendChild(script);
});
</script>监控不能只看 LCP，得盯住 FP 和 FCP
LCP（最大内容绘制）反映的是“内容填满”的时间，但用户感知白屏的核心指标是 FP（首次绘制）和 FCP（首次内容绘制）。很多优化后 LCP 没变，但 FP 缩短了 300ms，用户明显感觉“快了”。
- 用
performance.getEntriesByType('navigation')[0]查firstPaint和firstContentfulPaint - Chrome DevTools 的
Performance面板开启Paint记录，确认白屏结束点是否与首帧渲染对齐 - 真实设备上测试：低端安卓机的 JS 解析和布局耗时可能是桌面端的 3–5 倍，仅靠 localhost 测不出问题
真正难的不是加 preload 或删 document.write，而是判断哪些资源“算首屏”、哪些 JS “真能 defer”。每个页面的临界路径不同，得结合 coverage 面板和 waterfall 图动手切一次才知道。
