Core/Dash Dimension: Query String

Vad dimensionen Query String fångar upp

Dimensionen Query String grupperar din Core Web Vitals-data efter hela query-strängen som finns 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 query-strängar eller slår ihop dem till en enda URL-grupp. CoreDash håller dem intakta, vilket innebär att du kan jämföra LCP, INP och CLS för /products?sort=price med /products?sort=popularity på samma sidmall, med samma användare, under samma tidsperiod.

Varför query-strängar orsakar prestandaregressioner

Query-parametrar är en av de vanligaste orsakerna till oförklarlig prestandavariation. Här är anledningen till att de spelar roll:

Beteende för CDN-cachning

Som standard behandlar de flesta CDN:er URL:er med olika query-strängar som separata cacheposter. /search?q=boots och /search?q=sandals är två distinkta cachenycklar. Om din sökresultatsida genererar hundratals unika sökfrågor i timmen kommer nästan inga av dessa förfrågningar att serveras från cachen. Varje besökare träffar din ursprungsserver 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 din landningssida för e-postkampanjen att ha en cacheträffrekvens nära noll, och varje mottagare får en fullständig serverrendering istället för ett cachat svar. Det är en vanlig och mätbar LCP-spik.

Kostnad för rendering på serversidan

Filter- och sorteringsparametrar utlöser ofta de dyraste 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 databasfråga, en annorlunda svarsstruktur eller till och med en fullständig omrendering. På sidor som inte kan cacha filtrerade resultat effektivt ökar time to first byte, och LCP följer efter.

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

Klientbeteende som utlöses av parametrar

Vissa query-parametrar ändrar inte serversvaret utan ändrar vilken JavaScript som körs vid inläsning. Parametrar för A/B-testvarianter, affiliate-spårningskoder och värvningstokens läses ofta av skript som initierar olika UI-flöden, avfyrar ytterligare nätverksförfrågningar eller fördröjer renderingen i väntan på experimentkonfiguration. Dessa parametrar kan lägga till mätbara INP-kostnader och ibland orsaka layoutförskjutningar om varianten ändrar synligt innehåll efter den initiala renderingen.

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. Långa eller helt nya sökfrågor är nästan aldrig det. Att jämföra ?q=nike med ?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 sällan cachade. Om din 75:e percentil för LCP är hög är filterkombinationer en trolig bidragande orsak.
• Paginering bortom sida 1: Sida 2 och framåt är vanligtvis långsammare och mer resurskrävande. De innehåller dessutom ofta samma hero-bild eller layout, men utan fördelen av cachade tillgångar från ett tidigare besök.

Så 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 query-sträng tillsammans med dess LCP, INP, CLS och antal besök. Sortera efter LCP för att hitta de långsammaste parameterkombinationerna, eller sortera efter antal besök för att hitta varianterna med högst trafik.

Kombinera denna dimension med dimensionen URL för att avgränsa din analys till en enskild sidmall innan du jämför dess query-strängvarianter. 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 sorterar under kategorin Page & Navigation i CoreDash, tillsammans med dimensioner som URL, Pathname och Navigation Type.