Core/Dash -ulottuvuus: Query String

Mitä Query String -ulottuvuus tallentaa

Query String -ulottuvuus ryhmittelee Core Web Vitals -tietosi URL-osoitteessa sivuvierailun hetkellä olevan koko kyselymerkkijonon mukaan. 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-testien variantit ja suodatinyhdistelmät.

Useimmat suorituskyvyn seurantatyökalut poistavat kyselymerkkijonot tai yhdistävät ne yhdeksi URL-ryhmäksi. CoreDash pitää ne ennallaan, mikä tarkoittaa, että voit vertailla sivun /products?sort=price LCP-, INP- ja CLS-arvoja sivuun /products?sort=popularity samalla sivumallilla, samoilla käyttäjillä ja samalla aikavälillä.

Miksi kyselymerkkijonot aiheuttavat suorituskyvyn heikentymistä

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

CDN-välimuistin toiminta

Oletusarvoisesti useimmat CDN-verkot käsittelevät URL-osoitteita, joilla on eri kyselymerkkijonot, erillisinä välimuistimerkintöinä. /search?q=boots ja /search?q=sandals ovat kaksi eri välimuistiavainta. Jos hakutulossivusi luo satoja uniikkeja kyselyitä tunnissa, melkein mitään näistä pyynnöistä ei tarjota välimuistista. Jokainen vierailija kuormittaa alkuperäispalvelintasi kylmiltään.

Jotkin CDN-verkot antavat sinun sivuuttaa tietyt parametrit (kuten UTM-tunnisteet) välimuistiavaimessa, mutta tämä määritys on helppo unohtaa. 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äydellisen palvelinrenderöinnin välimuistista haetun vastauksen sijaan. Tämä on yleinen ja mitattavissa oleva LCP-piikki.

Palvelinpuolen renderöinnin kustannukset

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

Sivutus on toinen jatkuva ongelmien aiheuttaja. Luettelon sivu 1 on yleensä nopea, koska se on oletusnäkymä ja tallennetaan aggressiivisesti välimuistiin. Sivua 10 tai sivua 50 tallennetaan harvoin välimuistiin, niiden luominen on usein hitaampaa ja niitä testataan harvoin lainkaan. CoreDash tuo nämä erot esiin suoraan, ilman että sinun tarvitsee arvailla.

Parametrien käynnistämä asiakaspuolen toiminta

Jotkin kyselyparametrit eivät muuta palvelimen vastausta, mutta ne muuttavat sitä, mitä JavaScript-koodia suoritetaan latauksen yhteydessä. Komentosarjat, jotka alustavat erilaisia käyttöliittymäkulkuja, käynnistävät ylimääräisiä verkkopyyntöjä tai viivästyttävät renderöintiä odottaessaan kokeiluasetuksia, lukevat usein A/B-testien varianttiparametreja, kumppanuusseurantakoodeja ja suositustunnisteita. Nämä parametrit voivat lisätä mitattavissa olevaa INP-kustannusta ja joskus aiheuttaa asettelun siirtymiä, jos variantti muuttaa näkyvää sisältöä alkuperäisen maalauksen jälkeen.

Yleisiä tutkimisen arvoisia malleja

• UTM-parametrit maksetussa liikenteessä: Mainoksista tulevat vierailijat saapuvat usein osoitteeseen ?utm_source=google&utm_medium=cpc&utm_campaign=.... Jos CDN-verkkosi sisällyttää nämä välimuistiavaimeensa, maksettu liikenne saa jatkuvasti hitaampia vastauksia kuin orgaaninen liikenne.
• Hakutulossivut: Lyhyet, suositut kyselyt saatetaan tallentaa välimuistiin. Pitkän hännän (long-tail) tai ensimmäistä kertaa tehtäviä kyselyitä ei lähes koskaan tallenneta. ?q=nike vertaaminen ?q=blue+trail+running+shoes+mens+size+11 -kyselyyn osoittaa usein mitattavissa olevan LCP-eron.
• Raskaat suodatinyhdistelmät: Verkkokauppojen kategoria-sivut, joilla on useita aktiivisia suodattimia, ovat kalliita renderöidä ja niitä tallennetaan harvoin välimuistiin. Jos 75. prosenttipisteen LCP-arvosi on korkea, suodatinyhdistelmät ovat todennäköinen myötävaikuttaja.
• Sivutus sivun 1 jälkeen: Sivu 2 ja sitä seuraavat sivut ovat yleensä hitaampia ja resursseja vievämpiä. Ne sisältävät usein myös saman hero-kuvan tai asettelun, mutta ilman edellisen vierailun välimuistiin tallennettujen resurssien tuomaa etua.

Kuinka käyttää tätä ulottuvuutta CoreDashissa

Valitse Query String minkä tahansa CoreDash-raportin ulottuvuusvalitsimesta. Taulukko näyttää jokaisen uniikin kyselymerkkijonon sekä sen LCP-, INP- ja CLS-arvot ja vierailijamäärän. Lajittele LCP:n mukaan löytääksesi hitaimmat parametri-yhdistelmät tai lajittele vierailijamäärän mukaan löytääksesi eniten liikennettä saavat variantit.

Yhdistä tämä ulottuvuus URL-ulottuvuuteen rajataksesi analyysisi yhteen sivumalliin ennen sen kyselymerkkijonovarianttien vertailua. Tämä yhdistelmä tekee helpoksi vahvistaa, onko suorituskykyongelma itse sivussa vai tietyssä parametrimallissa.

Query String -ulottuvuus kuuluu CoreDashissa Page & Navigation -kategoriaan yhdessä ulottuvuuksien, kuten URL, Pathname ja Navigation Type, kanssa.