Google Core Web Vitals

Julkaistu:

Google otti kesäkuussa 2021 käyttöön Core Web Vitalsin päivityksen algoritmilleen. Core Web Vitalsit kertovat kuinka hyvä reaalimaailman käyttäjäkokemus verkkosivulla on. Ne kertovat latausajoista, paljonko menee aikaa, että sivu on vuorovaikutteinen sekä kuinka vakaasti sisältö pysyy latauksen aikana paikallaan.

Google Core Web Vitalsin mittarit

  • suurin osa sisällöstä tulee näkyviin (Largest Contentful Paint, LCP)
  • ensimmäisen syötön viive (First Input Delay, FID)
  • kumulatiivinen asettelun muutos (Cumulative Layout Shift, CLS)

Muita Web Vitalsin mittareita

  • ensimmäinen sisällön renderöinti
  • palvelimen vastausaikojen parantaminen
  • estoaika
  • interaktiivisuutta edeltävä aika

Largest Contentful Paint (LCP)

  • Kertoo kuinka kauan aikaa kuluu, että suurin osa sisällöstä tulee näkyviin.
  • Hyvä LCP arvo on alle 2,5 sekuntia.
  • Huono LCP arvo on yli 4 sekuntia

Mitkä aiheuttavat huonoa LCP:tä?

  • hidas palvelimen vasteaika
  • renderöinnin estävät JavaScript ja CSS
  • resurssien latausajat
    • kuvan, videon ja tekstilohkon elementit sivun yläosassa

Miten LCP:tä voi parantaa

  • palvelimen vaihtaminen parempaan
  • kuvien optimointi
  • ei-kriittisten JavaScriptien ja CSS:n lykkääminen ja minimointi

Palvelin

  • Jos käytössä on normaali webhotelli, vaihtaminen virtuaaliserveriin on merkittävä parannus.
  • Yksittäisellä dedikoidulla fyysisellä serverillä voi olla yli 2000 web-hotellia, jolloin yksittäisen web-hotellin voimakas kuormitus voi näkyä kaikille muille asiakkaille.
  • Virtuaaliserverissä on mahdollisuus asentaa juuri ideaalit ohjelmistot.
  • Web-hotelleissa ei voi vaikuttaa käytössä oleviin ohjelmistoihin usein lainkaan.
  • CDN (Content Delivery Network) koostuu joukosta palvelimia ympäri maailmaa useissa datakeskuksissa, jotka säilyttävät tiedostoja (JavaScript, CSS ja kuvia) välimuistissaan ja jakavat ne käyttäjälle lähimmästä mahdollisesta pisteestä.

Kuvat

  • Kuvat kannattaa jakaa seuraavan sukupolven muodoissa kuten WebP, jotka pakkaavat kuvat pienempään tilaan kuin jpg- ja png-kuvaformaatit.
  • WebP on bittikarttakuvien tiedostomuoto, jossa voidaan käyttää häviöllistä ja häviötöntä pakkausta.
  • WebP syntyi vuonna 2010 Googlen VP8-videoformaatin sivutuotteena ja julkaistiin avoimena formaattina vuonna 2010.
  • Jpg- ja png.kuvaformaatissa olevia kuvia voi optimoida siihen erikoistuneella palvelulla kuten Tinypng.com.
Kuvien lazy loading -tekniikka
  • Poissa näkyvistä olevat kuvat kannattaa ladata vasta kun kaikki kriittiset resurssit on ladattu.
  • Normaalisti sivu latautuu vasta kun kaikki resurssit on ladattu, joka ei ole latausaikojen kannalta optimaalista.
  • Ratkaisu on kuvien lazy loading -tekniikka: kuva ladataan vasta kun sen pitäisi näkyä näytöllä.
  • Lazy loading -tekniikka voidaan toteuttaa useilla eri tavoilla.
    • UIkit-nimisessä responsiivisen web-suunnittelun alustassa on kuvien lazy loading sisäänrakennettuna.
    • Chrome-selaimen versioon 76 tuli tuki sisäänrakennetulle lazy loading-ominaisuudelle.

JavaScript

  • JavaScript-tiedostot kannattaa yhdistää ja pakata esim. https:// javascript-minifier.com avulla.
  • Kutsu JavaScript-tiedostoon kannattaa laittaa ihan body-osan loppuun.
  • JavaScriptin latautumiseen voi vaikuttaa defer ja async -tekniikoilla.
    • Defer kertoo web-selaimelle, että sen pitäisi jatkaa työskentelyä sivun kanssa, ladata scripti taustalla ja suorittaa scripti sitten, kun sitä ladataan.
    • Deferiä kannattaa käyttää skripteihin, jotka tarvitsevat koko DOM (Document Object Mode) ja / tai niiden suhteellinen suorittamisen järjestys on tärkeää.
    • Async tarkoittaa, että skripti on täysin riippumaton eli sivun sisältö käsitellään ja näytetään huomioimatta async käyttävää skriptiä.
    • Asynciä kannattaa käyttää riippumattomiin skripteihin, kuten laskureihin tai mainoksiin, joiden suorittamisen järjestys ei ole tärkeää.

CSS

  • Css-tiedostot kannattaa yhdistää ja pakata esim https:// cssminifier.com avulla.
  • Kun CSS-tiedostot on pakattu ja yhdistetty, kannattaa määrittää ns. critical path.
  • Critical path tarkoittaa sivun yläosan muotoiluja, lisätään html:ään sisään.
  • Critical path voi määrittää esim https:// jonassebastianohlsson.com/criticalpathcssgenerator/ avulla.

HTML5 preload

  • HTML5 preload:n avulla voidaan ladata resurssit varhaisessa vaiheessa head-osassa niin, että resurssit eivät estä renderöintiä.
  • Käytännössä web-selaimelle annetaan ohje suorittaa alustava lataus, jotta ei jouduta odottamaan resurssin latautumista.

HTML5 prefetching DNS

  • HTML5 DNS prefethcing -tekniikalla ilmoitetaan web-selaimelle, että pitää hakea resursseja toisesta verkkotunnuksesta.
  • HTML5 prefetching DNS
  • Haettavia resursseja ovat esim.
    • Google Tag Manager
    • Google Analytics

Ensimmäisen syötön viive (FID)

  • Ensimmäisen syötteen viive (FID) mittaa aikaa, joka kuluu sivun vastaamiseen käyttäjän ollessa ensimmäisessä vuorovaikutuksessa sen kanssa.
  • Ensimmäisen syötteen viive keskittyy sivun vuorovaikutteisuuteen, mikä tarkoittaa, että jos käyttäjä ei ollut vuorovaikutuksessa sivun kanssa, sitä ei mitata.
  • Hyvä FID-pisteet ovat 100 ms ja alle. Käyttäjät kokevat 100 ms: n tai sitä pienemmän latausnopeuden hetkellisenä.
  • Kaikkia pisteitä, joka on 100 ms: n ja 300 ms: n välillä, on parannettava, ja yli 300 ms: n pisteitä pidetään heikkoina.
  • FID poikkeaa muista mittareista, koska se on ainoa mittari, joka voidaan mitata vain kentän työkaluilla.

Mikä voisi aiheuttaa huonot FID-pisteet?

Yksi yleinen syy huonoon FID-pistemäärään on se, että selaimen pääsäie on varattu JavaScript-koodin jäsentämiseen ja suorittamiseen. Kun pääsäie on varattu, se ei vielä voi vastata käyttäjän vuorovaikutukseen.

FID-pistemäärän parantaminen

  • Kun halutaan parantaa FID-pistemäärää, on tarkasteltava sitä, mikä pitää web-selaimen vuorovaikutteisena. Esimerkkejä asioista, joita voit tehdä FID-pistemäärän parantamiseksi ovat:
  • JavaScriptin suoritusajan vähentäminen
  • Pääsäikeessä tehdyn työn minimointi.
  • Kolmannen osapuolen JavaScript-koodin vaikutuksen vähentäminen.

Kumulatiivinen asettelun muutos (CLS)

  • Kumulatiivisen asettelun muutos kuvaa kun näkymän elementti siirtyi lähtöasennosta sivun lataamisen aikana.
  • Tavoitteena on mitata sivun visuaalinen vakaus.
  • Hyvä CLS-pisteet ovat alle 0,1.
  • Kaikki pisteet välillä 0,1 – 0,25 tarvitsevat parannusta.
  • Mitä tahansa arvoa yli 0,25 pidetään huonona.

Kuinka kumulatiivinen asettelun muutospiste lasketaan?

  • CLS-pisteet laskettaessa kaava on:
    • Asettelun muutoksen pisteet = vaikutusalue * etäisyyden osuus

Esimerkki

  • Oletetaan että ollaan sivulla, jossa yksi elementti (teksti, kuvat jne.), vie 40% korkeudesta.
  • Yhtäkkiä tapahtuu leiskan asteellun muutos ja mainos (epävakaa elementti) avautuu nykyisen elementin yläpuolelle.
  • Tämä mainoksen koko on 20% näkökulmasta nykyisen elementin yläpuolella.
  • Vaikutusalue on 60%.
  • Kumulatiivisen asettelun muutos = 0,6 * 0,2 = 0,12

Kumulatiivisen asettelun optimointi

  • Kuvien ja videoiden leveyden ja korkeuden määrittely auttaa web-selainta antamaan jokaiselle elementille riittävästi tilaa etukäteen.
  • Vältetään dynaamista sisältöä olemassa olevan sisällön yläpuolella
  • Web-fonttien optimointi

Web-fonttien optimointi

  • Web-fonteissa kannattaa käyttää HTML5 preload:ia.
  • CSS:llä voidaan vaikuttaa fontin latautumiseen esimerkiksi määrittelemällä font-display: swap;
  • Web-fontit kannattaa integroida julkaisujärjestelmän teemaan https://google-webfonts-helper.herokuapp.com/ fonts , jotta olisi vähemmän DNS-hakuja (loopup).

Jaa artikkeli

Tilaa syöte

Aiheeseen liittyviä artikkeleita

Arkisto

Heikki Kujala
Adlercreutzinkatu 35-37
06100 Porvoo
puh:045-1674800
email: heikki(at)heikkikujala.fi

Some