Dimensão Core/Dash: Query String

O que a dimensão Query String captura

A dimensão Query String agrupa seus dados do Core Web Vitals pela query string completa presente na URL no momento da visita à página. Isso inclui tudo depois do ?: parâmetros de rastreamento como utm_source=google, paginação como page=2, ordenações como sort=price, consultas de busca como q=running+shoes, variantes de teste A/B e combinações de filtros.

A maioria das ferramentas de monitoramento de performance remove as query strings ou as agrupa sob uma única URL. O CoreDash as mantém intactas, o que significa que você pode comparar o LCP, o INP e o CLS de /products?sort=price com /products?sort=popularity no mesmo template de página, com os mesmos usuários, no mesmo período.

Por que query strings causam regressões de performance

Parâmetros de query são uma das fontes mais comuns de variação inexplicável de performance. Aqui está por que eles importam:

Comportamento de cache da CDN

Por padrão, a maioria das CDNs trata URLs com query strings diferentes como entradas de cache distintas. /search?q=boots e /search?q=sandals são duas chaves de cache distintas. Se a sua página de resultados de busca gera centenas de consultas únicas por hora, quase nenhuma dessas requisições será servida a partir do cache. Todo visitante atinge seu servidor de origem sem cache.

Algumas CDNs permitem ignorar parâmetros específicos (como tags UTM) na chave de cache, mas essa configuração é fácil de passar despercebida. Se utm_source=email estiver incluído na sua chave de cache, a landing page da sua campanha de e-mail terá uma taxa de acerto de cache próxima de zero, e cada destinatário receberá uma renderização completa do servidor em vez de uma resposta cacheada. Esse é um pico de LCP comum e mensurável.

Custo de renderização no servidor

Parâmetros de filtro e ordenação costumam disparar as consultas de banco de dados mais caras de uma página. Uma listagem simples de produtos em /products pode estar totalmente cacheada. A mesma página em /products?color=red&size=M&brand=Nike&sort=price-asc pode exigir uma consulta complexa, um formato de resposta diferente ou até mesmo uma re-renderização completa. Em páginas que não conseguem cachear resultados filtrados com eficiência, o Time to First Byte aumenta, e o LCP o acompanha.

A paginação é outro problema frequente. A página 1 de uma listagem geralmente é rápida porque é a visualização padrão e é cacheada de forma agressiva. A página 10 ou 50 raramente é cacheada, costuma ser mais lenta para gerar e frequentemente nunca é testada. O CoreDash mostra essas diferenças diretamente, sem que você precise adivinhar.

Comportamento client-side disparado por parâmetros

Alguns parâmetros de query não alteram a resposta do servidor, mas mudam qual JavaScript roda no carregamento. Parâmetros de variantes de teste A/B, códigos de rastreamento de afiliados e tokens de referência são lidos com frequência por scripts que inicializam fluxos de UI diferentes, disparam requisições de rede adicionais ou atrasam a renderização enquanto aguardam a configuração do experimento. Esses parâmetros podem adicionar um custo mensurável ao INP e, ocasionalmente, causar mudanças de layout se a variante alterar o conteúdo visível após a pintura inicial.

Padrões comuns que valem a pena investigar

• Parâmetros UTM em tráfego pago: Visitantes vindos de anúncios frequentemente chegam com ?utm_source=google&utm_medium=cpc&utm_campaign=.... Se a sua CDN incluir esses parâmetros na chave de cache, o tráfego pago receberá consistentemente respostas mais lentas do que o tráfego orgânico.
• Páginas de resultados de busca: Consultas curtas e populares podem estar cacheadas. Consultas de cauda longa ou inéditas quase nunca estão. Comparar ?q=nike com ?q=blue+trail+running+shoes+mens+size+11 geralmente mostra uma diferença mensurável de LCP.
• Combinações pesadas de filtros: Páginas de categoria de e-commerce com múltiplos filtros ativos são caras para renderizar e raramente são cacheadas. Se o seu LCP no percentil 75 estiver alto, as combinações de filtros são um provável fator contribuinte.
• Paginação além da página 1: A página 2 e as seguintes costumam ser mais lentas e consumir mais recursos. Elas também costumam conter a mesma imagem hero ou layout, mas sem o benefício de recursos cacheados de uma visita anterior.

Como usar esta dimensão no CoreDash

Selecione Query String no seletor de dimensões em qualquer relatório do CoreDash. A tabela mostrará cada query string única ao lado de seu LCP, INP, CLS e número de visitas. Ordene por LCP para encontrar as combinações de parâmetros mais lentas, ou por número de visitas para encontrar as variantes de maior tráfego.

Combine esta dimensão com a dimensão URL para restringir sua análise a um único template de página antes de comparar suas variantes de query string. Essa combinação facilita confirmar se um problema de performance está na página em si ou em um padrão de parâmetro específico.

A dimensão Query String fica na categoria Page & Navigation no CoreDash, ao lado de dimensões como URL, Pathname e Navigation Type.