Core/Dash -dimensio: Query String

Mitä Query String -dimensio tallentaa

Query String -dimensio ryhmittelee Core Web Vitals -datasi koko sen kyselymerkkijonon mukaan, joka on URL-osoitteessa sivuvierailun hetkellä. Tämä sisältää kaiken ?-merkin jälkeen: seurantaparametrit kuten utm_source=google, sivutuksen kuten page=2, lajittelujärjestykset kuten sort=price, hakukyselyt kuten q=running+shoes, A/B-testivariantit ja suodatinyhdistelmät.

Useimmat suorituskyvyn seurantatyökalut karsivat kyselymerkkijonot tai yhdistävät ne yhdeksi URL-ryhmäksi. CoreDash pitää ne koskemattomina, mikä tarkoittaa, että voit vertailla /products?sort=price ja /products?sort=popularity osoitteiden LCP-, INP- ja CLS-arvoja samassa sivumallissa, samoilla käyttäjillä, samalla ajanjaksolla.

Miksi kyselymerkkijonot aiheuttavat suorituskyvyn heikkenemistä

Kyselyparametrit ovat yksi yleisimmistä selittämättömän suorituskykyvaihtelun lähteistä. Tässä syy niiden tärkeyteen:

CDN-välimuistin toiminta

Oletuksena useimmat CDN:t käsittelevät URL-osoitteita eri kyselymerkkijonoilla erillisinä välimuistimerkintöinä. /search?q=boots ja /search?q=sandals ovat kaksi erillistä välimuistiavainta. Jos hakutulossivusi tuottaa satoja yksilöllisiä kyselyitä tunnissa, melkein mitään näistä pyynnöistä ei tarjoilla välimuistista. Jokainen vierailija kuormittaa alkuperäispalvelintasi kylmiltään.

Jotkut CDN:t sallivat tiettyjen parametrien (kuten UTM-tagien) ohittamisen välimuistiavaimessa, mutta tämä konfiguraatio on helppo jättää huomiotta. Jos utm_source=email sisällytetään välimuistiavaimeesi, sähköpostikampanjasi aloitussivun välimuistin osumaprosentti on lähellä nollaa, ja jokainen vastaanottaja saa täyden palvelinrenderöinnin välimuistitetun vastauksen sijaan. Tämä on yleinen ja mitattavissa oleva LCP-piikki.

Palvelinpuolen renderöinnin kustannus

Suodatin- ja lajitteluparametrit käynnistävät usein sivun kalleimmat tietokantakyselyt. Tavallinen tuotelistus osoitteessa /products voi olla täysin välimuistissa. Sama sivu osoitteessa /products?color=red&size=M&brand=Nike&sort=price-asc saattaa vaatia monimutkaisen kyselyn, erilaisen vastauksen muodon tai jopa täydellisen uudelleenrenderöinnin. Sivuilla, jotka eivät pysty välimuistittamaan suodatettuja tuloksia tehokkaasti, time to first byte kasvaa ja LCP seuraa sitä.

Sivutus on toinen johdonmukainen ongelmien aiheuttaja. Listauksen sivu 1 on yleensä nopea, koska se on oletusnäkymä ja sitä välimuistiteaan aggressiivisesti. Sivu 10 tai sivu 50 on harvoin välimuistissa, usein hitaampi luoda ja usein myös testaamaton. CoreDash tuo nämä erot esiin suoraan, ilman että sinun tarvitsee arvailla.

Parametrien laukaisema asiakaspuolen toiminta

Jotkut kyselyparametrit eivät muuta palvelimen vastausta, mutta ne muuttavat sitä, mitä JavaScriptiä suoritetaan latauksen yhteydessä. A/B-testivarianttien parametreja, kumppanuusohjelmien seurantakoodeja ja suosittelutokeneita lukevat usein skriptit, jotka alustavat erilaisia käyttöliittymäpolkuja, lähettävät ylimääräisiä verkkopyyntöjä tai viivästyttävät renderöintiä kokeilun konfiguraatiota odotettaessa. Nämä parametrit voivat lisätä mitattavissa olevan INP-kustannuksen ja ajoittain aiheuttaa layout shift -ongelmia, jos variantti muuttaa näkyvää sisältöä alkuperäisen piirron jälkeen.

Yleisiä tutkimisen arvoisia kaavoja

• UTM-parametrit maksetussa liikenteessä: Mainoksista tulevat vierailijat saapuvat usein osoitteilla ?utm_source=google&utm_medium=cpc&utm_campaign=.... Jos CDN:si sisällyttää nämä välimuistiavaimeen, maksettu liikenne saa johdonmukaisesti hitaampia vastauksia kuin orgaaninen liikenne.
• Hakutulossivut: Lyhyet, suositut kyselyt saattavat olla välimuistissa. Pitkän hännän tai ensimmäistä kertaa tehtävät kyselyt eivät melkein koskaan ole. Vertailtaessa ?q=nike ja ?q=blue+trail+running+shoes+mens+size+11 välillä näkyy usein mitattava LCP-ero.
• Raskaat suodatinyhdistelmät: Verkkokauppojen kategoria-sivut useilla aktiivisilla suodattimilla ovat kalliita renderöidä ja harvoin välimuistissa. Jos LCP:si 75. persentiili on korkea, suodatinyhdistelmät ovat todennäköinen syy.
• Sivutus sivun 1 jälkeen: Sivu 2 ja sitä seuraavat sivut ovat yleensä hitaampia ja resursseja vaativampia. Ne sisältävät usein myös saman hero-kuvan tai layoutin, mutta ilman aiemmalta vierailulta saatua hyötyä välimuistitetuista resursseista.

Kuinka käyttää tätä dimensiota CoreDashissa

Valitse Query String dimensionvalitsimesta missä tahansa CoreDash-raportissa. Taulukko näyttää jokaisen yksilöllisen kyselymerkkijonon sekä sen LCP-, INP- ja CLS-arvot ja vierailumäärän. Lajittele LCP:n mukaan löytääksesi hitaimmat parametriyhdistelmät, tai lajittele vierailumäärän mukaan löytääksesi suurimman liikenteen variantit.

Yhdistä tämä dimensio URL-dimensioon kaventaaksesi analyysisi yhteen sivumalliin ennen sen kyselymerkkijonovarianttien vertailua. Tämä yhdistelmä tekee helpoksi vahvistaa, onko suorituskykyongelma itse sivussa vai tietyssä parametrikaavassa.

Query String -dimensio kuuluu CoreDashin Page & Navigation -kategoriaan, yhdessä sellaisten dimensioiden kuten URL, Pathname ja Navigation Type kanssa.