Core/Dash-dimensjon: Query String

Hva Query String-dimensjonen fanger opp

Query String-dimensjonen grupperer dine Core Web Vitals-data etter den fulle spørrestrengen (query string) som var til stede i URL-en på tidspunktet for sidebesøket. Det inkluderer alt etter ?: sporingsparametere som utm_source=google, paginering som page=2, sorteringsrekkefølger som sort=price, søkespørringer som q=running+shoes, A/B-testvarianter og filterkombinasjoner.

De fleste verktøy for ytelsesovervåking fjerner spørrestrenger eller slår dem sammen til en enkelt URL-gruppe. CoreDash beholder dem intakt, noe som betyr at du kan sammenligne LCP, INP og CLS for /products?sort=price med /products?sort=popularity på den samme sidemalen, med de samme brukerne, over den samme tidsperioden.

Hvorfor spørrestrenger forårsaker ytelsesregresjoner

Spørreparametere er en av de vanligste årsakene til uforklarlige variasjoner i ytelse. Her er hvorfor de er viktige:

CDN-bufringsatferd

Som standard behandler de fleste CDN-er URL-er med forskjellige spørrestrenger som separate buffer-oppføringer (cache entries). /search?q=boots og /search?q=sandals er to distinkte buffernøkler. Hvis siden for søkeresultater genererer hundrevis av unike spørringer i timen, vil nesten ingen av disse forespørslene bli servert fra bufferen. Hver besøkende treffer opprinnelsesserveren (origin server) din kaldt.

Noen CDN-er lar deg ignorere spesifikke parametere (som UTM-tagger) i buffernøkkelen, men den konfigurasjonen er lett å overse. Hvis utm_source=email er inkludert i buffernøkkelen din, vil e-postkampanjens landingsside ha en treffrate for bufferen på nær null, og hver mottaker får en full servergjengivelse i stedet for en bufret respons. Det er en vanlig og målbar LCP-topp.

Kostnad for server-side rendering

Filter- og sorteringsparametere utløser ofte de mest krevende databasespørringene på en side. En vanlig produktoppføring på /products kan være fullstendig bufret. Den samme siden på /products?color=red&size=M&brand=Nike&sort=price-asc kan kreve en kompleks spørring, en annerledes responsform, eller til og med en fullstendig re-gjengivelse (re-render). På sider som ikke kan bufre filtrerte resultater effektivt, øker Time to First Byte, og LCP følger etter.

Paginering er en annen konsekvent synder. Side 1 av en oppføring er vanligvis rask fordi det er standardvisningen og bufres aggressivt. Side 10 eller side 50 er sjelden bufret, ofte tregere å generere, og ofte aldri testet. CoreDash synliggjør disse forskjellene direkte, uten at du trenger å gjette.

Klient-side-atferd utløst av parametere

Noen spørreparametere endrer ikke serverresponsen, men de endrer hvilken JavaScript som kjøres ved innlasting. Parametere for A/B-testvarianter, affiliate-sporingskoder og henvisningstokener (referral tokens) leses ofte av skript som initialiserer forskjellige UI-flyter, avfyrer ekstra nettverksforespørsler eller forsinker gjengivelsen mens de venter på eksperimentkonfigurasjonen. Disse parameterne kan legge til målbar INP-kostnad og av og til forårsake Cumulative Layout Shift hvis varianten endrer synlig innhold etter innledende opptegning (initial paint).

Vanlige mønstre verdt å undersøke

• UTM-parametere på betalt trafikk: Besøkende fra annonser lander ofte med ?utm_source=google&utm_medium=cpc&utm_campaign=.... Hvis CDN-en din inkluderer disse i buffernøkkelen sin, får betalt trafikk konsekvent tregere responser enn organisk trafikk.
• Sider for søkeresultater: Korte, populære spørringer kan være bufret. Langhalespørringer (long-tail) eller førstegangsspørringer er nesten aldri det. Å sammenligne ?q=nike mot ?q=blue+trail+running+shoes+mens+size+11 viser ofte en målbar LCP-forskjell.
• Tunge filterkombinasjoner: Kategorisider for e-handel med flere aktive filtre er ressurskrevende å gjengi og sjelden bufret. Hvis din 75. persentil LCP er høy, er filterkombinasjoner en sannsynlig bidragsyter.
• Paginering utover side 1: Side 2 og utover er vanligvis tregere og mer ressurskrevende. De inneholder også ofte det samme heltebildet (hero image) eller oppsettet, men uten fordelen av bufrede ressurser fra et tidligere besøk.

Hvordan bruke denne dimensjonen i CoreDash

Velg Query String fra dimensjonsvelgeren i en hvilken som helst CoreDash-rapport. Tabellen vil vise hver unike spørrestreng ved siden av dens LCP, INP, CLS og besøkstall. Sorter etter LCP for å finne de tregeste parameterkombinasjonene, eller sorter etter besøkstall for å finne variantene med mest trafikk.

Kombiner denne dimensjonen med URL-dimensjonen for å avgrense analysen din til en enkelt sidemal før du sammenligner variantene av spørrestrenger. Den kombinasjonen gjør det enkelt å bekrefte om et ytelsesproblem ligger i selve siden eller i et spesifikt parametermønster.

Query String-dimensjonen faller inn under kategorien Side og navigasjon (Page & Navigation) i CoreDash, sammen med dimensjoner som URL, Pathname og Navigation Type.