免费工具 网站测速：真实用户 Core Web Vitals 加一次 Lighthouse 测试
输入网址。Google PageSpeed Insights 接口会返回两样不同的东西，本页把它们分开放：近 28 天真实 Chrome 访客的体验，和 Lighthouse 模拟加载一次的结果、外加省时最多的修改建议。它测的是页面打开有多快、稳不稳、点了有没有反应，不是各地节点 ping 你服务器的响应时间。
- 现场数据和实验室数据并排
- 手机、桌面都能测
- 请求从你的浏览器直接发给 Google
测一个页面
选手机或桌面后点按钮。测完一次再切换设备，会接着测同一个网址的另一种设备。
会发什么、发给谁
- 只在你点按钮时发送：网页地址、手机还是桌面、报告语言和 API key，从你的浏览器直接发到 Google（
www.googleapis.com）。TapCub 看不到、不转发、不保存。 - Google 的服务器随后像访客一样打开这个网页，再把报告返回给你的浏览器；这次请求适用 Google 隐私权政策。
- 你填的 key 只留在这个页面里；勾选「记住」才会存进这个浏览器（
localStorage），取消勾选即删除。 - 在中国大陆网络环境下，浏览器通常连不上 www.googleapis.com，测试会提示网络错误。
还没有测试
填网址、点按钮，真实用户数据和实验室测试结果会显示在这里。先看看 Google 对真实用户数据用的阈值：
| 指标（75 分位） | 良好 | 需改进 | 较差 |
|---|---|---|---|
| 最大内容绘制（LCP） | ≤ 2.5 s | 2.5 s – 4.0 s | > 4.0 s |
| 交互到下一次绘制（INP） | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| 累积布局偏移（CLS） | ≤ 0.10 | 0.10 – 0.25 | > 0.25 |
| 首次内容绘制（FCP） · 非核心指标 | ≤ 1.8 s | 1.8 s – 3.0 s | > 3.0 s |
| 首字节时间（TTFB） · 非核心指标 | ≤ 800 ms | 800 ms – 1.8 s | > 1.8 s |
来源：PageSpeed Insights 文档「关于 PageSpeed Insights」和 web.dev，2026-11-11 核对。
分享这组输入：数值写在链接的 # 后面，不会发到服务器。
https://tapcub.com/zh/tools/pagespeed-checker
版本 v1.0更新于 更新记录
四块结果，按这个顺序看
先看真实访客的体验，再用实验室测试找原因。
Core Web Vitals 评估
「通过」表示近 28 天真实 Chrome 用户的 LCP、INP、CLS 75 分位都在「良好」。INP 数据不够时只看 LCP 和 CLS；LCP 或 CLS 没数据就无法评估。
现场指标和颜色条
大数字是 75 分位；颜色条是良好、需改进、较差三档各占多少次访问。75 分位过线，仍可能有五分之一的访问体验较差。
性能分
Lighthouse 一次实验室测试的 0–100 综合分，由 5 个指标加权得到。适合同一设备设置下对比改动前后，不代表用户的真实感受。
先改什么
没通过的洞察和诊断项，附 Lighthouse 估算的省时。现场 LCP 差就先改省 LCP / FCP 的项；INP 差就先改阻塞时间相关的项。
现场数据只来自选择共享使用统计的 Chrome 用户，而且要有足够访问量。访客主要用其它浏览器（比如国内常见的各类国产浏览器、微信内置浏览器）的网站，可能很少甚至没有现场数据。
从一次测速到页面变快
测带来流量和转化的页面，不只测首页。
-
1
先用手机测关键页面
多数访问来自手机，Google 也按手机版收录，所以先测手机，再切桌面。
-
2
先看现场数据
真实用户 75 分位已经「良好」，实验室分数一般也不用太着急；没过线，就看是哪个指标拖后腿。
-
3
改排在前面的几项，再测
按「先改什么」逐项处理，上线后多测几次实验室数据；现场数据会在之后 28 天里慢慢更新。
-
4
持续看所有页面
一次测速只是抽查一个网址。统计里的真实用户监测能覆盖每个页面、每次发版。
本页用的阈值和权重
现场指标按 Google 的阈值、取 75 分位判断；实验室性能分是 Lighthouse 对 5 个指标得分的加权平均。
- 现场：75 分位 ≤「良好」上限为良好，超过「较差」下限为较差，中间为需改进（PageSpeed Insights 官方文档）
- Core Web Vitals = LCP、INP、CLS；FCP 和 TTFB 作为辅助指标一起显示
- 实验室分数档：90–100 良好、50–89 需改进、0–49 较差；单个实验室指标按它自己的 Lighthouse 得分同样分档
- INP 需要真实的点击和输入，只有现场数据；实验室测试用总阻塞时间（TBT）代替
| 指标 | 现场（75 分位） | 实验室 | 良好 | 较差 | 占性能分 |
|---|---|---|---|---|---|
| LCP | 有 | 有 | ≤ 2.5 秒 | > 4.0 秒 | 25% |
| INP | 有 | — | ≤ 200 毫秒 | > 500 毫秒 | — |
| CLS | 有 | 有 | ≤ 0.1 | > 0.25 | 25% |
| FCP | 有 | 有 | ≤ 1.8 秒 | > 3.0 秒 | 10% |
| TTFB | 有 | — | ≤ 0.8 秒 | > 1.8 秒 | — |
| TBT | — | 有 | Lighthouse 评分曲线 | Lighthouse 评分曲线 | 30% |
| Speed Index | — | 有 | Lighthouse 评分曲线 | Lighthouse 评分曲线 | 10% |
读一份手机端结果
一个商品详情页的假设数字，按本工具的展示方式读一遍。
| 部分 | 数值 | 怎么读 |
|---|---|---|
| LCP 现场 75 分位 | 2.9 秒 | 需改进（超过 2.5 秒）；68% 的访问是良好 |
| INP 现场 75 分位 | 180 毫秒 | 良好（≤ 200 毫秒） |
| CLS 现场 75 分位 | 0.12 | 需改进（超过 0.1） |
| Core Web Vitals | 未通过 | INP 虽然良好，但 LCP 和 CLS 没到良好 |
| 实验室性能分 | 58 | 需改进；改完后在同样的设备设置下对比 |
| 排第一的建议 | 阻塞渲染的请求，LCP −0.9 秒 | 关键 CSS 内联、其余延后加载，再测 |
这个例子的处理顺序：先 LCP（阻塞渲染的 CSS、首屏大图体积），再 CLS（给图片、横幅预留位置）。INP 已经达标。
网站测速里最容易走的弯路
四个浪费时间的习惯。
非要 100 分
实验室分数只是一次模拟加载。从 92 提到 100，用户几乎感觉不到；现场指标不达标才真正影响体验。
只测一次
服务器负载、网络、第三方脚本都会让每次结果不同。测三次，看中间那次。
把实验室和现场混为一谈
实验室 LCP 很好、现场 LCP 较差，通常说明真实的手机、网络或登录后页面比测试慢。以现场数字为准去改。
只测首页
商品页、文章页、结算页用的是不同模板，往往更慢。测真正带来流量和成交的页面。
用自己访客的数据看 Web Vitals，覆盖每个页面
PageSpeed Insights 是从 Google 那边抽查一个网址；TapCub 统计代码测的是你真实访客的每一次页面打开。
网站测速多少分算正常？
Lighthouse 把 90–100 算良好、50–89 需改进、0–49 较差。但这个分数只来自一次模拟加载。更重要的是真实用户能否通过 Core Web Vitals：75 分位 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1。
和国内的「多节点测速」有什么区别？
多节点测速是从各地服务器请求你的网站，看 DNS 解析、连接、下载各用了多久，适合查线路和 CDN。本工具测的是页面在浏览器里打开的体验：多久出现主要内容、版面会不会跳、点击有没有及时反应。两类工具互补。
为什么现场数据和实验室数据差很多？
现场数据是近 28 天真实 Chrome 访问，设备、网络各不相同；实验室数据是 Google 服务器上用一台模拟设备、固定网络加载一次。前者回答用户体验如何，后者帮你找原因。
为什么每次测的分数都不一样？
实验室测试会受 Google 服务器负载、你的服务器响应、第三方脚本和广告影响，差几分很正常。多测几次，看中间值。
为什么我的网站没有真实用户数据？
CrUX 只收录近 28 天有足够 Chrome 访问量的页面和网站。单个网址不够时 Google 改用全站数据，全站也不够就没有。访客多用其它浏览器的网站更容易没有数据。Google 也说过计划不再在这个接口里返回 CrUX 数据，2026-11-11 核对时仍在返回。
Core Web Vitals 影响 Google 排名吗？
Google 的页面体验文档写着 Core Web Vitals 会被其排名系统使用（原文 “Core Web Vitals are used by our ranking systems”）。它只是众多信号之一，内容是否有用、相关更重要。百度没有公开同样的说法，本页不做推断。
为什么要填 API key？在国内能用吗？
本页从你的浏览器直接调用 Google PageSpeed Insights 接口，Google 现在不给不带 key 的请求额度，所以每次都要 key（免费，用 Google 账号申请）。在中国大陆网络下浏览器通常连不上 Google 接口，需要能访问 Google 的网络环境。
手机和桌面先测哪个？
先测手机。Google 在 2023 年完成了移动优先索引，抓取的是手机版；手机测试用的模拟设备和网络也更慢，更容易暴露问题。