好的页面加载时间是:至少四分之三的真实访问里,页面主要内容在 2.5 秒内可见。这是一个具体的目标:用的是最大内容绘制(LCP)而不是「完全加载」,用的是第 75 百分位而不是平均值。本文解释为什么,列出相关耗时的目标,并讲怎么检查自己的页面。
读完你会知道
- 目标是真实访问第 75 百分位的 LCP 不超过 2.5 秒
- 「完全加载」时间包含了访客根本不会等的东西,不适合做目标
- 移动端单独看,先看最慢的页面模板
简短的答案
目标是真实访问第 75 百分位的最大内容绘制(LCP)不超过 2.5 秒。说白了:至少四次访问里有三次,主要内容要在 2.5 秒内可见。
为什么不用「完全加载」时间?
很多工具里的「加载时间」指页面上所有资源都加载完的时刻:首屏以下的图片、客服挂件、统计脚本。访客不会等这些。一个页面可能 1.5 秒就感觉能用了,完全加载却报 7 秒。
LCP 衡量的是视口里最大的那块内容(通常是主图或标题)出现的时间,和人的实际感受贴近得多。
为什么用第 75 百分位?
平均值把快的和慢的访问混成一个数,描述的不是任何人。第 75 百分位的意思是:四次访问里有三次至少这么快。它把慢的那四分之一保留在视野里,又不会被少数极端访问左右。
各项耗时的目标
表里给出了最重要的四项耗时的阈值。LCP 是主目标;FCP 和 TTFB 用来解释 LCP 为什么慢;INP 衡量加载后页面对操作的响应有多快。
| 耗时 | 良好 | 需改进 | 差 |
|---|---|---|---|
| 最大内容绘制 LCP(主要内容) | ≤ 2.5 秒 | 2.5–4 秒 | > 4 秒 |
| 首次内容绘制 FCP(最早出现的内容) | ≤ 1.8 秒 | 1.8–3 秒 | > 3 秒 |
| 首字节时间 TTFB(服务器响应) | ≤ 0.8 秒 | 0.8–1.8 秒 | > 1.8 秒 |
| 交互到下一次绘制 INP(对操作的响应) | ≤ 200 毫秒 | 200–500 毫秒 | > 500 毫秒 |
都按真实访问的第 75 百分位评判。
一个完整的例子
一家网店查看真实用户数据。桌面端 1.9 秒,轻松达标;移动端 3.1 秒,处在「需改进」区间。按页面模板拆开,移动端商品页 4.4 秒,慢得最多:商品大图没压缩,还有两个阻塞脚本。压缩图片、推迟脚本后,移动端商品页降到 2.4 秒。
桌面端
1.9 秒
良好
移动端
3.1 秒
需改进
最慢的模板
4.4 秒
移动端商品页
按设备和页面类型的 P75 LCP
示例怎么检查自己的页面
- 在每个页面上收集真实用户的耗时。在 TapCub 里,页面指标在页面隐藏时上报一次,性能报表的最慢页面列表按 P75 排序。
- 移动端和桌面端分开看。
- 按 P75 LCP 给页面模板排序,从又慢、又有流量的开始。
- 用加载耗时拆分(后端、网络、前端)找出时间花在哪。更多见网站性能指标。
加载时间会影响跳出率和 SEO 吗?
页面太慢,访客还没看到内容就走了,表现为浏览量变少、转化变低。包括 LCP 在内的核心网页指标,也被 Google 用作页面体验信号。光靠速度排不上名,但不管排在哪,慢页面都会流失访客。见怎么降低跳出率。
常见问题
页面加载时间多少秒算好?
真实访问第 75 百分位的最大内容绘制不超过 2.5 秒。
3 秒算好的加载时间吗?
对 LCP 来说,3 秒在「需改进」区间。不算差,但值得优化,尤其是移动端。
为什么实验室测试快,真实用户却慢?
实验室测试用的是一台快设备和快网络。真实访客用的手机和网络更慢,离服务器也更远。
这篇文章对你有帮助吗?
我们会根据反馈修改和补充这篇内容。
提交没有成功,请稍后再试。
谢谢你的反馈,我们会据此改进这篇内容。你已经反馈过这篇了,谢谢。




