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 核心）以及来自网络信息 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 数据中表现得最为明显。
主线程上的长任务会阻塞输入响应。在具有 1 GB RAM 的设备上，甚至在您的 JavaScript 运行之前，浏览器就已经处于内存压力之下：更激进的垃圾回收、更频繁的标签页丢弃以及 JIT 编译的余量更少，所有这些都直接转化为更长的任务持续时间。在一个现代手机上能以 180 毫秒通过 INP 的网站，在受限设备上很容易飙升到 400 毫秒。
2025 年 Web Almanac 性能章节证实了这一趋势：移动端 INP 总体通过率达到 77%，但在该数据中，高性能设备和低端设备之间的差距巨大。大约 29% 的移动 Web 用户使用的设备性能比当前旗舰机型低三倍。在大多数全球市场中，这些用户并不是异常值；他们是中位数的访问者。
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 与国家/地区维度结合使用。南亚和东南亚市场、撒哈拉以南非洲地区以及拉丁美洲部分地区高度集中了受限和极其有限的设备。按国家/地区过滤的 CCS 细分将向您展示差距最大的地方，并帮助您优先考虑首先解决哪个市场的问题。
未知存储桶 (CCS 0) 涵盖了所有 Firefox 和 Safari 流量，以及 API 未返回任何值的所有会话。不要忽略它。在 Firefox 或 Safari 份额很大的网站上，未知类别可能占所有会话的四分之一或更多。这并不意味着这些用户使用了糟糕的设备；它仅仅意味着信号不可用。将未知类别视为一个独立的片段，而不是将其折叠到您的基准线中。
如何处理这些数据
如果 CCS 3、4 或 5 的访问者占您流量的 15% 以上，并且他们的 INP 始终高于 200 毫秒，那么修复方案将非常明确：
- 在 Chrome DevTools 中的受限设备上对您耗时最长的任务进行性能分析。Performance 面板中的任务归因将显示哪些脚本是导致问题的原因。
- 将非关键的第三方脚本移至交互或可见性触发器之后，以便它们在初始加载窗口期间不会争夺主线程。
- 减小关键路径上的 JavaScript 包大小。在低内存设备上解析的每个千字节的成本都高于旗舰设备，因为 JIT 编译器缓存编译代码的空间更少。
- 使用
scheduler.yield()或setTimeout(0)来分解长任务，并让浏览器有机会在代码块之间处理输入事件。
CoreDash 将 CCS 和设备内存维度与每个 Core Web Vitals 指标一起呈现，这样您就可以确认，一项改善了高端设备 INP 的修复措施，是否也同时改善了受限访问者的数据，而不仅仅是您的最佳情况用户。
