白屏时间多久算正常？456数据详解首屏性能阈值与采集
白屏时间多久算正常，不能凭主观感受判断，而应由真实用户度量（RUM）的分位数指标界定。我们依据 web.dev 现行 Core Web Vitals 标准与前端性能监控实践给出明确口径：首次内容绘制（FCP）按 P75 ≤ 1.8 秒为良好，最大内容绘制（LCP）按 P75 ≤ 2.5 秒为良好。
本文从指标定义、浏览器采集原理、实验室与真实用户数据的区别、分位数口径，到边界条件与排查路径，给出一套可直接落地的判断与优化框架。我们面向站长、产品、前端与运营决策者，尽量讲清「为什么是这条线、怎么测准、慢了先查哪」。
一、结论先行：白屏与首屏的官方阈值
web.dev 把「首次内容绘制」（First Contentful Paint，FCP）按真实用户第 75 分位（P75）划分为三档，这也是「白屏时间」对应的核心度量：
| 档位 | FCP（P75） | 含义 |
|---|---|---|
| 良好 Good | ≤ 1.8 秒 | 多数用户在合理时间内看到首屏内容 |
| 待改进 Needs Improvement | 1.8 ～ 3.0 秒 | 一部分用户已感到明显等待 |
| 差 Poor | > 3.0 秒 | 显著影响体验，应优先排期优化 |
与白屏紧密衔接的「最大内容绘制」（Largest Contentful Paint，LCP），衡量的是首视口内最大元素渲染完成的时刻，web.dev 的官方刻度为：良好 ≤ 2.5 秒，待改进 2.5 ～ 4.0 秒，差 > 4.0 秒，同样以 P75 判定。
一句话口径：白屏（FCP）按 P75 控制在 1.8 秒内为良好，超过 3.0 秒为差；首屏主内容（LCP）对应 2.5 秒与 4.0 秒两条线。 这两组数字出自 web.dev 现行 Core Web Vitals 定义。这三档阈值如下图所示：
图1：FCP 与 LCP 的三档阈值标尺（口径来源：web.dev Core Web Vitals）
二、白屏/首屏到底是什么：定义与浏览器采集原理
「白屏时间」是国内前端监控的常用说法，在标准度量体系里对应 FCP：它记录的是从导航开始，到浏览器在屏幕上首次渲染出任意可见 DOM 内容的时刻。所谓「可见内容」，包括文字、图片元素、作为图片引用的 SVG、以及非空 canvas；纯白色背景或空容器不计入。
LCP 则更进一步，记录首视口内最大那个元素（图片、视频海报或大段文字块）完成渲染的时刻。与 FCP 不同，LCP 在页面加载过程中会被多次触发——随着更大的元素渲染出来，浏览器会不断上报新的候选；工程上通常取用户首次输入（点击、滚动）之前的最后一次上报作为该次访问的 LCP。
这两个指标不需要自己算时间戳，现代浏览器通过 PerformanceObserver 标准接口主动暴露。典型采集方式如下：
// 采集 FCP
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (entry.name === 'first-contentful-paint') {
console.log('FCP =', entry.startTime);
}
}
}).observe({ type: 'paint', buffered: true });
// 采集 LCP（多次触发，取输入前的最后一次）
new PerformanceObserver((entryList) => {
const entries = entryList.getEntries();
const last = entries[entries.length - 1];
console.log('LCP =', last.startTime, last.size);
}).observe({ type: 'largest-contentful-paint', buffered: true });
其中 buffered: true 的作用，是补回在监听器注册之前就已经发生的条目，避免首屏指标漏采。浏览器上报到 SDK、再聚合到看板的链路如下图所示：
图2：FCP/LCP 的浏览器上报时机与采集链路
三、实验室数据 vs 真实用户数据（Lab vs RUM）
判断「白屏时间正不正常」之前，必须先分清两类数据来源，否则很容易误判：
- 实验室数据（Lab）：在固定设备、固定网络下用 Lighthouse、PageSpeed Insights 等工具测得。优点是可复现、条件可控；缺点是它测的是「某一次、某个干净环境下」的结果，无法代表真实用户的分布。
- 真实用户数据（RUM）：直接从真实访问者的浏览器里采集，覆盖真实设备、真实网络、真实地区。它反映的是用户实际感受到的速度，也是 web.dev 阈值所针对的数据类型。
web.dev 的 FCP/LCP 阈值明确要求「在真实用户数据上、按 P75、移动与桌面分开」来判定。这意味着：PageSpeed 分数好看，不等于线上真实用户的白屏就达标。我们提供的正是 RUM 视角的前端性能监控，把卡顿、报错、接口超时和白屏/首屏指标放在同一套看板里观察。
四、为什么看 P75：分位数与采样口径
平均值是性能判断里最常见的坑。一个站如果九成访问秒开、一成访问卡到 6 秒，平均值可能仍然很漂亮，但那一成慢用户正在流失。
更合理的口径是分位数：
- P75：75% 的用户快于这个值，25% 慢于它。web.dev 用 P75 作为「良好/待改进/差」的判定点，意味着「至少四分之三用户体验达标」。
- P95：95% 的用户快于这个值，只放掉最慢的 5%。它用来盯长尾——那些弱网、低端机、跨国访问的用户。
关于采集口径，web.dev 明确建议：性能指标应基于真实用户数据、按第 75 分位（P75）评估，并将移动与桌面分开统计。对于日访问量极大的站点，行业通行做法是按业务量级配置采样率——常规性能指标按比例抽样，慢请求、报错与接口超时等异常事件保留全量上报，以在成本与长尾覆盖之间取得平衡。实践上，我们建议同时看 P75 和 P95：P75 决定「整体是否达标」，P95 决定「长尾是否在恶化」。只看平均值，会把慢用户的问题系统性地藏起来。
五、慢的代价：Google/SOASTA 2017 研究
白屏与首屏为什么值得优先优化，有真实用户行为数据支撑。Google 与 SOASTA 在 2017 年联合发布的移动端页面速度研究，基于海量真实访问数据得出：
- 页面加载时间从 1 秒增加到 3 秒，跳出概率上升约 32%；
- 从 1 秒增加到 5 秒，跳出概率上升约 90%；
- 从 1 秒增加到 10 秒，跳出概率上升约 123%。
同一份研究还给出一个被广泛引用的结论：超过一半（约 53%）的移动端访问，如果页面在 3 秒内没有加载完成，会被直接放弃。
需要说明数据边界：该研究完成于 2017 年，当时移动网络以 3G/4G 为主，今天的绝对数值不必照搬；但「首屏每变慢一截，跳出概率非线性放大」这一方向性结论，至今仍是性能投入的核心依据。
六、边界条件：同一页面在不同用户身上差异巨大
「白屏时间正常吗」这个问题，脱离分层维度就没有答案。判断时至少要按下面四个维度拆开看：
| 分层维度 | 差异来源 | 对判断的影响 |
|---|---|---|
| 网络类型 | Wi-Fi / 4G / 5G / 弱网 | 弱网下 TTFB 与资源下载耗时被放大 |
| 设备性能 | 高端机 / 中低端安卓 | 低端机 JS 解析与渲染耗时显著拉长 |
| 缓存状态 | 首次访问 / 二次访问 | 二次访问有缓存，白屏会快很多 |
| 地区分布 | CDN 节点、跨国链路 | 海外或偏远地区首字节延迟更高 |
因此，一份把所有用户揉在一起的「平均白屏时间」几乎没有决策价值。看板支持按设备、网络、地区对同一指标做下钻，定位到底是哪一类用户在慢。
七、白屏慢的排查路径：先定位卡在哪一段
白屏/首屏时间可以拆成几段来归因，先看 P75 落在哪一段，再决定优化方向：
- 网络与首字节（DNS / TLS / TTFB）：请求发出去但服务器迟迟没回第一个字节。通常靠 CDN 就近接入、缓存、TCP/TLS 优化解决。
- 服务端响应：接口本身耗时、数据库查询慢、服务端渲染瓶颈。这一段慢，前端怎么改都救不回来。
- 关键资源与渲染阻塞：首屏要拉的关键 JS/CSS 过大或阻塞渲染；单页应用（CSR）尤其明显——要等首包 JS 下载、解析、执行完才开始绘制，这是白屏的高发原因。
- 资源体积：首屏图片未压缩、未做响应式与懒加载、代码未拆包，导致首屏要下载的字节数过大。
一个实用判断法：看 TTFB 到 FCP 的间隔。如果 TTFB 已经很长，问题在网络或服务端；如果 TTFB 正常但 FCP 仍慢，问题集中在前端渲染与关键资源。两者的优化动作完全不同，不能混为一谈。真实用户性能数据从浏览器到分位看板的完整链路如下图所示：
图3：RUM 数据从用户浏览器到分位看板的完整链路
八、我们如何落地这套性能监控
456数据 是一个全端数据分析与性能监控平台，定位是「网站、App、小程序，一站看懂」。围绕本篇主题，我们的能力边界如下（均为官网公开信息）：
- 产品线：网站分析、App 分析、小程序分析、用户行为分析（事件埋点、漏斗、用户路径）、用户画像分析，以及前端性能监控。
- 前端性能监控：定位页面卡顿、收集前端报错、发现接口超时，并将白屏、首屏等性能指标按分位数可视化。
- 接入与架构：5 分钟快速接入，一套SDK覆盖网站、App、小程序，业务数据与性能数据打通，支持下钻分析。
- 定价透明：免费版 ¥0/月（含 100 万 PV / 50 万事件量/年），基础版 ¥99/年起（1000 万 PV / 500 万事件量/年），专业版与企业版按用量阶梯提供。
我们服务个人站长、互联网产品团队、电商零售、数字化营销等行业用户。具体功能与版本以官网实际展示为准。
九、常见判断误区
- 只看平均白屏时间。 平均值会掩盖 P75/P95 的真实分布，性能判断必须落到分位数。
- 只信实验室跑分。 Lighthouse 分数高，不代表线上弱网用户的白屏就达标，必须看 RUM。
- 白屏快就等于体验好。 FCP 达标后还要看 LCP、可交互时间（TTI）和报错率，白屏只是加载旅程的起点。
- 不分层看数据。 把移动与桌面、首次与二次访问、不同网络揉在一起，定位不出真正的慢用户群。
总结
白屏时间多久算正常，落到可执行口径就是：FCP 按 P75 ≤ 1.8 秒为良好、> 3.0 秒为差；LCP 按 P75 ≤ 2.5 秒为良好、> 4.0 秒为差。判断时要分清实验室数据与真实用户数据，用 P75 看整体、用 P95 盯长尾，并按网络、设备、缓存、地区分层。慢了先拆 TTFB、FCP、LCP 各段，定位到底卡在哪一环，再决定优化动作。这也是我们前端性能监控在落地时的基本判断框架。
