CoreDash 维度： 设备与客户端能力

这些维度测量什么

CoreDash 在“设备与客户端能力”类别下提供了两个维度。它们回答不同的问题，但又互为补充。

设备内存 (Device Memory)（组代码 m）报告浏览器从 navigator.deviceMemory 返回的 RAM 范围。规范有意将其向下舍入到最接近的 2 的幂并对结果进行限制，因此您会看到 0.25, 0.5, 1, 2, 4, 或 8+ GB 等值，而不是确切的数字。这种舍入是有意为之：它限制了指纹识别脚本可用的精度，同时仍能为开发人员提供可用的信号。

客户端能力评分 (Client Capability Score)（组代码 ccs）是 CoreDash 根据浏览器公开的三个信号计算出的综合得分：设备内存、navigator.hardwareConcurrency（逻辑 CPU 核心数）以及来自 Network Information API 的有效连接类型。结果分为六个等级：

综合得分比任何单一信号都更有用。一台在 2G 连接下拥有 4 GB RAM 的设备与同一台在 Wi-Fi 下的设备表现完全不同。将内存、核心数和连接类型合并为一个序数刻度，可以让您过滤和比较性能数据，而无需为每个变量单独运行细分分析。

浏览器支持和数据覆盖范围

navigator.deviceMemory 是一个仅限 Chromium 的 API。Firefox 和 Safari 不公开它，这意味着这些浏览器在内存组件方面始终报告 Unknown (CCS 0)。实际上，Chrome 和基于 Chrome 的浏览器占据了 Android 流量的绝大部分，而低内存情况正是在 Android 设备上集中的。因此，该信号在最需要的地方最为可用。

设备内存 HTTP 标头 (Device-Memory) 是另一种机制，允许服务器通过 Accept-CH 协商请求读取相同的值。CoreDash 使用在页面加载时收集的 JavaScript API，因此该值随 RUM 信标传输，而无需服务器端标头配置。

为什么设备能力对 Core Web Vitals 很重要

LCP 主要是网络和渲染问题。INP 主要是 CPU 和内存问题。这种区别就是为什么 CCS 维度在 INP 数据中表现得最为明显的原因。

主线程上的长任务会阻塞输入响应。在拥有 1 GB RAM 的设备上，甚至在您的 JavaScript 运行之前，浏览器就已经处于内存压力之下：更积极的垃圾回收、更频繁的标签页丢弃以及更少的 JIT 编译空间，都会直接转化为更长的任务持续时间。一个在现代手机上 INP 为 180 ms 达标的网站，在受限 (Constrained) 设备上很容易达到 400 ms。

2025 Web Almanac 性能章节 证实了这一趋势：移动端 INP 达标率总体达到 77%，但该数字中高性能设备与低端设备之间的差距很大。大约 29% 的 mobile web 用户使用的设备性能比当前旗舰机低三倍。在全球大多数市场中，这些用户并不是极端个例，而是中位访客。

CLS 对硬件等级的敏感度低于 INP，但 CPU 慢的设备在字体或延迟加载的图像引起重排（reflow）时，如果重排在浏览器已经提交一帧后才完成，仍可能产生布局偏移。

如何在 CoreDash 中使用 CCS 和设备内存

最高效的工作流程是先使用 CCS 作为过滤器，然后使用设备内存来确认您的假设。

首先，打开按 CCS 细分的 INP 报告。如果您的 p75 INP 在高性能 (Very Capable, CCS 1) 和合格 (Capable, CCS 2) 访客中表现良好，但在受限 (Limited, CCS 3) 及以下访客中表现不佳，那么您面临的是 CPU 或内存瓶颈，而不是网络瓶颈。这排除了一整类修复方案（预加载、连接提示、CDN 调整），并将您的注意力集中在 JavaScript 执行时间上：长任务、输入处理程序的权重以及在每次交互中运行的第三方脚本。

然后按设备内存进行过滤，看看哪些 RAM 等级导致了最差的结果。如果 1 GB 设备在差评 INP 分数中占据了不成比例的份额，您就知道阈值在哪里了。仅凭这些数据，在 4 GB 设备上可以接受的脚本就可能成为延迟加载或移除的候选对象。

对于拥有全球受众的网站，请将 CCS 与 国家/地区 维度结合使用。南亚、东南亚市场、撒哈拉以南非洲和拉丁美洲的部分地区拥有高浓度的受限 (Constrained) 和极度受限 (Very Limited) 设备。按国家/地区过滤的 CCS 细分将显示差距最大的地方，并帮助您优先处理哪个市场。

未知类别 (Unknown, CCS 0) 涵盖了所有 Firefox 和 Safari 流量，以及 API 未返回值的任何会话。不要忽视它。在 Firefox 或 Safari 份额显著的网站上，未知类别可能代表了四分之一或更多的会话。这并不意味着这些用户的设备很差；它意味着信号不可用。将未知类别视为一个单独的细分群体，而不是将其合并到基准中。

如何处理这些数据

如果 CCS 3, 4 或 5 访客占据了您流量的 15% 以上，且他们的 INP 持续高于 200 ms，则修复方案是具体的：

• 在 Chrome DevTools 中，在受限设备上对您的最长任务进行分析。性能面板中的任务归属 (Task Attribution) 将显示哪些脚本是负责人。
• 将非关键的第三方脚本放在交互或可见性触发器之后，这样它们就不会在初始加载窗口期间竞争主线程。
• 减少关键路径上的 JavaScript 包大小。在低内存设备上解析的每个字节的成本都比在旗舰机上高，因为 JIT 编译器缓存编译代码的空间较小。
• 使用 scheduler.yield() 或 setTimeout(0) 来拆分长任务，让浏览器有机会在分块之间处理输入事件。

CoreDash 在每个 Core Web Vitals 指标旁都呈现了 CCS 和设备内存维度，因此您可以确认，提升了高端设备 INP 的修复方案是否也改善了受限 (Constrained) 访客的数据，而不仅仅是您的理想用户。