17370845950

白屏时间长主因是资源加载阻塞或渲染逻辑混乱，需控制HTML解析流、预加载关键资源、避免主线程卡顿；首屏CSS内联、JS用defer/async、字体图片preload；服务端流式输出骨架HTML；第三方脚本异步延迟加载；监控聚焦FP/FCP而非仅LCP。

白屏时间长，通常不是因为网络慢，而是资源加载阻塞或渲染逻辑没理清。关键在控制 HTML 解析流、提前触发关键资源获取、避免主线程卡顿。

关键资源必须内联或预加载

浏览器遇到 或未优化的 会暂停 HTML 解析，导致白屏延长。首屏依赖的 CSS 和 JS 必须优先保障。

• 首屏所需 CSS 提取为内联样式，用 放在 中；非首屏 CSS 用 rel="preload" + onload 动态插入
• JS 脚本按需加 defer（DOM 构建完成后执行）或 async（下载不阻塞，但执行时机不可控），禁止在 中使用同步
• 字体、关键图片可加 或 as="image"，避免 FOIT/FOUT 前的空白等待

服务端要输出有意义的首帧 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() —— 现代浏览器中它会清空整个文档，直接造成白屏重绘

监控不能只看 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 图动手切一次才知道。