Core/Dash-dimensjon: Query String

Hva dimensjonen Query String fanger opp

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

De fleste verktøy for ytelsesovervåking fjerner query strings eller slår dem sammen til en enkelt URL-gruppe. CoreDash beholder dem intakte, 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 query strings forårsaker ytelsesregresjoner

Query-parametere er en av de vanligste kildene til uforklarlig ytelsesvarians. Her er grunnen til at de betyr noe:

CDN-caching-atferd

Som standard behandler de fleste CDN-er URL-er med forskjellige query strings som separate cache-oppføringer. /search?q=boots og /search?q=sandals er to distinkte cache-nøkler. Hvis siden din for søkeresultater genererer hundrevis av unike søk i timen, vil nesten ingen av disse forespørslene bli servert fra cache. Hver besøkende treffer opprinnelsesserveren din kaldt.

Noen CDN-er lar deg ignorere spesifikke parametere (som UTM-tagger) i cache-nøkkelen, men den konfigurasjonen er lett å overse. Hvis utm_source=email er inkludert i cache-nøkkelen din, vil e-postkampanjens landingsside ha en cache hit-rate nær null, og hver mottaker får en full server-rendering i stedet for et cachet svar. Det er en vanlig og målbar LCP-topp.

Kostnad ved server-side rendering

Filter- og sorteringsparametere utløser ofte de dyreste databaseforespørslene på en side. En enkel produktoversikt på /products kan være fullstendig cachet. Den samme siden på /products?color=red&size=M&brand=Nike&sort=price-asc kan kreve et komplekst søk, en annen form på responsen, eller til og med en komplett re-rendering. På sider som ikke kan cache filtrerte resultater effektivt, øker time to first byte, og LCP følger etter.

Paginering er en annen konsekvent synder. Side 1 av en oversikt er vanligvis rask fordi det er standardvisningen og caches aggressivt. Side 10 eller side 50 er sjelden cachet, ofte tregere å generere, og ofte aldri testet. CoreDash fremhever disse forskjellene direkte, uten at du trenger å gjette.

Klient-side-atferd utløst av parametere

Noen query-parametere endrer ikke serverresponsen, men endrer hvilken JavaScript som kjøres ved innlasting. A/B-testvariant-parametere, affiliate-sporingskoder og henvisningstokens blir ofte lest av skript som initialiserer ulike UI-flyter, utløser ytterligere nettverksforespørsler eller forsinker rendering mens de venter på eksperimentkonfigurasjon. Disse parameterne kan legge til målbar INP-kostnad og av og til forårsake layout shifts hvis varianten endrer synlig innhold etter 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 din CDN inkluderer disse i sin cache-nøkkel, vil betalt trafikk konsekvent få tregere responser enn organisk trafikk.
• Sider for søkeresultater: Korte, populære søk kan være cachet. Langhale-søk eller førstegangssøk 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: Kategori-sider for e-handel med flere aktive filtre er dyre å rendere og sjelden cachet. Hvis din 75. persentil LCP er høy, er filterkombinasjoner en sannsynlig bidragsyter.
• Paginering forbi side 1: Side 2 og utover er vanligvis tregere og mer ressurskrevende. De inneholder også ofte det samme heltebildet eller layoutet, men uten fordelen av cachede ressurser fra et tidligere besøk.

Slik bruker du denne dimensjonen i CoreDash

Velg Query String fra dimensjonsvelgeren i en hvilken som helst CoreDash-rapport. Tabellen vil vise hver unike query string sammen med dens LCP, INP, CLS og besøksantall. Sorter på LCP for å finne de tregeste parameterkombinasjonene, eller sorter på besøksantall for å finne variantene med mest trafikk.

Kombiner denne dimensjonen med URL-dimensjonen for å begrense analysen din til en enkelt sidemal før du sammenligner dens query string-varianter. Den kombinasjonen gjør det enkelt å bekrefte om et ytelsesproblem ligger i selve siden eller i et spesifikt parametermønster.

Dimensjonen Query String faller under Page & Navigation-kategorien i CoreDash, sammen med dimensjoner som URL, Pathname og Navigation Type.