Core/Dash-dimensio: Laitetyyppi

Dimensio: Laitetyyppi (d)

Laitetyyppi-dimensio jakaa Real User Monitoring -datasi kahteen luokkaan: mobile ja desktop. Tämä on kaikista tärkein ensimmäinen suodatin suorituskyvyn tutkinnassa, sillä mobiili- ja työpöytäympäristöt ovat perustavanlaatuisesti erilaisia tietoteknisiä ympäristöjä. Eri suorittimet, eri verkkoyhteydet, eri viewport-koot ja eri selainmoottorit.

Jos tarkastelet yhdistettyjä Core Web Vitals -tuloksia suodattamatta niitä laitetyypin mukaan, lasket keskiarvon kahdesta populaatiosta, joilla ei ole juuri mitään yhteistä. Tuo keskiarvo on parhaimmillaankin harhaanjohtava.

Mobiilin suorituskykykuilu

Mobiililaitteet muodostavat noin 62 % maailmanlaajuisesta verkkoliikenteestä Statistan (2025) mukaan. Silti mobiili suoriutuu jatkuvasti huonommin kuin työpöytä. 2025 Web Almanacin mukaan vain 48 % mobiilisivustoista (origins) läpäisee kaikki kolme Core Web Vitals -mittaria, kun vastaava luku työpöydällä on 56 %. Se tarkoittaa 8 prosenttiyksikön eroa.

Kuilu johtuu siitä, että mobiililaitteilla on kolme rajoitetta, joita työpöytälaitteilla ei ole:

• Suorittimen kuristaminen (CPU throttling): Keskihintaisella Android-puhelimella on noin 3–5 kertaa vähemmän laskentatehoa kuin työpöytätietokoneella. JavaScript, jonka suorittaminen kestää työpöydällä 50 ms, voi viedä mobiililaitteella 200 ms, mikä työntää INP:n "hyvän" rajan yli.
• Verkon viive (network latency): Mobiiliyhteyksissä (4G/5G) on suuremmat pyyntö-vastausajat (RTT) ja enemmän vaihtelua kuin langallisissa yhteyksissä. Tämä kasvattaa TTFB:tä ja LCP:n Load Delay -vaihetta.
• Viewport-koko: Pienemmät näytöt muuttavat sitä, mikä elementti on LCP. Työpöydän hero-kuva saattaa kutistua tekstilohkon alapuolelle mobiilissa, mikä muuttaa optimointikohdetta täysin.

CoreDashin laitetyyppijakauma

CoreDash-projekteissa tyypillinen liikenteen jakautuminen on 65 % mobiililaitteille ja 35 % työpöydille. Verkkokauppasivustot painottuvat vielä vahvemmin mobiiliin (70–75 %), kun taas B2B SaaS -tuotteissa nähdään usein 50/50-jako tai jopa työpöytälaitteiden hallitsevuus.

Suorituskykykuilu CoreDash-datassa heijastaa maailmanlaajuista suuntausta. Mobiilin p75 LCP on keskimäärin 2,8 s, kun se työpöydällä on 1,9 s. INP:n kohdalla kuilu on vielä suurempi: mobiilin p75 on noin 220 ms, kun työpöytä pyörii 120 ms:n tuntumassa.

Mittarikohtainen analyysi

Largest Contentful Paint (LCP)

Mobiilin LCP on lähes poikkeuksetta huonompi kuin työpöydän. Ensisijainen syy on Load Delay: mobiiliselaimet löytävät LCP-kuvan myöhemmin, koska HTML:n latautuminen kestää kauemmin (suurempi TTFB) ja preload scanner kilpailee resursseista hitaammalla CPU:lla. Jos työpöytäsi LCP on alle 2,0 s mutta mobiili ylittää 3,0 s, syy on harvoin itse kuvatiedostossa. Kyse on toimitusputkesta (delivery pipeline).

Interaction to Next Paint (INP)

Tässä laitteiden välinen ero iskee kovimmin. JavaScript-tapahtumankäsittelijät (event handlers), jotka tuntuvat välittömiltä työpöydän i7-suorittimella, voivat tukkia main threadin yli 300 ms:n ajaksi Snapdragon 665:llä. Suodata mobiilin mukaan, lajittele INP-vaikutuksen mukaan, ja löydät juuri ne interaktiot, jotka rikkoutuvat oikeilla puhelimilla. Näen tätä jatkuvasti: kehittäjät testaavat MacBook Pro -koneilla ja julkaisevat interaktioita, joita on mahdoton käyttää laitteilla, joita 65 % heidän todellisista käyttäjistään kantaa mukanaan.

Cumulative Layout Shift (CLS)

Laitetyyppien väliset CLS-erot johtuvat yleensä responsiivisesta suunnittelusta. Mainospaikat, jotka varaavat tilaa työpöydällä, voivat romahtaa tai muuttaa kokoaan mobiililaitteella. Fonttien fallback-metriikat, jotka täsmäävät työpöydällä, aiheuttavat näkyviä siirtymiä pienemmissä viewporteissa. Verkkofontit renderöityvät eri tavalla mobiili- ja työpöytäselaimissa, ja fyysinen pikselitiheys vaikuttaa sub-pixel-pyöristyksiin.

Vianmäärityksen työnkulku

1. Aloita jokainen tutkimus laitesuodattimella: Ennen kuin katsot mitään muuta dimensiota, jaa data Laitetyypin mukaan. Jos kokonais-LCP on 2,5 s, saatat huomata työpöydän olevan 1,8 s ja mobiilin 3,1 s. Ongelma koskee tällöin yksinomaan mobiililaitteita.
2. Vertaa jakaumia, älä vain p75-arvoa: Tarkista good / needs improvement / poor -jakauma jokaiselle laitetyypille. Työpöytä, jossa on 85 % hyviä tuloksia (good), ja mobiili, jossa niitä on vain 45 %, kertovat aivan eri tarinan kuin pelkkä p75-arvo.
3. Yhdistä muihin dimensioihin: Kun olet eristänyt laitetyypin, lisää toinen suodatin. Laitetyyppi + Maa paljastaa, onko mobiilin suorituskykykuilu globaali vai keskittynyt alueille, joilla on hitaat verkot. Laitetyyppi + Navigation Type osoittaa, tallentuvatko mobiilin back-forward-navigoinnit välimuistiin oikein.

Nyrkkisäännöt kehittäjille

• Mobiilin LCP alle 2,5 s: Tämä on kynnysarvo, jota Google käyttää "hyvälle" (good) tulokselle. Jos työpöytäsi läpäisee testin mutta mobiili epäonnistuu, keskity Load Delayn (fetchpriority, preload) ja TTFB:n vähentämiseen (esim. edge-välimuisti, CDN).
• Mobiilin INP alle 200 ms: Testaa jokainen interaktiivinen toiminto oikealla keskitason Android-laitteella. Chrome DevTools -työkalujen suorittimen kuristus (CPU throttling 4x) simuloi tätä, mutta testaus oikealla laitteella on aina parempi.
• Älä koskaan optimoi vain työpöydälle: Jos mobiililiikenteesi ylittää 50 % (ja se lähes varmasti tekee niin), mobiililaitteiden suorituskyky on hakukonesijoitukseesi vaikuttava tekijä. Google käyttää sijoituksissa mobiililaitteiden CrUX-dataa.

Laitetyyppi ei ole mikään "kiva tietää" -suodatin. Se on ensimmäinen kysymys, jonka kysyt: "Onko tämä mobiili- vai työpöytäongelma?" Jokainen optimointipäätös perustuu tähän vastaukseen.