Trusted by market leaders · Client results
这些维度测量什么
CoreDash 在设备与客户端能力分类下提供两个维度。它们回答不同的问题，但直接互补。
设备内存（分组代码 m）报告浏览器从 navigator.deviceMemory 返回的 RAM 区间。规范故意向下取整到最近的 2 的幂并限制结果。因此你会看到 0.25、0.5、1、2、4 或 8+ GB 的值，而不是精确数字。这种取整是故意的：它限制了指纹脚本可用的精度，同时仍为开发者提供可用的信号。
客户端能力得分（分组代码 ccs）是 CoreDash 从三个浏览器暴露的信号计算得出的综合得分：设备内存、navigator.hardwareConcurrency（逻辑 CPU 核心数）以及 Network Information API 提供的有效连接类型。结果分为六个区间之一：
| 值 | 标签 |
|---|---|
| 0 | 未知 |
| 1 | 能力极强 |
| 2 | 能力强 |
| 3 | 能力受限 |
| 4 | 能力极度受限 |
| 5 | 能力受约束 |
综合得分比单一信号更有用。4 GB RAM 设备在 2G 连接下和在 Wi-Fi 下的表现截然不同。将内存、核心数和连接类型合并为一个有序等级，能让你过滤和比较性能数据，无需为每个变量单独细分。
浏览器支持和数据覆盖率
navigator.deviceMemory 是仅限 Chromium 的 API。Firefox 和 Safari 不暴露它，这意味着这些浏览器在内存组件上始终报告未知（CCS 0）。在实践中，Chrome 和基于 Chrome 的浏览器占了 Android 流量的绝大部分，而 Android 设备正是低内存情况集中的地方。因此，这个信号恰好在最重要的地方最为可用。
设备内存 HTTP 标头（Device-Memory）是一个独立的机制，允许服务器从 Accept-CH 协商请求中读取相同的值。CoreDash 使用在页面加载时收集的 JavaScript API，因此该值随 RUM 信标一起发送，无需配置服务器端标头。
为什么设备能力对 Core Web Vitals 很重要
LCP 主要是网络和渲染问题。INP 主要是 CPU 和内存问题。正是这种区别，让 CCS 维度在 INP 数据中表现得最明显。
main thread 上的 long task 会阻塞输入响应。在 1 GB RAM 的设备上，甚至在你的 JavaScript 运行之前，浏览器就已经面临内存压力。更激进的垃圾回收、更频繁的标签页丢弃以及更少的 JIT 编译余量，都直接转化为更长的任务持续时间。在现代手机上以 180 毫秒通过 INP 的站点，在能力受约束的设备上很容易升至 400 毫秒。
2025 Web Almanac Performance 章节 证实了这一趋势：移动端 INP 总体通过率达到 77%，但在该数据中，高性能和低端设备之间的差距很大。约 29% 的移动端网页用户，其设备性能不到当前旗舰机的三分之一。在大多数全球市场中，这些用户不是特例；他们是典型的中位数访客。
CLS 对硬件类别的敏感度不如 INP。但在 CPU 较慢的设备上，当字体或延迟加载的图片引起重排，且在浏览器已经提交帧之后才完成时，仍会产生布局偏移。
如何在 CoreDash 中使用 CCS 和设备内存
最高效的工作流是：先将 CCS 作为过滤器，然后使用设备内存来确认你的假设。
首先，打开你按 CCS 细分的 INP。如果你的第 75 百分位 INP 对能力极强（CCS 1）和能力强（CCS 2）的访客表现良好，但对能力受限（CCS 3）及以下的访客不及格，那你面临的是 CPU 或内存瓶颈，而不是网络瓶颈。这排除了一整类修复方案（预加载、连接提示、CDN 调优），并将你的注意力集中在 JavaScript 执行时间上：long task、输入处理程序的开销，以及在每次交互时运行的第三方脚本。
然后按设备内存过滤，查看哪些 RAM 区间导致了最差的结果。如果 1 GB 设备在糟糕的 INP 分数中占了不成比例的份额，你就知道阈值了。在 4 GB 下表现尚可的脚本，仅凭这些数据即可成为延迟或移除的候选对象。
对于拥有全球受众的站点，将 CCS 与 国家 维度结合使用。南亚和东南亚市场、撒哈拉以南非洲以及拉丁美洲部分地区，高度集中了能力受约束和能力极度受限的设备。按国家过滤的 CCS 细分会显示差距最大的地方，帮你确定优先解决哪个市场。
未知区间（CCS 0）涵盖所有 Firefox 和 Safari 流量，以及 API 未返回任何值的会话。不要忽略它。在 Firefox 或 Safari 份额很大的站点上，未知可能占所有会话的四分之一或更多。这并不意味着这些用户的设备很差；这意味着信号不可用。将未知作为一个单独的细分处理，不要将其并入你的基准中。
如何处理这些数据
如果 CCS 3、4 或 5 的访客占你流量的 15% 以上，且他们的 INP 始终高于 200 毫秒，则修复方案很明确：
- 在 Chrome DevTools 中使用节流设备对最长的任务进行分析。性能面板中的任务归因会显示是哪些脚本造成的。
- 将非关键的第三方脚本放在交互或可见性触发器之后，这样它们就不会在初始加载窗口期争夺 main thread。
- 减小关键路径上的 JavaScript 包大小。在低内存设备上解析每一千字节的成本都比旗舰机高，因为 JIT 编译器缓存编译代码的空间更小。
- 使用
scheduler.yield()或setTimeout(0)拆分 long task，让浏览器有机会在分块之间处理输入事件。
CoreDash 在每个 Core Web Vitals 测量指标旁都会提供 CCS 和设备内存维度。这能让你确认，在高端设备上改善 INP 的修复方案，是否也改善了能力受约束访客的数据，而不仅仅是你最佳情况下的用户。
