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 也会随之增加。
分页是另一个常见的性能杀手。列表的第一页通常很快，因为它是默认视图且被积极缓存。第 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 差异。 - 重度过滤器组合： 带有多个活动过滤器的电子商务分类页面渲染成本高昂，且很少缓存。如果您的 p75 LCP 很高，过滤器组合很可能是一个原因。
- 第 1 页以外的分页： 第 2 页及之后通常更慢且更耗资源。它们通常也包含相同的 Hero 图像或布局，但没有前一次访问缓存资产的优势。
如何在 CoreDash 中使用此维度
在任何 CoreDash 报告的维度选择器中选择查询字符串。表格将显示每个唯一的查询字符串及其 LCP、INP、CLS 和访问次数。按 LCP 排序以查找最慢的参数组合，或按访问次数排序以查找流量最高的变体。
将此维度与 URL 维度配对，以便在比较其查询字符串变体之前将分析缩小到单个页面模板。这种组合可以轻松确认性能问题是在页面本身还是在特定的参数模式中。
查询字符串维度属于 CoreDash 中的页面与导航类别，与 URL、Pathname 和导航类型等维度并列。