Core/Dash Dimension: Query String

Hvad Query String-dimensionen fanger

Query String-dimensionen grupperer dine Core Web Vitals-data efter den fulde 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 performance-varians. Her er hvorfor de har betydning:

CDN caching-adfæ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 forskellige cache-nøgler. Hvis din søgeresultatside 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 landingssiden for din e-mailkampagne have en cache hit rate på næsten 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 er muligvis 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 genindlæsning. På sider, der ikke effektivt kan cache filtrerede resultater, 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 er sjældent cachet, ofte langsommere at generere og bliver ofte aldrig testet. 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 serverens svar, men ændrer 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 rendering, mens der ventes på eksperimentkonfiguration. Disse parametre kan tilføje målbare INP-omkostninger og kan lejlighedsvis 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 svartider end organisk trafik.
• Søgeresultatsider: 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-handels-kategorisider med flere aktive filtre er dyre at rendere og sjældent cachet. Hvis din 75. percentil LCP er høj, er filterkombinationer en sandsynlig bidragyder.
• Paginering efter side 1: Side 2 og derefter er normalt langsommere og mere ressourcekrævende. De indeholder ofte også det samme hero-billede eller layout, men uden fordelen af cachede aktiver fra et tidligere besøg.

Sådan bruger du denne dimension i CoreDash

Vælg Query String fra dimensionsvælgeren i en hvilken som helst CoreDash-rapport. Tabellen vil vise hver unik query string sammen med dens LCP, INP, CLS og besøgsantal. Sortér efter LCP for at finde de langsommeste parameterkombinationer, eller sortér efter besøgsantal for at finde varianterne med højest trafik.

Kombinér denne dimension med dimensionen URL 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 performance-problem 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.