Dimension Core/Dash : Query String

Ce que capture la dimension Query String

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 ? : paramètres de suivi comme utm_source=google, pagination comme page=2, ordres de tri comme sort=price, requêtes de recherche comme q=running+shoes, variantes de tests A/B et combinaisons de filtres.

La plupart des outils de monitoring de performance suppriment les chaînes de requête ou les regroupent dans un seul groupe d'URL. CoreDash les conserve intactes. Vous pouvez ainsi comparer le LCP, l'INP et le CLS de /products?sort=price et de /products?sort=popularity sur un même modèle de page, avec les mêmes utilisateurs et sur la même période.

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

Les paramètres d'URL sont l'une des sources les plus courantes de variations de performance inexpliquées. Voici pourquoi ils importent :

Comportement de mise en cache des CDN

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

Certains CDN permettent d'ignorer des paramètres spécifiques (comme les tags UTM) dans la clé de cache, mais cette configuration est facile à omettre. Si utm_source=email est inclus dans votre clé de cache, le taux de hit de cache de votre page de destination de campagne e-mail sera proche de zéro. Chaque destinataire déclenchera un rendu serveur complet au lieu de recevoir une réponse mise en cache. C'est un pic de LCP courant et mesurable.

Coût du rendu côté serveur

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

La pagination est un autre coupable récurrent. La page 1 d'une liste est généralement rapide, car c'est la vue par défaut, mise en cache de façon agressive. La page 10 ou la page 50 est rarement mise en cache, plus lente à générer, et bien souvent jamais testée. CoreDash affiche ces différences directement, sans vous laisser deviner.

Comportements côté client déclenchés par les 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 variante de test A/B, les codes d'affiliation et les jetons de parrainage sont fréquemment lus par des scripts qui initialisent différents parcours d'interface, déclenchent des requêtes réseau supplémentaires ou retardent le rendu en attendant la configuration du test. Ces paramètres peuvent alourdir l'INP de façon mesurable et provoquer parfois des décalages de mise en page si la variante modifie le contenu visible après le rendu initial.

Pistes d'investigation courantes

• Paramètres UTM sur le trafic payant : les visiteurs issus de publicités arrivent souvent avec des paramètres du type ?utm_source=google&utm_medium=cpc&utm_campaign=.... Si votre CDN inclut ces éléments dans sa clé de cache, le trafic payant recevra 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 inédites ne le sont presque jamais. Comparer ?q=nike à ?q=blue+trail+running+shoes+mens+size+11 révèle souvent un écart de LCP mesurable.
• Combinaisons de filtres lourdes : les pages de catégorie e-commerce avec plusieurs filtres actifs sont coûteuses à générer et rarement mises en cache. Si votre LCP au 75e percentile est élevé, ces combinaisons de filtres en sont probablement la cause.
• 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 affichent souvent la même image principale ou la même mise en page, sans pour autant bénéficier des ressources en cache d'une visite précédente.

Comment utiliser cette dimension dans CoreDash

Sélectionnez Query String dans le sélecteur de dimensions de n'importe quel rapport CoreDash. Le tableau affiche chaque chaîne de requête unique avec ses métriques LCP, INP, CLS et son nombre de visites. Triez par LCP pour identifier les combinaisons de paramètres les plus lentes, ou par nombre de visites pour trouver les variantes qui génèrent le plus de trafic.

Associez cette dimension à la dimension URL pour restreindre votre analyse à un modèle de page unique avant de comparer ses variantes de chaînes de requête. Cette combinaison permet de confirmer facilement si un problème de performance provient de la page elle-même ou d'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.