Core/Dash Dimensie: Query String

Wat de Query String dimensie vastlegt

De Query String dimensie groepeert je Core Web Vitals data op de volledige query string die aanwezig is in de URL op het moment van het paginabezoek. Dat omvat alles na de ?: tracking parameters zoals utm_source=google, paginering zoals page=2, sorteervolgordes zoals sort=price, zoekopdrachten zoals q=running+shoes, A/B test varianten en filtercombinaties.

De meeste performance monitoring tools strippen query strings of voegen ze samen in één URL groep. CoreDash houdt ze intact, wat betekent dat je de LCP, INP en CLS van /products?sort=price kunt vergelijken met /products?sort=popularity op hetzelfde pagina template, met dezelfde gebruikers, over dezelfde tijdsperiode.

Waarom query strings performance regressies veroorzaken

Query parameters zijn een van de meest voorkomende bronnen van onverklaarde performance variantie. Dit is waarom ze belangrijk zijn:

CDN caching gedrag

Standaard behandelen de meeste CDN's URL's met verschillende query strings als aparte cache vermeldingen. /search?q=boots en /search?q=sandals zijn twee verschillende cache keys. Als je zoekresultaten pagina honderden unieke queries per uur genereert, zal bijna geen enkel verzoek vanuit de cache geserveerd worden. Elke bezoeker doet een koude aanroep naar je origin server.

Sommige CDN's laten je specifieke parameters (zoals UTM tags) in de cache key negeren, maar die configuratie is makkelijk over het hoofd te zien. Als utm_source=email in je cache key is opgenomen, zal je e-mailcampagne landing page een cache hit rate van bijna nul hebben, en elke ontvanger krijgt een volledige server render in plaats van een gecachete respons. Dat is een veelvoorkomende en meetbare LCP piek.

Server-side rendering kosten

Filter- en sorteerparameters triggeren vaak de duurste database queries op een pagina. Een gewone productlijst op /products is misschien volledig gecachet. Dezelfde pagina op /products?color=red&size=M&brand=Nike&sort=price-asc kan een complexe query vereisen, een andere response vorm, of zelfs een complete re-render. Op pagina's die gefilterde resultaten niet efficiënt kunnen cachen, neemt de Time to First Byte toe, en LCP volgt.

Paginering is een andere consistente boosdoener. Pagina 1 van een lijst is meestal snel omdat het de standaardweergave is en agressief wordt gecachet. Pagina 10 of pagina 50 is zelden gecachet, vaak trager om te genereren en wordt vaak nooit getest. CoreDash brengt deze verschillen direct aan het licht, zonder dat je hoeft te raden.

Client-side gedrag getriggerd door parameters

Sommige query parameters veranderen de server response niet, maar veranderen wel welke JavaScript er draait bij het laden. A/B test variant parameters, affiliate tracking codes en referral tokens worden vaak gelezen door scripts die verschillende UI flows initialiseren, extra netwerkverzoeken afvuren of rendering vertragen terwijl ze wachten op experiment configuratie. Deze parameters kunnen meetbare INP kosten toevoegen en soms layout shifts veroorzaken als de variant zichtbare content verandert na de initial paint.

Veelvoorkomende patronen die het onderzoeken waard zijn

• UTM parameters op betaald verkeer: Bezoekers via advertenties landen vaak met ?utm_source=google&utm_medium=cpc&utm_campaign=.... Als je CDN deze opneemt in zijn cache key, krijgt betaald verkeer consistent tragere responses dan organisch verkeer.
• Zoekresultaten pagina's: Korte, populaire zoekopdrachten kunnen gecachet zijn. Long-tail of eerste zoekopdrachten zijn dat bijna nooit. Het vergelijken van ?q=nike met ?q=blue+trail+running+shoes+mens+size+11 laat vaak een meetbaar LCP verschil zien.
• Zware filtercombinaties: E-commerce categoriepagina's met meerdere actieve filters zijn duur om te renderen en zelden gecachet. Als je 75e percentiel LCP hoog is, zijn filtercombinaties een waarschijnlijke oorzaak.
• Paginering na pagina 1: Pagina 2 en verder zijn meestal trager en meer resource-intensief. Ze bevatten ook vaak dezelfde hero image of layout, maar zonder het voordeel van gecachete assets van een vorig bezoek.

Hoe deze dimensie te gebruiken in CoreDash

Selecteer Query String uit de dimensie picker in een willekeurig CoreDash rapport. De tabel toont elke unieke query string naast de LCP, INP, CLS en het aantal bezoeken. Sorteer op LCP om de traagste parametercombinaties te vinden, of sorteer op aantal bezoeken om de varianten met het meeste verkeer te vinden.

Combineer deze dimensie met de URL dimensie om je analyse te verfijnen tot een enkel pagina template voordat je de query string varianten vergelijkt. Die combinatie maakt het eenvoudig om te bevestigen of een performance probleem in de pagina zelf zit of in een specifiek parameter patroon.

De Query String dimensie valt onder de Page & Navigation categorie in CoreDash, naast dimensies zoals URL, Pathname en Navigation Type.