Dimension Core/Dash : Query String

Ce que la dimension Query String capture

La dimension Query String regroupe vos données Core Web Vitals par la chaîne de requête complète présente dans l'URL au moment de la visite de la page. Cela inclut tout ce qui se trouve après le ? : les paramètres de suivi comme utm_source=google, la pagination comme page=2, les ordres de tri comme sort=price, les requêtes de recherche comme q=running+shoes, les variantes de tests A/B et les combinaisons de filtres.

La plupart des outils de surveillance des performances suppriment les chaînes de requête ou les regroupent dans une seule URL. CoreDash les conserve intactes, ce qui signifie que vous pouvez comparer le LCP, l'INP et le CLS de /products?sort=price par rapport à /products?sort=popularity sur le même modèle de page, avec les mêmes utilisateurs, sur la même période.

Pourquoi les chaînes de requête causent des régressions de performance

Les paramètres de requête sont l'une des sources les plus courantes de variations de performance inexpliquées. Voici pourquoi ils sont importants :

Comportement de mise en cache du CDN

Par défaut, la plupart des CDN traitent les URL avec des chaînes de requête différentes comme des entrées de cache distinctes. /search?q=boots et /search?q=sandals sont deux clés de cache distinctes. Si votre page de résultats de recherche génère des centaines de requêtes uniques par heure, presque aucune de ces requêtes ne sera servie depuis le cache. Chaque visiteur sollicite votre serveur d'origine à froid.

Certains CDN vous permettent d'ignorer des paramètres spécifiques (comme les balises UTM) dans la clé de cache, mais cette configuration est facile à omettre. Si utm_source=email est inclus dans votre clé de cache, la page de destination de votre campagne e-mail aura un taux de réussite de cache proche de zéro, et chaque destinataire obtiendra un rendu serveur complet au lieu d'une réponse mise en cache. Il s'agit d'un pic LCP courant et mesurable.

Coût du rendu côté serveur

Les paramètres de filtre et de tri déclenchent souvent les requêtes de base de données les plus coûteuses sur une page. Une simple liste de produits sur /products peut être entièrement mise en cache. La même page sur /products?color=red&size=M&brand=Nike&sort=price-asc peut nécessiter une requête complexe, une forme de réponse différente, voire un rendu complet. Sur les pages qui ne peuvent pas mettre en cache efficacement les résultats filtrés, le Time to First Byte augmente, et le LCP suit.

La pagination est un autre problème récurrent. La page 1 d'une liste est généralement rapide car il s'agit de la vue par défaut et elle est mise en cache de manière agressive. La page 10 ou la page 50 est rarement mise en cache, souvent plus lente à générer, et fréquemment jamais testée. CoreDash met ces différences en évidence directement, sans que vous ayez à deviner.

Comportement côté client déclenché par des paramètres

Certains paramètres de requête ne modifient pas la réponse du serveur mais changent le JavaScript exécuté au chargement. Les paramètres de variantes de tests A/B, les codes de suivi d'affiliation et les jetons de parrainage sont fréquemment lus par des scripts qui initialisent différents flux d'interface utilisateur (UI), déclenchent des requêtes réseau supplémentaires ou retardent le rendu en attendant la configuration de l'expérience. Ces paramètres peuvent ajouter un coût INP mesurable et occasionnellement causer des Cumulative Layout Shift si la variante modifie le contenu visible après le premier affichage.

Modèles courants qui valent la peine d'être examinés

• Paramètres UTM sur le trafic payant : Les visiteurs provenant de publicités atterrissent souvent avec ?utm_source=google&utm_medium=cpc&utm_campaign=.... Si votre CDN les inclut dans sa clé de cache, le trafic payant obtient systématiquement des réponses plus lentes que le trafic organique.
• Pages de résultats de recherche : Les requêtes courtes et populaires peuvent être mises en cache. Les requêtes de longue traîne ou effectuées pour la première fois ne le sont presque jamais. Comparer ?q=nike avec ?q=blue+trail+running+shoes+mens+size+11 révèle souvent une différence de LCP mesurable.
• Combinaisons de filtres lourdes : Les pages de catégories e-commerce avec de multiples filtres actifs sont coûteuses à rendre et rarement mises en cache. Si votre 75ème centile LCP est élevé, les combinaisons de filtres y contribuent probablement.
• Pagination au-delà de la page 1 : La page 2 et les suivantes sont généralement plus lentes et plus gourmandes en ressources. Elles contiennent aussi souvent la même image héro ou la même mise en page, mais sans bénéficier des ressources mises en cache lors d'une visite précédente.

Comment utiliser cette dimension dans CoreDash

Sélectionnez Query String dans le sélecteur de dimension de n'importe quel rapport CoreDash. Le tableau affichera chaque chaîne de requête unique avec son LCP, INP, CLS et son nombre de visites. Triez par LCP pour trouver les combinaisons de paramètres les plus lentes, ou triez par nombre de visites pour trouver les variantes avec le plus fort trafic.

Associez cette dimension à la dimension URL pour restreindre votre analyse à un seul modèle de page avant de comparer ses variantes de chaînes de requête. Cette combinaison permet de confirmer facilement si un problème de performance réside dans la page elle-même ou dans un modèle de paramètre spécifique.

La dimension Query String fait partie de la catégorie Page & Navigation dans CoreDash, aux côtés de dimensions telles que URL, Pathname et Navigation Type.