Core/Dash-dimension: Query String

Vad dimensionen Query String fångar upp

Dimensionen Query String grupperar din Core Web Vitals-data efter hela frågesträngen som fanns i URL:en vid tidpunkten för sidbesöket. Det inkluderar allt efter ?: spårningsparametrar som utm_source=google, paginering som page=2, sorteringsordningar som sort=price, sökfrågor som q=running+shoes, A/B-testvarianter och filterkombinationer.

De flesta verktyg för prestandaövervakning rensar bort frågesträngar eller slår ihop dem till en enda URL-grupp. CoreDash behåller dem intakta, vilket innebär att du kan jämföra LCP, INP och CLS för /products?sort=price mot /products?sort=popularity på samma sidmall, med samma användare, under samma tidsperiod.

Varför frågesträngar orsakar prestandaregressioner

Query-parametrar är en av de vanligaste orsakerna till oförklarliga prestandavariationer. Här är varför de spelar roll:

Beteende för CDN-cachelagring

Som standard behandlar de flesta CDN:er URL:er med olika frågesträngar som separata cache-poster. /search?q=boots och /search?q=sandals är två distinkta cachenycklar. Om din sökresultatsida genererar hundratals unika sökfrågor per timme kommer nästan inga av dessa förfrågningar att serveras från cachen. Varje besökare träffar din ursprungsserver (origin) kallt.

Vissa CDN:er låter dig ignorera specifika parametrar (som UTM-taggar) i cachenyckeln, men den konfigurationen är lätt att missa. Om utm_source=email inkluderas i din cachenyckel kommer landningssidan för din e-postkampanj att ha en cache-träffsäkerhet nära noll, och varje mottagare får en fullständig server-rendering istället för ett cachat svar. Det är en vanlig och mätbar LCP-spik.

Kostnad för server-side rendering

Filter- och sorteringsparametrar utlöser ofta de mest krävande databasfrågorna på en sida. En vanlig produktlista på /products kan vara helt cachad. Samma sida på /products?color=red&size=M&brand=Nike&sort=price-asc kan kräva en komplex sökning, en annorlunda svarsstruktur eller till och med en fullständig omrendering. På sidor som inte effektivt kan cacha filtrerade resultat ökar time to first byte, och LCP följer med.

Paginering är en annan återkommande bov. Sida 1 i en lista är vanligtvis snabb eftersom det är standardvyn och cachas aggressivt. Sida 10 eller sida 50 cachas sällan, är ofta långsammare att generera och testas ofta aldrig. CoreDash lyfter fram dessa skillnader direkt, utan att du behöver gissa.

Klientbeteende som utlöses av parametrar

Vissa frågeparametrar ändrar inte serversvaret men ändrar däremot vilket JavaScript som körs vid laddning. Parametrar för A/B-testvarianter, koder för affiliatetracking och värvningstokens läses ofta av skript som initierar olika UI-flöden, skjuter iväg ytterligare nätverksförfrågningar eller fördröjer renderingen i väntan på experimentkonfiguration. Dessa parametrar kan lägga till en mätbar INP-kostnad och ibland orsaka layout shifts om varianten ändrar det synliga innehållet efter initial paint.

Vanliga mönster värda att undersöka

• UTM-parametrar på betald trafik: Besökare från annonser landar ofta med ?utm_source=google&utm_medium=cpc&utm_campaign=.... Om ditt CDN inkluderar dessa i sin cachenyckel får betald trafik konsekvent långsammare svar än organisk trafik.
• Sökresultatsidor: Korta, populära sökfrågor kan vara cachade. Long-tail eller förstagångssökningar är nästan aldrig det. Att jämföra ?q=nike mot ?q=blue+trail+running+shoes+mens+size+11 visar ofta en mätbar LCP-skillnad.
• Tunga filterkombinationer: Kategorisidor för e-handel med flera aktiva filter är dyra att rendera och cachas sällan. Om din 75:e percentil för LCP är hög är filterkombinationer en trolig orsak.
• Paginering bortom sida 1: Sida 2 och framåt är vanligtvis långsammare och mer resurskrävande. De innehåller också ofta samma hero-bild eller layout, men utan fördelen av cachade tillgångar från ett tidigare besök.

Så här använder du denna dimension i CoreDash

Välj Query String från dimensionsväljaren i valfri CoreDash-rapport. Tabellen kommer att visa varje unik frågesträng tillsammans med dess LCP, INP, CLS och besöksantal. Sortera på LCP för att hitta de långsammaste parameterkombinationerna, eller sortera på besöksantal för att hitta de varianter som har mest trafik.

Kombinera denna dimension med dimensionen URL för att avgränsa din analys till en enda sidmall innan du jämför dess varianter av frågesträngar. Den kombinationen gör det enkelt att bekräfta om ett prestandaproblem ligger i själva sidan eller i ett specifikt parametermönster.

Dimensionen Query String faller under kategorin Page & Navigation i CoreDash, tillsammans med dimensioner som URL, Pathname och Navigation Type.