Core/Dash Dimensie: Query String

Wat de Query String dimensie vastlegt

De Query String dimensie groepeert uw Core Web Vitals data op basis van 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, paginatie 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 u de LCP, INP en CLS van /products?sort=price kunt vergelijken met /products?sort=popularity op hetzelfde paginatemplate, 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. Hier is waarom ze belangrijk zijn:

CDN caching gedrag

Standaard behandelen de meeste CDN's URL's met verschillende query strings als aparte cache items. /search?q=boots en /search?q=sandals zijn twee afzonderlijke cache keys. Als uw zoekresultatenpagina honderden unieke zoekopdrachten per uur genereert, zal bijna geen enkele van die requests uit de cache worden geserveerd. Elke bezoeker raakt uw origin server koud.

Sommige CDN's laten u 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 uw cache key is opgenomen, zal uw e-mailcampagne landingspagina een near-zero cache hit rate hebben, en elke ontvanger krijgt een volledige server render in plaats van een gecachete response. 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 productvermelding op /products kan volledig gecachet zijn. Dezelfde pagina op /products?color=red&size=M&brand=Nike&sort=price-asc kan een complexe query, een andere response vorm of zelfs een complete re-render vereisen. Op pagina's die gefilterde resultaten niet efficiënt kunnen cachen, neemt de Time to First Byte toe, en LCP volgt deze.

Paginatie 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 wordt zelden gecachet, is vaak trager om te genereren en wordt regelmatig nooit getest. CoreDash brengt deze verschillen direct aan de oppervlakte, zonder dat u 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 netwerk requests afvuren of het renderen vertragen terwijl ze wachten op experiment configuratie. Deze parameters kunnen meetbare INP kosten toevoegen en af en toe 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 van advertenties landen vaak met ?utm_source=google&utm_medium=cpc&utm_campaign=.... Als uw CDN deze in zijn cache key opneemt, krijgt betaald verkeer consequent tragere responses dan organisch verkeer.
• Zoekresultatenpagina's: Korte, populaire zoekopdrachten kunnen worden gecachet. Long-tail of first-time zoekopdrachten bijna nooit. Het vergelijken van ?q=nike met ?q=blue+trail+running+shoes+mens+size+11 toont vaak een meetbaar LCP verschil.
• Zware filtercombinaties: E-commerce categoriepagina's met meerdere actieve filters zijn duur om te renderen en worden zelden gecachet. Als uw 75e percentiel LCP hoog is, zijn filtercombinaties een waarschijnlijke oorzaak.
• Paginatie voorbij 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 dimensiekiezer in een 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 het aantal bezoeken om de varianten met het meeste verkeer te vinden.

Combineer deze dimensie met de URL dimensie om uw analyse te beperken tot een enkel paginatemplate voordat u de query string varianten ervan 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.