Dimensão CoreDash: Query String

O que a dimensão Query String captura

A dimensão Query String agrupa seus dados de Core Web Vitals pela string de consulta completa presente na URL no momento da visita à página. Isso inclui tudo após o ?: parâmetros de rastreamento como utm_source=google, paginação como page=2, ordens de classificação como sort=price, consultas de pesquisa 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 em um único grupo de URLs. O CoreDash as mantém intactas, o que significa que você pode comparar o LCP, INP e CLS de /products?sort=price com /products?sort=popularity no mesmo template de página, com os mesmos usuários, no mesmo período de tempo.

Por que as query strings causam regressões de performance

Os parâmetros de consulta são uma das fontes mais comuns de variação de performance inexplicável. Eis por que eles importam:

Comportamento de cache do CDN

Por padrão, a maioria dos CDNs trata URLs con diferentes query strings como entradas de cache separadas. /search?q=boots e /search?q=sandals são duas chaves de cache distintas. Se a sua página de resultados de pesquisa gera centenas de consultas únicas por hora, quase nenhuma dessas solicitações será servida pelo cache. Cada visitante atinge seu servidor de origem "frio".

Alguns CDNs permitem que você ignore parâmetros específicos (como tags UTM) na chave de cache, mas essa configuração é fácil de esquecer. 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 em cache. Esse é um pico de LCP comum e mensurável.

Custo de renderização no lado do servidor (Server-side rendering)

Os parâmetros de filtro e classificação frequentemente acionam as consultas de banco de dados mais caras em uma página. Uma listagem de produtos simples em /products pode estar totalmente em cache. 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 renderização completa. Em páginas que não podem armazenar resultados filtrados de forma eficiente, o time to first byte aumenta, e o LCP o acompanha.

A paginação é outro ofensor consistente. A página 1 de uma listagem costuma ser rápida porque é a visualização padrão e é armazenada em cache agressivamente. A página 10 ou a página 50 raramente estão em cache, costumam ser mais lentas para gerar e frequentemente nunca são testadas. O CoreDash traz essas diferenças à tona diretamente, sem exigir que você adivinhe.

Comportamento do lado do cliente acionado por parâmetros

Alguns parâmetros de consulta não alteram a resposta do servidor, mas alteram qual JavaScript é executado no carregamento. Parâmetros de variante de teste A/B, códigos de rastreamento de afiliados e tokens de referência são frequentemente lidos por scripts que inicializam diferentes fluxos de UI, disparam solicitaçõ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 de 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 o seu CDN incluir estes na sua chave de cache, o tráfego pago receberá consistentemente respostas mais lentas do que o tráfego orgânico.
• Páginas de resultados de pesquisa: Consultas curtas e populares podem estar em cache. Consultas de "cauda longa" ou de primeira vez quase nunca estão. Comparar ?q=nike com ?q=blue+trail+running+shoes+mens+size+11 frequentemente 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 estão em cache. Se o seu p75 LCP estiver alto, as combinações de filtros são um provável contribuinte.
• Paginação além da página 1: A página 2 e além costumam ser mais lentas e exigir mais recursos. Elas também costumam conter a mesma imagem hero ou layout, mas sem o benefício de ativos em cache 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 junto com seu LCP, INP, CLS e contagem de visitas. Classifique por LCP para encontrar as combinações de parâmetros mais lentas ou classifique por contagem de visitas para encontrar as variantes de tráfego mais alto.

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 a confirmação de 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 se enquadra na categoria Page & Navigation no CoreDash, ao lado de dimensões como URL, Pathname e Navigation Type.