CoreDash-ulottuvuus: Browser

Ulottuvuus: Browser (browser)

Browser-ulottuvuus ryhmittelee suorituskykydataa asiakkaan lähettämän User Agent -merkkijonon perusteella. Tämän avulla voit tarkastella Core Web Vitals -suorituskykyä sovellustasi renderöivän ohjelmiston (esim. Chrome, Firefox, Safari, Edge, Samsung Internet) näkökulmasta.

Browser-ulottuvuus eristää ohjelmistorajoitukset, renderöintimoottoreiden erot (Blink, Gecko, WebKit) ja kolmannen osapuolen skriptien yhteensopivuuden.

RUM vs. CrUX

Datan lähteen ymmärtäminen on tärkeää tarkalle tekniselle analyysille.

• CrUX (Chrome User Experience Report): Tämä tietojoukko kerää dataa yksinomaan Chrome-käyttäjiltä (ja joistakin Chromium-pohjaisista selaimista), jotka ovat antaneet siihen luvan. Se jättää huomiotta Firefox- (Gecko-moottori) ja Safari-liikenteen (WebKit-moottori).
• CoreDash RUM: Kerää dataa jokaisesta selaimesta, joka suorittaa JavaScript-koodinpätkän.

Monilla verkkosivustoilla muut kuin Chrome-selaimet edustavat 30–50 % liikenteestä. Pelkkään CrUX-dataan luottaminen luo sokean pisteen: optimoit sivustoa Googlen V8-moottorille ja unohdat SpiderMonkey- (Firefox) ja JavaScriptCore-moottorit (Safari), joita suuri osa yleisöstäsi käyttää.

Metriikkakohtainen diagnostiikka

Eri selainmoottorit hallitsevat resursseja, kääntävät JavaScriptiä ja laskevat asettelun geometriaa eri tavoin. Käytä tätä ulottuvuutta moottorikohtaisten vikojen paikantamiseen.

Interaction to Next Paint (INP)

INP-ongelmat korreloivat suoraan selaimen JavaScript-moottorin tehokkuuden ja main-thread-aikataulutuksen kanssa.

• Firefox (SpiderMonkey): Firefox käsittelee tehtävien priorisointia eri tavalla kuin Chrome. Raskas tapahtumankäsittelijä (event listener), joka läpäisee testit Chromessa, saattaa aiheuttaa huomattavaa input delayta Firefoxissa johtuen eroista siinä, miten main thread antaa tilaa (yield).
• Safari (JavaScriptCore): osoittaa usein erilaista käyttäytymistä "napautusviiveen" (tap latency) suhteen mobiililaitteilla. Hydration-logiikka, joka tuntuu välittömältä Androidilla (Chrome), voi aiheuttaa viiveitä iOS:llä erilaisten tapahtumien etenemismallien vuoksi.

Largest Contentful Paint (LCP)

LCP-erot kertovat yleensä ominaisuuksien puutteesta tai nykyaikaisten optimointi-API:en tuen puutteesta.

• Format Negotiation: Jos Chrome raportoi nopean LCP:n, mutta Firefox laahaa jäljessä, tarkista kuvamuotostrategiasi. Saatat tarjota AVIF-kuvia Chromelle, mutta käyttää suurempia JPEG-kuvia vanhemmille selaimille, joista puuttuu tuki.
• Priority Hints: Chrome noudattaa aggressiivisesti määritettä fetchpriority="high". Selaimet, jotka jättävät tämän määritteen huomiotta, käsittelevät LCP-resurssia vakioprioriteetilla, mikä kasvattaa keinotekoisesti Load Delayta.
• Connection Protocols: Edge ja Firefox saattavat neuvotella HTTP/3 (QUIC) -yhteydet eri tavalla yritys- tai rajoitetuissa verkkoympäristöissä, mikä vaikuttaa LCP:n TTFB-komponenttiin.

Cumulative Layout Shift (CLS)

Renderöintimoottorit laskevat pikseligeometrian käyttämällä erilaisia alipikselilogiikoita.

• Font Rendering (Gecko vs. Blink): Firefox (Gecko) ja Chrome (Blink) renderöivät fonttien perusviivat (baselines) ja merkkivälin (tracking) hieman eri tavalla. Jos et täsmäytä fallback-fonttimetriikkaasi täydellisesti, tekstilohko muuttaa kokoaan, kun web font latautuu, mikä aiheuttaa siirtymän toisessa selaimessa mutta ei toisessa.
• Scrollbar Reservation: Windows-selaimet (Edge/Firefox/Chrome) varaavat fyysisen tilan vierityspalkeille, kun taas macOS-selaimet näyttävät ne sisällön päällä. Tämä ero aiheuttaa usein leveyteen perustuvia asettelun siirtymiä, jotka ovat näkymättömiä kehityksen aikana Macilla, mutta näkyviä Windows-käyttäjille.

Työnkulku: Moottorikohtaisten heikkenemisten eristäminen

Tämän ulottuvuuden ensisijainen käyttötarkoitus on "moottorin validointi" (Engine Validation).

• Tunnista poikkeama: Järjestä Browser-taulukkosi Impact- tai Volume-sarakkeen mukaan. Etsi tietty selain (esim. Firefox Mobile), jolla on huomattavasti huonompi tulos kuin baseline-selaimella (Chrome Mobile).
• Varmista ympäristö: Tarkista, liittyykö ongelma tiukasti selaimeen vai selaimen ja OS:n yhdistelmään (esim. Edge Androidilla vs. Edge Windowsilla).
• Debuggaus: Jos Edge on hidas mutta Chrome on nopea (molemmat käyttävät Blinkiä), tutki kolmannen osapuolen laajennuksia tai Edge-käyttäjille tyypillisiä yritysturvaohjelmistoja, jotka injektoivat skriptejä DOM-puuhun. Jos Firefox on hidas, auditoi CSS-tyylisi epästandardien ominaisuuksien tai layout thrashingin varalta, jota Gecko rankaisee raskaammin kuin Blink.

Vanhat ja upotetut selaimet

Käytä Browser-ulottuvuutta tunnistamaan "pitkän hännän" (Long Tail) suorituskykyrasitteet.

In-App-selaimet: Instagramin, LinkedInin tai Facebookin liikenne ajetaan usein rajoitetuissa WebView-näkymissä, jotka käyttäytyvät eri tavalla kuin natiivi mobiiliselain.

Vanhat versiot: Saatat löytää liikennettä vanhentuneista selainversioista. Jos nämä aiheuttavat korkean INP:n, määritä build-työkalusi (Babel/PostCSS) joko tarjoamaan tarvittavat polyfillit tai, jos määrä on merkityksetön, tee strateginen päätös lopettaa tuki bundle-koon pienentämiseksi nykyaikaisille käyttäjille.