Trusted by market leaders · Client results
Query String 维度捕获的内容
Query String 维度根据页面访问时 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 报告中的维度选择器中选择 Query String。该表将显示每个唯一的查询字符串及其 LCP、INP、CLS 和访问计数。按 LCP 排序以查找最慢的参数组合，或按访问计数排序以查找流量最高的变体。
将此维度与 URL 维度结合使用，可在比较其查询字符串变体之前，将您的分析范围缩小到单个页面模板。这种组合可以轻松确认性能问题是出在页面本身还是出在特定的参数模式中。
Query String 维度属于 CoreDash 中的 Page & Navigation 类别，与 URL、Pathname 和 Navigation Type 等维度并列。