Trusted by market leaders · Client results
CoreDash 中的自定义细分
国家和设备类型等技术维度是根据浏览器信号构建的。CoreDash 会自动收集它们。这里介绍的三个维度则不同：Page Label、A/B Test 和 Logged In Status 是用户定义的。在 CoreDash 运行之前，你在自己的代码中通过给 window 变量赋值来设置它们。
从自动到主动的转变才是核心所在。你的应用知道浏览器无法推断的信息：用户正在看哪个结账变体、当前的 URL 是商品详情页还是落地页、用户是否已登录。将这些上下文传递给 CoreDash，意味着你的性能数据能反映业务的实际运作方式。
Page Label (lb)
Page Label 维度让你能够根据业务功能而不是 URL 结构对页面进行分组。像这样定义它：
window.__CWVL = 'mypagelabel';
典型值包括：checkout、product-detail、landing-page、category、search-results、account。该值是由你控制的任意字符串。
为什么这很重要
基于 URL 的分析有一个致命的扩展问题。一个大型电商网站可能有 50,000 个商品详情页。它们的 URL 看起来像 /products/blue-widget-32oz 和 /products/red-gadget-xl。这些是相同的模板、相同的业务功能、相同的优化目标。逐个分析 URL 没有意义。把它们归组到 product-detail 下，你就能得到整个商品目录的统一性能画像。
Page Label 还能将适用不同性能预算的页面区分开。结账页面直接带来收入，其可接受的 LCP 阈值非常苛刻。博客文章的容忍度则完全不同。而投放付费流量的落地页对慢 LCP 则是零容忍，因为多慢一毫秒都在浪费你的广告费。
一旦你按业务功能对页面进行了标记，你就可以在 CoreDash 中为每个标签设置不同的告警阈值，并将对应的告警派发给负责的团队。
A/B Test (ab)
A/B Test 维度保存了你分配给用户当前所处变体的标签。像这样定义它：
window.__CWAB = 'my page version';
该值是任意的。variant-a 和 variant-b 是显而易见的选择，但你可以使用任何能映射到你实验平台变体标识符的字符串。
为什么这很重要
A/B 测试是导致意外性能退化最常见的原因之一。变体 B 引入了新的主图轮播；变体 B 加载了第三方推荐组件；变体 B 包含了额外的 React hydration 过程。所有这些都会带来性能开销，而你的实验工具几乎肯定不会去测量它。
大多数实验平台只追踪转化率 and 收入，它们不追踪 p75 LCP 或 INP。如果变体 B 的转化率提升了 2%，但在移动端加载慢了 400 毫秒，你需要在推送到 100% 流量之前知道这一点。随着用户失去耐心，性能退化带来的损失可能会在下个季度彻底抹平转化率的增长。
设置 __CWAB 后，打开 CoreDash，过滤 ab = variant-b，即可并排对比它与对照组的 Core Web Vitals。我曾见过一些 A/B 测试，胜出的变体因为加载了更重的字体，其 p75 LCP 比对照组慢了 600 毫秒。业务团队只看到了转化率的提升，却没看到性能的退化。这正是该维度能帮你避免的问题。
Logged In Status (li)
Logged In Status 维度记录了当前用户是否已登录。像这样定义它：
window.__CWVLI = 1; // 已登录 window.__CWVLI = 0; // 未登录
为什么这很重要
已登录用户收到的页面与匿名访问者有本质的不同。他们的请求会绕过许多 CDN 缓存层。服务器需要运行数据库查询以生成个性化内容：用户的购物车、订单历史和收藏的商品。这些服务端开销会直接增加 TTFB。
在前端，已登录页面通常会加载更多 JavaScript：账户组件、通知系统、购物车响应式交互等。它们还可能跳过让匿名页面变快的预渲染或边缘缓存。结果就是，已登录用户的性能体验通常比匿名用户更慢，然而已登录用户通常是你价值最高的客户。他们已经完成了转化，是你最需要留住的人。
如果没有 li 维度，已登录用户的缓慢性能就会被隐藏在聚合数据中。你的匿名用户 LCP 可能是 1.8 秒，而登录用户 LCP 则是 3.4 秒。聚合数据读出来是 2.3 秒，看起来完全可以接受。但一旦按 li 细分，情况就完全不同了。
实现方式
这三个维度都遵循相同的模式：在 CoreDash 代码段执行前设置 window 变量。将它们放在文档头部（head）的 script 标签中，或者放在应用的初始化代码里：
// 根据应用状态设置这三个变量 window.__CWVL = 'checkout'; // 页面标签 window.__CWAB = 'variant-b'; // A/B 测试变体 window.__CWVLI = 1; // 已登录
标签值均为字符串（除了接收 1 或 0 的 __CWVLI）。请在整个代码库中保持一致。如果你在一个模板中使用 product-detail，而在另一个模板中使用了 productDetail，CoreDash 会将它们视为两个独立的细分，从而导致数据碎片化。选择一种命名规范并贯彻执行。
组合使用这三个维度
当你将这些维度叠加使用时，真正的价值才开始显现。假设你正在针对已登录用户在结账页面上运行 A/B 测试。你想知道变体 B 是让已登录的结账体验变快了还是变慢了。
在 CoreDash 中，可以过滤 ab = variant-b 加上 lb = checkout 加上 li = 1。这能精准呈现已登录用户在结账变体 B 下的性能表现。如果不在你那边进行繁琐的自定义开发，其他监控工具根本无法提供这种组合维度的分析能力。
标准技术维度告诉你浏览器经历了什么，而自定义维度则告诉你业务经历了什么。在投放付费流量的 landing-page 上，400 毫秒的 LCP 退化与在 blog 页面上的退化意义完全不同。这些差异对于排定优化优先级至关重要。而优先级的排定，正是性能优化工作走向成功还是陷入停滞的分水岭。