Core/Dash-dimension: Query String

Hvad Query String-dimensionen registrerer

Query String-dimensionen grupperer dine Core Web Vitals-data efter den fulde forespørgselsstreng (query string), der er til stede i URL'en på tidspunktet for sidebesøget. Det inkluderer alt efter ?: sporingsparametre som utm_source=google, paginering som page=2, sorteringsrækkefølger som sort=price, søgeforespørgsler som q=running+shoes, A/B-testvarianter og filterkombinationer.

De fleste værktøjer til overvågning af performance fjerner query strings eller samler dem i en enkelt URL-gruppe. CoreDash bevarer dem intakte, hvilket betyder, at du kan sammenligne LCP, INP og CLS for /products?sort=price med /products?sort=popularity på den samme sideskabelon, med de samme brugere og over den samme tidsperiode.

Hvorfor query strings forårsager performance-regressioner

Query-parametre er en af de mest almindelige kilder til uforklarlig variation i performance. Her er grunden til, at de betyder noget:

CDN-cachingadfærd

Som standard behandler de fleste CDN'er URL'er med forskellige query strings som separate cache-poster. /search?q=boots og /search?q=sandals er to adskilte cache-nøgler. Hvis din side med søgeresultater genererer hundredvis af unikke forespørgsler i timen, vil næsten ingen af disse anmodninger blive serveret fra cachen. Hver besøgende rammer din origin-server koldt.

Nogle CDN'er lader dig ignorere specifikke parametre (som UTM-tags) i cache-nøglen, men den konfiguration er let at overse. Hvis utm_source=email er inkluderet i din cache-nøgle, vil din e-mailkampagnes landingsside have en cache hit-rate tæt på nul, og hver modtager får en fuld server-rendering i stedet for et cachet svar. Det er en almindelig og målbar LCP-stigning.

Omkostninger ved server-side rendering

Filter- og sorteringsparametre udløser ofte de dyreste databaseforespørgsler på en side. En almindelig produktliste på /products kan være fuldt cachet. Den samme side på /products?color=red&size=M&brand=Nike&sort=price-asc kan kræve en kompleks forespørgsel, en anden svarstruktur eller endda en komplet gen-rendering. På sider, der ikke kan cache filtrerede resultater effektivt, stiger time to first byte, og LCP følger med.

Paginering er en anden konsekvent synder. Side 1 af en liste er normalt hurtig, fordi det er standardvisningen og caches aggressivt. Side 10 eller side 50 caches sjældent, er ofte langsommere at generere og testes ofte aldrig. CoreDash synliggør disse forskelle direkte, uden at du behøver at gætte.

Client-side adfærd udløst af parametre

Nogle query-parametre ændrer ikke server-svaret, men ændrer i stedet, hvilken JavaScript der køres ved indlæsning. A/B-testvariantparametre, affiliate-sporingskoder og henvisningstokens læses ofte af scripts, der initialiserer forskellige UI-forløb, affyrer yderligere netværksanmodninger eller forsinker renderingen, mens de venter på eksperimentkonfiguration. Disse parametre kan tilføje målbare INP-omkostninger og af og til forårsage layout shifts, hvis varianten ændrer synligt indhold efter initial paint.

Almindelige mønstre, der er værd at undersøge

• UTM-parametre på betalt trafik: Besøgende fra annoncer lander ofte med ?utm_source=google&utm_medium=cpc&utm_campaign=.... Hvis dit CDN inkluderer disse i sin cache-nøgle, får betalt trafik konsekvent langsommere svar end organisk trafik.
• Sider med søgeresultater: Korte, populære forespørgsler kan være cachede. Long-tail eller førstegangsforespørgsler er det næsten aldrig. En sammenligning af ?q=nike med ?q=blue+trail+running+shoes+mens+size+11 viser ofte en målbar LCP-forskel.
• Tunge filterkombinationer: E-handelskategorisider med flere aktive filtre er dyre at rendere og sjældent cachede. Hvis din 75. percentil LCP er høj, er filterkombinationer en sandsynlig bidragyder.
• Paginering ud over side 1: Side 2 og frem er normalt langsommere og mere ressourcekrævende. De indeholder også ofte det samme hero-billede eller layout, men uden fordelen af cachede ressourcer fra et tidligere besøg.

Sådan bruger du denne dimension i CoreDash

Vælg Query String i dimensionsvælgeren i enhver CoreDash-rapport. Tabellen vil vise hver unik query string sammen med dens LCP, INP, CLS og besøgsantal. Sorter efter LCP for at finde de langsommeste parameterkombinationer, eller sorter efter besøgsantal for at finde de varianter, der har mest trafik.

Kombiner denne dimension med URL-dimensionen for at indsnævre din analyse til en enkelt sideskabelon, før du sammenligner dens query string-varianter. Den kombination gør det nemt at bekræfte, om et performanceproblem ligger i selve siden eller i et specifikt parametermønster.

Query String-dimensionen hører under kategorien Page & Navigation i CoreDash sammen med dimensioner som URL, Pathname og Navigation Type.