Core/Dash Dimension: 设备与客户端能力

这些维度测量的指标

CoreDash 在设备与客户端能力类别下提供了两个维度。它们解答了不同的问题，但彼此之间形成了直接的互补。

设备内存（分组代码 m）报告了浏览器从 navigator.deviceMemory 返回的 RAM 区间。规范刻意向下取整到最接近的 2 的幂并限制了结果范围，因此您将看到 0.25、0.5、1、2、4 或 8+ GB 的值，而不是确切的数字。这种取整是有意为之的：它限制了指纹识别脚本可用的精度，同时仍然为开发者提供了可用的信号。

客户端性能评分（分组代码 ccs）是 CoreDash 根据三个浏览器暴露的信号计算得出的综合评分：设备内存、navigator.hardwareConcurrency（逻辑 CPU 核心数）以及网络信息 API 的有效连接类型。计算结果分为以下六个等级之一：

该综合评分比任何孤立的单一信号都更有用。配备 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 数据中表现得最为明显。

主线程上的长任务会阻塞输入响应。在拥有 1 GB RAM 的设备上，甚至在您的 JavaScript 运行之前，浏览器就已经处于内存压力之下：更激进的垃圾回收、更频繁的标签页丢弃，以及更少的 JIT 编译余量，所有这些都直接转化为更长的任务持续时间。在现代手机上以 180 毫秒通过 INP 的网站，在性能窘迫 (Constrained) 的设备上很容易就会飙升到 400 毫秒。

2025 年 Web Almanac 性能章节证实了这一趋势：移动端 INP 通过率总体达到 77%，但高性能设备与低端设备在该数据上的差距巨大。大约 29% 的移动网络用户使用的设备性能比当前的旗舰机低三倍。在大多数全球市场中，这些用户并非特例；他们是中位数访客。

CLS 对硬件类别的敏感度不如 INP，但如果字体或延迟加载的图像导致的重排在浏览器已经提交帧之后才完成，CPU 缓慢的设备仍然会产生布局偏移。

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

最高效的工作流程是首先将 CCS 用作过滤器，然后使用设备内存来验证您的假设。

首先，打开按 CCS 划分的 INP 细分数据。如果您的第 75 百分位 INP 对于极佳 (CCS 1) 和良好 (CCS 2) 的访客表现不错，但在受限 (CCS 3) 及以下的访客中未达标，则说明您遇到的是 CPU 或内存瓶颈，而不是网络瓶颈。这就可以排除一整类修复方案（预加载、连接提示、CDN 调优），并将您的注意力集中在 JavaScript 执行时间上：长任务、输入处理程序的开销以及在每次交互时运行的第三方脚本。

然后按设备内存进行过滤，查看哪些 RAM 区间导致了最差的结果。如果 1 GB 设备在糟糕的 INP 得分中占据了不成比例的份额，您就知道了瓶颈阈值。仅基于这些数据，在 4 GB 设备上尚可接受的脚本，便可成为延迟加载或移除的候选对象。

对于拥有全球受众的网站，请将 CCS 与国家/地区维度结合使用。南亚和东南亚市场、撒哈拉以南非洲以及拉丁美洲部分地区高度集中了性能窘迫 (Constrained) 和极度受限 (Very Limited) 的设备。按国家/地区过滤的 CCS 细分将向您展示差距最大的地方，并帮助您优先考虑首先解决哪个市场的问题。

未知 (CCS 0) 区间涵盖了所有 Firefox 和 Safari 流量，以及 API 未返回任何值的会话。切勿忽略它。在 Firefox 或 Safari 份额很大的网站上，未知可能会占到所有会话的四分之一或更多。这并不意味着这些用户的设备很差；它仅意味着该信号不可用。请将“未知”视为一个单独的细分，而不是将其归入您的基准数据中。

如何利用这些数据

如果 CCS 为 3、4 或 5 的访客在您的流量中占比超过 15%，且他们的 INP 始终高于 200 毫秒，则相应的修复方案非常明确：

• 在 Chrome DevTools 的受限设备模式下对最长的任务进行性能分析。性能面板中的任务归因（Task Attribution）将显示哪些脚本是罪魁祸首。
• 将非关键的第三方脚本移动到交互或可见性触发器之后，以便它们不会在初始加载窗口期间争抢主线程。
• 减小关键路径上的 JavaScript 包体积。在低内存设备上解析每一 KB 所花费的成本都要高于旗舰机，因为 JIT 编译器缓存编译后代码的空间更小。
• 使用 scheduler.yield() 或 setTimeout(0) 拆分长任务，并让浏览器有机会在代码块之间处理输入事件。

CoreDash 在每个 Core Web Vitals 指标旁边都会显示 CCS 和设备内存维度，以便您确认那些改善了高端设备 INP 的修复方案，是否也同样提升了性能窘迫 (Constrained) 访客的指标，而不仅仅是您的最佳环境用户。