Core/Dash 维度： 设备类型

通过跨设备外形拆分你的 Core Web Vitals 数据来调试移动端性能差距。

免费试用

Trusted by market leaders · Client results

harvardnestlehappyhorizonnina caresnvmarktplaatserasmusmcebaysaturnperionvpnloopearplugsworkivawhowhatwearaleteiadpg mediacomparemonarchfotocasaadevintakpnmy work featured on web.dev

维度：设备类型 (d)

设备类型 维度将你的 RUM 数据拆分为两类：mobile 和 desktop。这是任何性能调查中绝对重要的首个过滤器，因为移动端和桌面端是截然不同的计算环境。不同的 CPU、不同的网络条件、不同的视口大小以及不同的浏览器引擎。

如果你在查看聚合的 Core Web Vitals 时没有按设备类型进行过滤，那么你正在对两个几乎毫无共同点的人群进行平均。这种平均值充其量只能产生误导。

coredash metric table urls

移动端性能差距

根据 Statista (2025) 的数据，移动设备约占全球网络流量的 62%。然而，移动端的表现始终不及桌面端。根据 2025 Web Almanac，只有 48% 的移动端源通过了所有三个 Core Web Vitals，而桌面端为 56%。这之间存在 8 个百分点的差距。

这种差距的存在，是因为移动设备面临着桌面端没有的三个限制：

  • CPU 节流：中端 Android 手机的处理能力大约比桌面端低 3-5 倍。在桌面端 50ms 内执行的 JavaScript，在移动端可能需要 200ms，从而将 INP 推过“良好”阈值。
  • 网络延迟：移动连接 (4G/5G) 的往返时间比有线连接更高，且波动更大。这会抬高 TTFB 和 LCP 加载延迟。
  • 视口大小：较小的屏幕会改变哪个元素成为 LCP。你的桌面端首屏图片在移动端可能会缩小并排在文本块下方，从而彻底改变优化目标。

CoreDash 设备类型分布

在所有 CoreDash 项目中，典型的流量分布为 65% 的移动端和 35% 的桌面端。电子商务网站更严重地偏向移动端 (70-75%)，而 B2B SaaS 产品通常呈现 50/50 的比例，甚至桌面端占据主导。

CoreDash 数据中的性能差距反映了全球趋势。移动端 p75 LCP 平均为 2.8s，而桌面端为 1.9s。对于 INP，差距甚至更大：移动端 p75 位于 220ms 左右，而桌面端徘徊在 120ms 附近。

特定指标分析

Largest Contentful Paint (LCP)

移动端 LCP 几乎总是比桌面端差。主要原因是加载延迟：移动浏览器发现 LCP 图片的时间更晚，因为 HTML 到达所需的时间更长（更高的 TTFB），而且预加载扫描器在较慢的 CPU 上面临着更多的资源争用。如果你的桌面端 LCP 低于 2.0s，但移动端超过 3.0s，问题极少出在图片文件本身。问题在于交付管道。

Interaction to Next Paint (INP)

这是设备差距打击最严重的地方。在台式机 i7 上感觉瞬间完成的 JavaScript 事件处理程序，可能会在骁龙 665 上阻塞主线程超过 300ms。按移动端过滤，按 INP 影响排序，你就能确切找出在真实手机上崩溃的交互。我经常看到这种情况：开发者在 MacBook Pro 上进行测试，发布的交互却在 65% 用户实际携带的设备上无法使用。

Cumulative Layout Shift (CLS)

不同设备类型之间的 CLS 差异通常可追溯到响应式设计。在桌面端预留空间的广告位，在移动端可能会折叠或调整大小。在桌面端对齐的字体 fallback 指标，会导致在较小的视口上发生可见的偏移。Web 字体在移动端和桌面浏览器上的渲染方式不同，物理像素密度也会影响子像素舍入。

调试工作流

  1. 每次调查都从设备过滤器开始： 在查看任何其他维度之前，先按设备类型进行拆分。如果你的聚合 LCP 为 2.5s，你可能会发现桌面端为 1.8s，移动端为 3.1s。“问题”完全出在移动端。
  2. 比较分布，而不仅仅是 p75： 检查每种设备类型的 良好/需要改进/差 的分布。具有 85% 良好的桌面端和 45% 良好的移动端，所讲述的故事与单纯看 p75 完全不同。
  3. 与其他维度结合： 隔离设备类型后，添加第二个过滤器。设备类型 + 国家/地区 可以揭示移动端差距是全球性的，还是集中在网络较慢的区域。设备类型 + 导航类型 可以显示移动端前进-后退导航是否被正确缓存。

工程经验法则

  • 移动端 LCP 低于 2.5s： 这是 Google 用于判断“良好”的阈值。如果你的桌面端通过了但移动端失败，请专注于减少加载延迟（fetchpriority、preload）和 TTFB（边缘缓存、CDN）。
  • 移动端 INP 低于 200ms： 在真实的中端 Android 设备上测试每一个交互功能。Chrome DevTools CPU 节流 (4x) 可以近似模拟，但真实设备测试更好。
  • 永远不要只针对桌面端进行优化： 如果你的移动端流量超过 50%（几乎可以肯定是这样），移动端性能就是你的搜索排名信号。Google 使用移动端 CrUX 数据进行排名。

设备类型不是一个可有可无的过滤器。它是你要问的第一个问题：“这是移动端问题，还是桌面端问题？”每一个优化决策都源自这个答案。