Trusted by market leaders · Client results
查询字符串维度捕获的内容
查询字符串维度根据页面访问时 URL 中存在的完整查询字符串对你的 Core Web Vitals 数据进行分组。这包括 ? 之后的所有内容：像 utm_source=google 这样的跟踪参数、像 page=2 这样的分页、像 sort=price 这样的排序、像 q=running+shoes 这样的搜索查询、A/B 测试变体，以及过滤器组合。
大多数性能监控工具会剥离查询字符串，或将它们合并到单个 URL 组中。CoreDash 将它们完整保留。这意味着，对于同一个页面模板，你可以比较同一时期、相同用户的 /products?sort=price 和 /products?sort=popularity 的 LCP、INP 和 CLS。
为什么查询字符串会导致性能回退
查询参数是导致不明原因性能波动的最常见来源之一。原因如下：
CDN 缓存行为
默认情况下，大多数 CDN 会将带有不同查询字符串的 URL 视为独立的缓存条目。/search?q=boots 和 /search?q=sandals 是两个截然不同的缓存键。如果你的搜索结果页面每小时生成数百个唯一的查询，几乎没有请求能命中缓存。每个访客都会对你的源服务器发起冷请求。
某些 CDN 允许你在缓存键中忽略特定参数（比如 UTM 标签），但这种配置很容易被遗漏。如果你的缓存键包含了 utm_source=email，你的邮件营销落地页缓存命中率将接近于零，并且每个接收者得到的都是完整的服务器渲染，而不是缓存响应。这是一种常见且可测量的 LCP 飙升。
服务器端渲染成本
过滤和排序参数通常会触发页面上最昂贵的数据库查询。位于 /products 的普通产品列表可能被完全缓存。但位于 /products?color=red&size=M&brand=Nike&sort=price-asc 的同一个页面，可能需要复杂的查询、不同的响应格式，甚至完全重新渲染。在无法高效缓存过滤结果的页面上，Time to First Byte 会增加，LCP 也会随之增加。
分页是另一个常见的罪魁祸首。列表的第 1 页通常很快，因为它是默认视图，会被激进地缓存。第 10 页或第 50 页很少被缓存，生成速度通常更慢，而且常常从未被测试过。CoreDash 直接呈现这些差异，让你无需猜测。
参数触发的客户端行为
有些查询参数不会改变服务器响应，但会改变页面加载时运行的 JavaScript。A/B 测试变体参数、联盟跟踪代码和推荐令牌经常被脚本读取，用于初始化不同的 UI 流程、触发额外的网络请求，或在等待实验配置时延迟渲染。这些参数会增加可测量的 INP 成本，如果变体在初次绘制后改变了可见内容，有时还会导致布局偏移。
值得调查的常见模式
- 付费流量上的 UTM 参数：来自广告的访客通常带有
?utm_source=google&utm_medium=cpc&utm_campaign=...落地。如果你的 CDN 将这些包含在缓存键中，付费流量的响应速度将始终慢于自然流量。 - 搜索结果页面：简短的热门查询可能会被缓存。长尾或首次查询几乎从不被缓存。将
?q=nike与?q=blue+trail+running+shoes+mens+size+11进行比较，通常会显示出可测量的 LCP 差异。 - 繁重的过滤器组合：具有多个活动过滤器的电商分类页面渲染成本高昂，且很少被缓存。如果你的 75 分位 LCP 很高，过滤器组合很可能是原因之一。
- 第 1 页之后的分页：第 2 页及之后的页面通常更慢，也更消耗资源。它们通常还包含相同的首图或布局，但无法从之前访问的缓存资源中获益。
如何在 CoreDash 中使用此维度
在任何 CoreDash 报告的维度选择器中选择 查询字符串。表格会显示每个唯一的查询字符串及其 LCP、INP、CLS 和访问次数。按 LCP 排序，可以找到最慢的参数组合；或者按访问次数排序，找到流量最高的变体。
将此维度与 URL 维度结合使用，在比较其查询字符串变体之前，将分析范围缩小到单个页面模板。这种组合能让你轻松确认，性能问题究竟是出在页面本身，还是特定的参数模式上。
查询字符串维度在 CoreDash 中属于 页面与导航 类别，与 URL、路径名和导航类型等维度并列。