Moduuli 4 · 4.3
Core Web Vitals: LCP, INP ja CLS
Moduuli 4: Nopeus, mobiili ja https · Lukuaika: 13 minuuttia
Oppimistavoite: Tämän oppitunnin jälkeen osaat selittää kolme Core Web Vitals -mittaria ja niiden raja-arvot, kertoa kenttädatan ja laboratoriodatan eron, lukea PageSpeed Insightsin mittaustuloksen, korjata huonon tuloksen tärkeimmät syyt ja arvioida rehellisesti, kuinka paljon nopeus painaa hakutuloksissa.
Keskeiset käsitteet: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. persentiili, kenttädata (CrUX), laboratoriodata (Lighthouse), PageSpeed Insights, Search Consolen Core Web Vitals -raportti, TTFB, pakkaus, kuvien width ja height, loading="lazy", sivukokemus
Nopeus kolmena lukuna
”Onko sivustoni nopea?” on epämääräinen kysymys. Google ja Chromen kehittäjät ovat tehneet siitä kolme mitattavaa kysymystä, Core Web Vitals -mittarit:
| Mittari | Kysymys | Hyvä | Kaipaa parannusta | Huono |
|---|---|---|---|---|
| LCP, Largest Contentful Paint | Kuinka nopeasti suurin sisältöosa näkyy ruudulla? | enintään 2,5 s | 2,5-4 s | yli 4 s |
| INP, Interaction to Next Paint | Kuinka nopeasti sivu reagoi, kun klikkaat, napautat tai kirjoitat? | enintään 200 ms | 200-500 ms | yli 500 ms |
| CLS, Cumulative Layout Shift | Kuinka paljon sivu hyppii latautuessaan? | enintään 0,1 | 0,1-0,25 | yli 0,25 |
Muutama asia, jotka kannattaa ymmärtää hyvin:
- LCP mittaa hetkeä, jolloin suurin näkyvä elementti ilmestyy. Se on yleensä iso kuva sivun yläosassa (niin sanottu hero-kuva) tai suuri tekstilohko. Bloemenatelier Lotten sivustolla se on kotisivun kukka-asetelman kuva.
- INP tarkastelee kaikkia käynnin aikaisia klikkauksia, napautuksia ja näppäinpainalluksia ja raportoi (lähes) hitaimman reaktion. INP korvasi 12. maaliskuuta 2024 vanhemman mittarin FID (First Input Delay), joka katsoi vain ensimmäistä klikkausta ja vain odotusaikaa ennen käsittelyä. Jos vanhassa artikkelissa puhutaan FID:stä, tieto on vanhentunut.
- CLS ei ole aika vaan yksikötön pistemäärä. Se kasvaa, jos asiat siirtyvät lukemisen aikana: aiot napauttaa painiketta, ja juuri silloin yläpuolelle ilmestyy banneri, jolloin napautatkin jotain muuta.
75. persentiili
Sivu ”läpäisee” Core Web Vitals -mittarit, kun 75 prosenttia käynneistä saa hyvän tuloksen kaikissa kolmessa, erikseen mitattuna mobiilissa ja tietokoneella. Tätä kutsutaan 75. persentiiliksi. Se tarkoittaa, että ratkaisevaa ei ole oma nopea tietokoneesi valokuituyhteydellä vaan useimpien kävijöiden kokemus, myös niiden, joilla on vanhempi puhelin 4G-yhteydellä.
Kenttädata ja laboratoriodata
Mittauksia on kahdenlaisia, ja ne antavat usein eri lukuja.
- Kenttädata tulee oikeilta kävijöiltä. Chrome kerää (sen sallivilta käyttäjiltä) nimettömästi tietoa sivujen nopeudesta Chrome User Experience Report (CrUX) -raporttiin. PageSpeed Insights näyttää viimeisten 28 päivän kenttädatan. Search Consolen Core Web Vitals -raportti käyttää samaa lähdettä. Jos sivullasi on liian vähän kävijöitä, PageSpeed Insights näyttää koko sivustosi (niin sanotun originin) luvut, ja jos niitäkin on liian vähän, kenttädataa ei ole lainkaan.
- Laboratoriodata tulee Lighthousen simuloidusta testistä: yksi lataus jäljitellyllä keskitason puhelimella ja yhteydellä. Lighthouse ei pysty mittaamaan INP:tä (kukaan ei klikkaa), joten se antaa muita lukuja, kuten Total Blocking Time, jotka antavat kuitenkin vihjeen INP:stä.
Arvioinnissa ratkaisee kenttädata. Laboratoriodatasta on hyötyä syiden etsimisessä ja kun haluat korjauksen jälkeen nähdä heti, auttoiko se, odottamatta 28 päivää.
Kuinka paljon se painaa?
Tätä liioitellaan paljon. Näin Google itse kertoo sivukokemusta käsittelevässä dokumentaatiossaan:
- ”Core Web Vitals are used by our ranking systems”: ne siis vaikuttavat järjestykseen.
- Erillistä ”sivukokemussignaalia” ei ole. Googlen mukaan hyvän sivukokemuksen muut osat (https, ei tunkeilevia ponnahdusikkunoita, mobiilikäytettävyys) eivät suoraan nosta sinua ylemmäs, mutta ne tekevät sivustostasi miellyttävämmän.
- ”Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (Google pyrkii aina näyttämään osuvimman sisällön, vaikka sivukokemus olisi heikko.) Hidas sivu, jolla on paras vastaus, voi siis hyvin olla kärjessä.
- Täydellisen tuloksen tavoittelu pelkästään hakukoneoptimoinnin vuoksi ei Googlen mukaan ”ehkä ole paras tapa käyttää aikaasi”.
Johtopäätös: huolehdi, että olet vihreällä tai vähintään oranssilla alueella, ennen kaikkea siksi, että kävijät luopuvat hitaasta tai hyppivästä sivusta. Lighthousen pisteiden jahtaaminen 90:stä 100:aan ei juuri näy hakutuloksissa.
Syyt, joihin voit itse vaikuttaa
Hidas ensimmäinen vastaus (TTFB)
Kaikki alkaa hetkestä, jolloin HTML:n ensimmäinen tavu saapuu, eli Time to First Byte -ajasta. TTFB ei itse ole Core Web Vitals -mittari, mutta hidas TTFB tekee hyvästä LCP:stä lähes mahdottoman. web.dev antaa ohjearvoksi: hyvä on enintään 0,8 sekuntia, huono yli 1,8 sekuntia. Syitä web.devin mukaan ovat webhotellin liian vähäinen laskentateho, välimuistin puuttuminen (jokainen sivu rakennetaan aina uudelleen, tyypillistä WordPressissä ilman välimuistilisäosaa), uudelleenohjaukset (oppitunti 4.1) ja kaukana sijaitseva palvelin ilman CDN:ää.
Pakkaus kuuluu asiaan: palvelimen pitäisi lähettää HTML, CSS ja JavaScript pakattuina gzipillä tai Brotlilla. Sen näkee otsakerivistä Content-Encoding: gzip tai br. Lähes kaikki webhotellit tekevät tämän oletuksena, mutta väärä asetus tai vanha palvelin voi kytkeä sen pois.
Kuvat
Kuvat ovat yleisin syy huonoon LCP:hen ja CLS:ään:
- Liian suuret. 4 000 pikseliä leveä ja 5 Mt:n kuva 800 pikselin alueelle. Pienennä kuva ennen lataamista ja käytä modernia muotoa, kuten WebP tai AVIF.
Ei leveyttä ja korkeutta. Ilman
width- jaheight-määritteitä selain ei tiedä, kuinka paljon tilaa kuva tarvitsee, ja kuvan alla oleva teksti hyppää, kun kuva latautuu. web.dev suosittelee lisäämäänwidth- jaheight-määritteet jokaiseen<img>-elementtiin:<img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">- Tärkeimmän kuvan laiska lataus.
loading="lazy"lataa kuvan vasta, kun se tulee näkyviin. Se sopii hyvin alempana oleville kuville, mutta web.dev sanoo selvästi: älä lataa laiskasti kuvia, jotka näkyvät jo sivua avattaessa, ja varsinkaan LCP-kuvaa. Muuten selain viivyttää juuri sitä kuvaa, joka ratkaisee LCP:si.
Hyppivä sisältö ja hitaat reaktiot
Muita CLS:n syitä web.devin mukaan ovat fontit, joiden koko muuttuu latauksen aikana, mainokset ja upotetut widgetit, jotka kasvattavat itseään, sekä sisältö, joka lisätään myöhemmin olemassa olevan sisällön yläpuolelle (kuten evästepalkki, joka työntää sivua alaspäin sen sijaan, että se olisi sivun päällä). Huono INP johtuu lähes aina liiasta JavaScriptistä: raskaista teemoista, kuvakaruselleista, chat-widgeteistä ja kolmansien osapuolten seurantakoodeista. Tarkastele jokaista lisäosaa ja upotettua palvelua kriittisesti; tässä vähemmän on todella enemmän.
Käytännössä: mittaus PageSpeed Insightsilla
Mene osoitteeseen pagespeed.web.dev, kirjoita kotisivusi osoite ja valitse Analyze. Saat kaksi välilehteä (Mobile ja Desktop). Ylimpänä on Core Web Vitals -arvio kenttädatan perusteella, jos sitä on. Sen alla on Lighthouse-testi pistemäärineen ja Diagnostics-luettelo konkreettisine huomioineen, esimerkiksi tarpeettoman suurista kuvista tai laiskasti ladattavasta LCP-kuvasta (tarkat nimet muuttuvat Lighthousen uusissa versioissa). Aloita Mobile-välilehdestä: siellä tulokset ovat yleensä huonompia, ja Google katsoo ensin mobiiliversiota (oppitunti 4.2).
Jos sivustosi on Search Consolessa (moduuli 2), katso myös kohta Experience, Core Web Vitals. Siellä näet samankaltaisten sivujen ryhmät tiloineen, myös sivuille, joita et ole itse testannut.
AI Builderilla tehty sivusto lisää leveyden ja korkeuden kuviin, joiden koko tiedetään, lataa sivun ensimmäisen kuvan heti ja etusijalla (fetchpriority="high") ja muut laiskasti, ja tekee julkaisun yhteydessä suurista kuvista 800 pikseliä leveän version. WordPressissä eniten auttavat välimuistilisäosa ja kuvien pienentäminen; WordPress-kurssin moduuli 6 käsittelee tätä tarkemmin. Muissa sivustotyökaluissa ja webhotelleissa toimitaan samaan tapaan: painikkeet ovat erilaisia, mutta syyt ovat samat.
Yhteenveto
- Core Web Vitals -mittarit ovat LCP (hyvä enintään 2,5 s), INP (hyvä enintään 200 ms, maaliskuusta 2024 FID:n tilalla) ja CLS (hyvä enintään 0,1), ja ne mitataan 75. persentiilillä laitetyypeittäin.
- Kenttädata (CrUX, 28 päivää) ratkaisee arvion; laboratoriodata (Lighthouse) auttaa löytämään syyt.
- Google käyttää Core Web Vitals -mittareita järjestyksessä, mutta osuvuus menee edelle: täydellinen tulos ei ole itsetarkoitus.
- Suurin hyöty: nopea palvelinvastaus välimuistilla ja pakkauksella, pienet kuvat
width- jaheight-määritteillä, tärkeimmän kuvan lataus ilman laiskaa latausta ja vähemmän kolmansien osapuolten JavaScriptiä.
Tietovisa
Tehtävä
Tehtävä A4.3: Nopea vastaus ja kevyet kuvat. Kirjoita sivun osoite. Ohjelma mittaa palvelimeltamme kolme kertaa ajan ensimmäiseen tavuun (TTFB) ja ottaa keskimmäisen luvun, tarkistaa, lähetetäänkö HTML pakattuna (gzip, Brotli tai zstd), laskee kuvat, joilta puuttuvat width ja height, ja tarkistaa, ettei sivun yläosan tärkeintä kuvaa ladata loading="lazy"-määritteellä. Huomaa: tämä on mittaus yhdestä paikasta, ei kävijöidesi mittaus. Eikö sinulla ole omaa sivustoa? Käytä osoitetta www.wikipedia.org.
Tehtävä D4.3: Sivustosi Core Web Vitals. Aja PageSpeed Insights kotisivullesi ja yhdelle muulle tärkeälle sivulle, ensin Mobile-välilehdellä. Kirjaa jokaisesta sivusta: onko kenttädataa (sivulta vai koko sivustolta), kenttädatan LCP, INP ja CLS, Lighthouse-pistemäärä sekä elementti, jonka Lighthouse ilmoittaa LCP-elementiksi. Valitse yksi parannus, joka on mielestäsi hyödyllisin, ja perustele valintasi.
Tehtävä D4.3: Sivustosi Core Web Vitals
Tämän tehtävän teet itse, kukaan ei tarkista sitä. Merkitse tekemäsi kohdat ja merkitse tehtävä tehdyksi.
Esimerkki: sivulle ei ole kenttädataa, mutta koko sivustolle on: LCP 3,1 s, ei läpäissyt. LCP-elementti on 2,4 Mt:n kuva, jossa on loading=lazy. Parannus: pienennä kuvaa äläkä lataa sitä laiskasti. Se vaikuttaa juuri siihen mittaukseen, joka epäonnistuu.
Merkintäsi ja muistiinpanosi pysyvät vain tässä selaimessa, emme lähetä niitä minnekään. Jos olet kirjautunut sisään, tallennamme kohtaan Omat kurssit vain sen, että olet tehnyt tehtävän.
Lisälukemista
- web.dev, Web Vitals: https://web.dev/articles/vitals
- web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
- web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
- web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
- web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
- web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
- Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
- PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
- Search Console Help, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520
