Google julkaisi viime vuonna Page experience -nimisen päivityksen. Sen myötä monien huulille on noussut kirjainyhdistelmä CWV eli Core Web Vitals. Lue tästä blogikirjoituksesta, mitä Core Web Vitals tarkoittaa, mitä väliä niillä on, miten näitä metriikoita mitataan sekä mitä sivustojen ylläpitäjien tulisi tehdä parantaakseen sivustoaan näiden mittareiden valossa.
Miksi Core Web Vitals on tärkeä asia?
Mitä ovat Largest Contentful Paint, First Input Delay ja Cumulative Layout Shift?
Core Web Vitals: Miten niitä mitataan?
Core Web Vitals: Miten niitä kehitetään?
Mitä ovat Core Web Vitals?
Core Web Vitals on osa laajempaa Googlen lanseeraamaa Web Vitals -aloitetta. Web Vitalsien pyrkimyksenä on määritellä universaalit laatumittarit verkkosivustojen käyttäjäkokemukselle. Googlen oman ilmoituksen mukaan sen tavoitteena on luoda mittarit, jotka ovat yleistajuiset ja sopivat niin ohjelmoijille, markkinoijille kuin sivustojen ylläpitäjillekin.
Core Web Vitals, kuten nimi kertoo, määrittelee mittareista kaikkein tärkeimmät. Core Web Vitals eli lyhennettynä CWV oli osa Googlen Page Experience -algoritmipäivitystä, joka julkaistiin toukokuussa 2021. Google kertoi päivityksestä jo vuotta ennen sen julkaisua. Sitä pidettiin merkkinä asian tärkeydestä, sillä Google vain harvoin tiedottaa algoritmipäivityksistään etukäteen.
Core Web Vitals -mittareita on kolme: Largest Contentful Paint (LCP), First Input Delay (FID) ja Cumulative Layout Shift (CLS). Google on määritellyt kaikille mittareille hyvän arvon, johon pääseminen tulisi olla sivuston ylläpitäjien tavoitteena hyvän käyttäjäkokemuksen turvaamiseksi. Kaikki metriikat selitetään alla tarkemmin, mutta tässä yksinkertaistettuna, mitä ne tarkoittavat:
- LCP: Latausnopeus eli kuinka nopeasti sivu latautuu käyttäjälle
- FID: Viive (interaktiosta komennon suorittamiseen) eli kuinka nopeasti sivu alkaa toteuttaa käyttäjän komentoa
- CLS: Visuaalinen stabiliteetti eli kuinka hyvin sivun elementit pysyvät mielekkäillä paikoilla sivua käytettäessä
Miksi Core Web Vitals on tärkeä asia?
Page Experience -algoritmipäivityksen taustalla oli tieto siitä, että käyttökokemus on enenevissä määrin tärkeää. Mobiililaitteiden ja -yhteyksien yleistyessä niin sivuston latausnopeus kuin käyttäjäystävällisyys ovat vielä merkityksellisempiä kuin ennen. Tämän Google oli jo aiemmin huomioinut muun muassa palkitsemalla hakutuloksissa sivuja, joilla on hyvä latausnopeus ja mobiilikokemus. Page experience -päivitys järjesti Core Web Vitalsit sekä muut käytettävuuteen liittyvät ominaisuudet (kuten mobiiliystävällisyys, HTTPS) saman sateenvarjon alle. Päivitys julkaistiin toukokuussa 2021.
Page experience -päivityksen jälkeen CWV-metriikat ovat vaikuttaneet sijoituksiin mobiililaitteilla. Vuoden 2022 alussa Google tiedotti, että se laajentaa päivitystä siten, että CWV-metriikoista tulee sijoituksiin vaikuttava tekijä (ns. ranking factor) myös desktop- eli pöytätietokoneilla. Deskaripäivitys julkaistiin helmi-maaliskuun aikana 2022.
Core Web Vitals -metriikoiden ymmärtäminen on tärkeää hakukoneoptimoijille, sillä niillä on suora vaikutus sijoituksiin. Asiaa ei kuitenkaan tulisi jättää vain hakukoneoptimoijien harteille, sillä sivuston nopeus ja käytettävyys ovat mitä suuremmassa määrin koko organisaation asioita. Jos sivusto on hidas ja sen tarjoama käyttäjäkokemus huono, kaikkoavat käyttäjät eikä heitä ole helppoa saada palaamaan.
Lukuisat tutkimukset ovat osoittaneet sen, että hitaasti latautuva sivusto tappaa konversiot.
Mitä ovat Largest Contentful Paint, First Input Delay ja Cumulative Layout Shift?
Core Web Vitalseihin kuuluu kolme metriikkaa: Largest Contentful Paint (LCP), First Input Delay (FID) sekä Cumulative Layout Shift (CLS).
Largest Contentful Paint (LCP) mittaa aikaa, joka kuluu siihen, että sivun suurin elementti on ladattu. Vielä vähän teknisemmin selitettynä LCP määrittää ajan, joka kuluu sivun suurimman viewportissa olevan kuva- tai tekstielementin renderöintiin. Hyvä LCP-arvo on 2,5 sekuntia tai alle.
Google perustelee kyseisen mittarin valintaa käyttäjäkeskeisyydellä, ja käyttäjäkeskeinen mittari se onkin. Kun käyttäjä tulee sivulle ja näkee heti keskeisimpien kuva- tai tekstielementtien latautuvan, syntyy luottamus, että ahaa tämä sivu toimii ja sille latautuu mielekästä sisältöä. Siksi se on käyttäjän näkökulmasta parempi mittari kuin muutamat muut latausnopeutta mitanneet metriikat “Load”, “DOMContentLoaded” tai “First Contentful Paint”.
First Input Delay (FID) puolestaan mittaa aikaa käyttäjän ensimmäisestä interaktiosta siihen, kun selain voi alkaa käsitellä tätä tapahtumaa. Hyvä FID-tulos on alle 100 millisekuntia.
First Input Delay tapahtuu usein First Contentful Paintin (FCP) ja Time-to-Interactiven (TTI) välissä, eli käytännössä sinä hetkenä, kun käyttäjä jo näkee sivulla jotain minkä kanssa olla vuorovaikutuksessa, mutta käyttäjän pyyntö ei lähde heti käsittelyyn, koska taustalla pääsäie (engl. main thread) suorittaa muita komentoja. Tällainen tilanne sattuu vaikkapa silloin, kun käyttäjä näkee sivulla linkin tai painikkeen ja klikkaa sitä, mutta klikkikomento ei lähde heti käsittelyyn, sillä pääsäie suorittaa vielä muita komentoja. Tästä syntyy käyttäjälle vaikutelma viiveestä.
Cumulative Layout Shift (CLS) mittaa visuaalista stabiliteettia eli yksinkertaistettuna sitä, kuinka paljon sivun elementit liikahtavat tai vaihtavat paikkaa sivua käytettäessä. CLS:ää mitataan ns. CLS scorella. Hyväksi katsotaan tulos, joka on pienempi kuin 0,1. (Google määrittelee laskentatavan CLS:n mittaamiselle web.dev-sivustollaan – yksinkertaistettuna siihen vaikuttaa se, kuinka suuria liikahtavat elementit ovat ja kuinka paljon ne liikahtavat.)
CLS on käyttäjän näkökulmasta hyvä mittari, sillä sivustolla yllättävästi hypähtävät tai liikahtavat elementit ovat hämmentäviä, turhauttavia ja voivat johtaa myös harhaklikkauksiin. Tyypillinen esimerkki CLS:n syntymisestä on tilanne, jossa käyttäjä selaa sivua alaspäin esimerkiksi artikkelia lukiessaan ja yhtäkkiä keskelle artikkelia pompsahtaa mainos, joka samalla puskee tekstin ylöspäin.
Core Web Vitals: Miten niitä mitataan?
Google erottaa toisistaan kaksi erilaista mittaamisen tapaa. CWV-metriikoista voidaan saada ns. laboratoriodataa (lab data) tai kenttädataa (field data). Laboratoriodata kertoo, miten hypoteettiset käyttäjät kokevat sivuston. Sitä käytetään silloin, kun muutoksia suunnitellaan ja kun oikeaa kenttädataa ei ole saatavilla. Laboratoriodata koostuu laskennallisista arvoista ja arvioi saamansa tiedon valossa sitä, miten sivusto suoriutuu tietyissä olosuhteissa. Kenttädata puolestaan viittaa dataan, jota kerätään oikeilta käyttäjiltä. Kenttädata kertoo, miten sivusto tosiasiallisesti suoriutuu. Sitä voidaan kerätä vasta, kun muutokset sivustolla on toteutettu ja käyttäjät pääsevät sivustolle.
Niin laboratorio- kuin kenttädatallekin on paikkansa, kun sivuston nopeutta ja käytettävyyttä tarkkaillaan ja kehitetään. Alla on esitelty joukko työkaluja, joita voi käyttää CWV:n mittaamiseen ja kehitystyöhön.
Kenttätyökalut
Google nimittää kenttätyökaluja myös nimellä RUM eli real-user monitoring tools. Niistä saa oikeaa käyttäjädataa.
Search Console, joka mittaa sivuston liikennettä ja performanssia, sisältää Core Web Vitals -osion. Search Consolen data perustuu ns. CrUX:in kenttädataan (CrUX field data). Search Consolen datan etuna on se, että se niputtaa yhteen urlijoukkoja, jotka kärsivät samasta ongelmasta. Search Console onkin oiva paikka yleiskuvan luomiseen sivuston nopeudesta ja käytettävyydestä. Se näyttää aikajanalla hyvien (good), kehitystä kaipaavien (needs improvement) ja huonojen (poor) sivujen määrän sekä identifioi, minkä CWV-metriikan kanssa sivustolla on ongelmia. Search Console ei kerro jokaisesta ongelmallisesta urlista, vaan antaa joukon esimerkkiurleja, kun se huomauttaa ongelmasta. Search Consolesta kannattaa tarkastaa sivuston tilanne ja ryhtyä tutkimaan ongelmia tarkemmin muilla työkaluilla, kuten Page Speed Insights -testillä.
Page Speed Insights -testi on hyvä työkalu CWV-metriikoiden ja kehitysehdotusten tutkimiseen sivutasolla. Testi antaa paitsi tiedot suoriutumisesta eri CWV-metriikoiden valossa, myös selkeitä kehitysehdotuksia, joita toteuttamalla suoriutumista voi parantaa.
Sivustojen ylläpitäjien kannattaa myös hyödyntää Chrome User Experience Reportia eli CrUX-raportin dataa, johon edelläkin viitattiin. CrUX kerää dataa Big Queryyn ja sitä voi tuoda myös Datastudion dashboardeille. Myös Page Speed Insights -testi tarjoilee CrUX-dataa laboratiodatan lisäksi. CrUX on Googlen Chrome-selaimen käyttäjiltä kerättyä kenttädataa. Data on origin-tasolla, mutta myös yksittäisistä urleista saattaa löytyä tietoa, jos sivustolla on riittävästi liikennettä. CrUX-raportti sopii kaikille sivustoille, myös niille, jotka keräävät omaa kenttädataa, sillä sen avulla saa myös vertailudataa muihin sivustoihin. Huomaa kuitenkin, että jos sivuston liikennemäärä on hyvin vähäinen, se ei todennäköisesti ole saatavilla CrUX-tietokannassa.
Laboratoriotyökalut
Laboratoriotyökaluista tunnetuin lienee Lighthouse. Lighthouse antaa jäsenneltyjä suosituksia yksittäisten sivujen parantamiseen.
Lighthouse User Flows -lisäosa mahdollistaa sivun testaamisen koko session ajan. Sen avulla voin tehdä raportteja siitä, miten sivu käyttäytyy sitä ladattaessa ja miten se vastaa käyttäjän komentoihin.
Lighthouse-CI on user flows -työkaluun liittyvä työkalu koodareille, joka mahdollistaa Lighthouse-datan keräämisen silloinkin, kun saittia työstetään ja päivitetään.
Lighthousen lisäksi Chrome-selaimen DevTools on hyödyllinen lisä. DevToolsin Performance-välilehdellä voi seurata kaikkia sivulla tapahtuvia aktiviteetteja sen käynnistyessä tai niin kauan kuin sitä nauhoitetaan. Mukana on myös syvällinen katsaus Core Web Vitalseihin. DevTools on hyvä resurssi erityisesti ohjelmoijille.
Googlen omien työkalujen lisäksi markkinoilla on koko joukko kolmannen osapuolen RUM-työkaluja, muun muassa Cloudfare, New Relic ja Blue Triangle. Ne ovat myös hyviä lisiä nopeuden ja käytettävyyden seurantaan, ja moniin on intergroitu CWV-metriikat.
Core Web Vitals: Miten niitä kehitetään?
Core Web Vitalsien mittaaminen ja monitorointi on yksi juttu – mutta vielä sitä tärkeämpää on tietysti parantaa niitä. Mitään viisastenkiveä ei kuitenkaan valitettavasti ole olemassa. Nopeuden ja käytettävyyden parantaminen vaatii jatkuvaa auditointia, kehittämistä ja monitorointia.
Ensimmäinen askel on tutustua erilaisiin työkaluihin ja ryhtyä käyttämään niitä. Jo Search Consolen ja Page Speed Insights -testin avulla voi suorittaa auditoinnin ja päästä alkuun.
Kun oman sivuston hyvyydestä (tai huonoudesta!) on muodostunut kokonaiskuva, on aika ryhtyä priorisoimaan kehityskohteita. Nyrkkisääntönä voisi todeta, että mitä suurempi ongelma on kyseessä ja mitä laajempaa sivujoukkoa se koskee, sitä korkeammalle se prioriteettilistalla nousee. Kehitystyö on hyvä aloittaa niistä urleista, jotka on luokiteltu “huonoiksi”. Ideaalitapauksessa sivustolla yleisesti käytettyihin sivupohjiin voidaan tehdä parannuksia ja tällä tavoin kehitystyön vaikutus ulottuu laajalle joukolle yksittäisiä urleja. On myös mielekästä kohdistaa kehitystoimenpiteitä yksittäisiin tärkeisiin urleihin – kuten etusivuun tai parhaiten konvertoituviin “rahasivuihin”.
Kun parannuksia on tehty, ne voi validoida Search Consolen kautta. Yksi muutos kerrallaan sivusto muuttuu nopeammaksi ja käyttäjäystävällisemmäksi. Varsinkin jos sivuston lähtötaso on ollut heikko, voi CWV-tulosten parantaminen vaikuttaa loputtomalta suolta. Kannattaa kuitenkin muistaa, että mitään taikatemppuja ei tarvita. Voit aloittaa pienistä muutoksista ja keskittyä vaikkapa yhteen mittariin yhdellä sivutyypillä. Google rohkaisee pieniinkin muutoksiin ja antaa ymmärtää, että jo pelkästään parhaiden käytäntöjen seuraamisella on myönteinen vaikutus mittareihin.
Pidä myös mielessä, että Core Web Vitalsien kehittäminen ei kuulu vain hakukoneoptimoijille eikä ainoa syy niiden parantamiseen ole mahdollinen sijoitusten nousu, vaan kokonaisvaltaisesti parempi käyttäjäkokemus. Parempi käyttäjäkokemus johtaa alhaisempiin bounce rateihin, parempaan kävijätyytyväisyyteen ja korkeampaan konversioasteeseen – eli tuloksiin, joita kaikki verkkosivustojen parissa työskentelevät tavoittelevat!
