Core Web Vitals selitettynä: LCP, INP ja CLS selkokielellä

Core Web Vitals ei ole persoonallisuustesti verkkosivustollesi

Core Web Vitalsiin suhtaudutaan usein kuin arvoitukselliseen pistetaulukkoon. Sivu saa punaisen luvun, joku julkaisee kuvakaappauksen Slackissa, ja tiimi alkaa väitellä JavaScript-kehyksistä.

Se ei ole erityisen hyödyllistä.

Parempi tapa ajatella Core Web Vitalsia on yksinkertaisempi: ne ovat kolme mittaria siitä, tuntuuko sivu käyttökelpoiselta oikealle ihmiselle oikealla laitteella. Ne eivät kata suorituskyvyn, saavutettavuuden tai laadun kaikkia osa-alueita. Mutta ne tavoittavat kolme yleistä turhautumisen lähdettä:

• Pääsisällön ilmestyminen kestää liian kauan.
• Sivu reagoi hitaasti, kun käyttäjä yrittää tehdä jotain.
• Asettelu hyppii käyttäjän lukiessa tai napauttaessa.

Nämä ovat kolme Core Web Vitals -mittaria: LCP, INP ja CLS.

Google käyttää niitä osana sivukokemussignaalejaan, mutta SEO-näkökulma ei ole paras syy välittää niistä. Parempi syy on se, että hitaat, hyppivät ja reagoimattomat sivut tuhlaavat käyttäjien aikaa. Ne myös yleensä konvertoivat huonommin, kuormittavat tukea enemmän ja vanhenevat huonosti.

Kolme mittaria yhdellä lauseella kukin

Ennen yksityiskohtia tässä on selkokielinen versio:

• LCP eli Largest Contentful Paint mittaa, kuinka kauan pääasiallisen näkyvän sisällön latautuminen kestää.
• INP eli Interaction to Next Paint mittaa, kuinka nopeasti sivu reagoi käyttäjän vuorovaikutuksiin käynnin aikana.
• CLS eli Cumulative Layout Shift mittaa, kuinka paljon sivu liikkuu odottamattomasti.

Tavanomaiset raja-arvot ovat:

| Mittari | Hyvä | Vaatii parannusta | Heikko | |---|---:|---:|---:| | LCP | 2,5 s tai nopeampi | 2,5 s–4,0 s | Yli 4,0 s | | INP | 200 ms tai nopeampi | 200 ms–500 ms | Yli 500 ms | | CLS | 0,1 tai pienempi | 0,1–0,25 | Yli 0,25 |

Näitä lukuja arvioidaan yleensä todellisten käyttäjäkäyntien 75. persentiilissä. Sillä on merkitystä. Et yritä tehdä yhtä täydellistä laboratoriomittausta. Yrität tehdä kokemuksesta hyvän useimmille käyttäjille, myös niille, joilla on hitaampia puhelimia ja epävakaampia verkkoyhteyksiä.

Jos tuijotat automatisoitua raporttia etkä tiedä, mistä aloittaa, diagnoosi kannattaa erottaa paniikista. Meillä on erillinen opas siitä, miten Lighthouse-raporttia luetaan panikoimatta, ja se käsittelee työnkulkua tarkemmin.

LCP: milloin sivu tuntuu latautuneelta?

Largest Contentful Paint mittaa näkymäalueen suurimman näkyvän sisältöelementin renderöintiaikaa. Käytännössä se on usein:

• hero-kuva,
• suuri otsikko,
• artikkelin pääkuva,
• tuotekuva,
• suuri tekstilohko.

LCP ei kysy, milloin jokainen skripti, seurantapikseli ja taitteen alapuolella oleva kuva on latautunut. Se kysyy: milloin se pääasia, jota käyttäjä tuli katsomaan, tuli näkyviin?

Tämä tekee LCP:stä inhimillisemmän mittarin kuin vanhanaikainen ”sivun latausaika”. Sivu voi teknisesti latautua loppuun myöhään mutta tuntua silti nopealta, jos pääsisältö ilmestyy nopeasti. Myös päinvastainen voi olla totta: sivu voi laukaista load-tapahtuman, vaikka hero-alue on yhä tyhjä, sumea tai renderöintiviiveen estämä.

Huonon LCP:n yleisiä syitä

Useimmat huonot LCP-ongelmat johtuvat muutamasta ennakoitavasta kohdasta:

1. Hidas palvelinvastaus

Jos HTML-dokumentti saapuu myöhässä, kaikki muukin alkaa myöhässä.

1. Renderöinnin estävä CSS tai JavaScript

Selaimella on sisältö, mutta se ei voi vielä piirtää sitä.

1. Optimoimattomat hero-kuvat

Suurin elementti on liian suuri, väärässä muodossa, ilman priorisointia tai vahingossa laiskasti ladattu.

1. Verkkofontit viivästyttävät tekstin renderöintiä

Suuri otsikko voi olla LCP-elementti, ja fonttien latautuminen voi viivästyttää tai muuttaa sitä visuaalisesti.

1. Asiakaspuolen renderöinnin viiveet

Jos sivu tarvitsee suuren JavaScript-paketin ennen kuin se voi näyttää merkityksellistä sisältöä, LCP kärsii.

Miten LCP:tä parannetaan

Aloita todellisesta LCP-elementistä. Älä optimoi satunnaisia resursseja ennen kuin tiedät, mitä selain mittaa.

Käytännön korjauksia ovat:

• Tarjoile HTML nopeasti: käytä välimuistia tarpeen mukaan, vähennä taustajärjestelmän työtä ja vältä hitaita uudelleenohjauksia.
• Optimoi LCP-kuva: käytä oikeita mittoja, pakkausta ja formaattia.
• Älä laiskalata ensinäytössä olevaa hero-kuvaa.
• Käytä pääkuvalle fetchpriority="high" harkiten, kun se on todella prioriteetti.
• Upota kriittinen CSS vain silloin, kun se vähentää renderöintiviivettä merkittävästi.
• Vähennä JavaScriptiä, jota tarvitaan ennen ensimmäistä merkityksellistä renderöintiä.
• Käytä font-display: swap -asetusta tai muuta tarkoituksellista fonttistrategiaa.

Kuvat ja fontit ovat usein syyllisiä. Kuvissa kompromissi ei ole vain ”pieni tiedosto hyvä”. Formaattivalinta, enkoodauksen tehokkuus ja selaintuki merkitsevät kaikki, minkä vuoksi ylläpidämme käytännön päätöspuuta siitä, milloin AVIF voittaa WebP:n ja milloin ei. Tekstipainotteisilla sivuilla verkkofontit ovat edelleen yksi helpoimmista suorituskykyvoitoista, koska monet sivustot toimittavat enemmän fonttitiedostoja kuin ne käyttävät.

INP: reagoiko sivu kosketukseen?

Interaction to Next Paint mittaa reagointikykyä. Tarkemmin sanottuna se tarkastelee viivettä käyttäjän vuorovaikutuksen ja seuraavan visuaalisen päivityksen välillä sen jälkeen, kun selain on käsitellyt kyseisen vuorovaikutuksen.

Vuorovaikutuksia ovat esimerkiksi:

• painikkeen napsauttaminen,
• valikon napauttaminen,
• valintaruudun valitseminen,
• lomakekenttään kirjoittaminen,
• haitarin avaaminen.

INP korvasi First Input Delayn Core Web Vital -mittarina vuonna 2024. Se oli hyvä muutos. First Input Delay tarkasteli vain ensimmäistä vuorovaikutusta. INP on laajempi: se huomioi vuorovaikutukset koko sivukäynnin ajalta ja raportoi suuren viiveen vuorovaikutuksen sivun reagointikykypisteenä.

Selkokielellä: INP löytää sivut, jotka näyttävät latautuneilta mutta tuntuvat jumiutuneilta.

Olet todennäköisesti käyttänyt tällaista sivua. Se näyttää valmiilta. Napautat valikkoa. Mitään ei tapahdu puoleen sekuntiin. Napautat uudelleen. Sitten kaksi asiaa tapahtuu yhtä aikaa. Se on INP-ongelma.

Huonon INP:n yleisiä syitä

INP on yleensä pääsäikeen ongelma. Selain haluaa reagoida, mutta JavaScript, renderöintityö tai asettelulaskenta on tiellä.

Tyypillisiä syitä ovat:

• suuret JavaScript-paketit,
• raskaat tapahtumankäsittelijät,
• hydratointityö asiakaspuolella renderöidyissä sovelluksissa,
• kolmannen osapuolen skriptit, jotka kilpailevat pääsäikeestä,
• pitkään kestävät tehtävät sivun latautumisen jälkeen,
• monimutkaiset DOM-päivitykset, jotka käynnistyvät pienistä vuorovaikutuksista,
• layout thrashing, jossa koodi lukee ja kirjoittaa asetteluarvoja toistuvasti.

Markkinointitagit, analytiikka, chat-widgetit ja suostumusbannerit voivat kaikki vaikuttaa tähän. Tämä ei tarkoita ”poista kaikki”. Se tarkoittaa, että jokaisella sivun skriptillä on kustannus, ja vuorovaikutusviive on paikka, jossa tämä kustannus usein tulee näkyviin.

Miten INP:tä parannetaan

INP:n parantaminen ei ole niinkään yhden taika-attribuutin löytämistä, vaan pääsäikeen kuormituksen vähentämistä.

Hyödyllisiä lähestymistapoja ovat:

• Pilko pitkät JavaScript-tehtävät pienempiin osiin.
• Siirrä ei-välttämätön työ siihen asti, kunnes sivu on käyttökelpoinen.
• Poista käyttämätön JavaScript sen sijaan, että vain minifioisit sen.
• Pidä tapahtumankäsittelijät pieninä ja ennakoitavina.
• Vältä suurten käyttöliittymän osien uudelleenrenderöintiä pienten tilamuutosten vuoksi.
• Käytä CSS:ää yksinkertaisiin visuaalisiin tiloihin aina kun mahdollista.
• Auditoi kolmannen osapuolen skriptit ja lataa niitä vain siellä, missä niitä tarvitaan.

Tarkastele myös vuorovaikutussuunnittelua. Painike, joka antaa välittömän visuaalisen palautteen, voi tuntua reagoivammalta, vaikka jatkotyö kestäisi kauemmin. Se ei korvaa suorituskykyä, mutta se on osa hyvää käyttöliittymäsuunnittelua. Saavutettavien verkkopainikkeiden tarkistuslistamme limittyy tämän kanssa: selkeät tilat, oikea semantiikka ja ennakoitava käyttäytyminen auttavat sekä käyttäjiä että selaimia.

CLS: pysyykö sivu siellä missä käyttäjä odottaa?

Cumulative Layout Shift mittaa näkyvien elementtien odottamatonta liikkumista. Jos käyttäjä alkaa lukea kappaletta ja mainos, kuva tai banneri latautuu sen yläpuolelle työntäen tekstin alas, se kasvattaa CLS:ää.

CLS:ää ei mitata sekunneissa. Se on pistemäärä, joka perustuu siihen, kuinka paljon sisältöä liikkui ja kuinka kauas se liikkui. Pienempi on parempi.

Avainsana on odottamaton. Käyttäjän toiminnasta johtuvia asettelumuutoksia ei yleensä lasketa samalla tavalla. Jos joku napauttaa ”näytä lisää” ja sisältö laajenee, se on odotettua. Jos uutiskirjebanneri ilmestyy yläreunaan kolmen sekunnin kuluttua ja työntää kaiken alas, se ei ole odotettua.

Huonon CLS:n yleisiä syitä

CLS-epäonnistumiset ovat usein arkisia:

• kuvat ilman width- ja height-attribuutteja,
• mainokset tai upotukset ilman varattua tilaa,
• evästebannerit, jotka lisätään sisällön yläpuolelle,
• verkkofontit, jotka vaihtuvat eri metriikoilla,
• myöhään latautuvat kampanjapalkit,
• dynaamisesti lisätty sisältö sivun yläosan lähellä.

Korjaus on yleensä varata tila ennen kuin sisältö saapuu. Selaimen pitäisi tietää sivun muoto mahdollisimman aikaisin.

Miten CLS:ää parannetaan

Aloita näkyvistä siirtymistä. Katso tallenne tai käytä selaimen työkaluja tunnistaaksesi, mitkä elementit liikkuvat.

Sovella sitten tylsiä korjauksia:

• Lisää kuviin eksplisiittiset width- ja height-attribuutit.
• Käytä CSS:n aspect-ratio-ominaisuutta responsiivisissa mediasäiliöissä.
• Varaa kiinteä tai vähimmäistila mainoksille, upotuksille ja iframeille.
• Vältä bannerien lisäämistä olemassa olevan sisällön yläpuolelle latautumisen jälkeen.
• Valitse fonttivarafontit, joiden metriikat ovat lähellä lopullista fonttia.
• Vältä animaatioita, jotka muuttavat asetteluominaisuuksia kuten top, left, width tai height; suosi transformaatioita.

CLS on yksi harvoista suorituskykymittareista, joissa kurinalaisuus voittaa nokkeluuden. Jos sivulla on vakaat laatikot, se saa yleensä hyvät pisteet.

Kenttädata ja laboratoriodata ovat molemmat hyödyllisiä, mutta ne vastaavat eri kysymyksiin

Yleinen hämmennyksen lähde on se, että eri työkalut näyttävät eri lukuja. Se on normaalia.

Kenttädata tulee oikeilta käyttäjiltä. Se heijastaa todellisia laitteita, verkkoja, sijainteja ja selainolosuhteita. Googlen Chrome User Experience Report on esimerkki kenttädatasta.

Laboratoriodata tulee hallitusta testiympäristöstä. Lighthouse on tuttu esimerkki. Se on toistettavaa ja hyödyllistä vianetsinnässä, mutta se ei ole sama asia kuin käyttäjiesi todellinen kokemus.

Käytä kenttädataa päättääksesi, onko käyttäjillä todellinen ongelma. Käytä laboratoriodataa ongelman toistamiseen ja vianetsintään.

Muista myös, että Core Web Vitalsia arvioidaan yleensä URL-osoitteen tai URL-ryhmän mukaan, ei yhtenä abstraktina brändisi ominaisuutena. Etusivulla, blogiartikkelilla, hinnastosivulla ja kassalla voi olla hyvin erilaiset pullonkaulat.

Järkevä työjärjestys

Jos kaikki kolme mittaria ovat heikkoja, houkutus on aloittaa kaikkialta. Vastusta sitä.

Käytännöllinen järjestys on:

1. Korjaa ilmeiset CLS-ongelmat ensin

Puuttuvat kuvamitat ja epävakaat bannerit ovat usein nopeita voittoja.

1. Paranna tärkeiden sivupohjien LCP:tä

Keskity sivuihin, joilla on merkitystä: tuotesivuihin, laskeutumissivuihin, artikkeleihin ja rekisteröitymisprosesseihin.

1. Tutki INP:tä todellisilla vuorovaikutuksilla

Napsauta niitä asioita, joita käyttäjät oikeasti napsauttavat. Valikot, suodattimet, lomakkeet ja kassatoiminnot paljastavat usein enemmän kuin alkuperäinen latausjälki.

1. Auditoi kolmannen osapuolen skriptit

Säilytä ne, jotka oikeuttavat kustannuksensa. Poista tai viivästytä ne, jotka eivät oikeuta.

1. Aseta suorituskykybudjetti

Ilman budjettia suorituskykyparannukset rapautuvat. Uudet skriptit, kuvat ja design-komponentit kumoavat työn hiljalleen.

Tärkeä asia: älä optimoi merkkiä varten. Optimoi käyttäjäpolkua varten. Marginaalinen pisteparannus vähäliikenteisellä sivulla voi olla vähemmän tärkeä kuin hieman epätäydellinen mutta paljon nopeampi kassavuorovaikutus.

<!-- tool-cta:start -->

💡 Kokeile tätä: Koska LCP on yleensä kuvaongelma, pienennä hero-elementtiäsi Image Compressor -työkalulla ensimmäisenä helppona voittona.

<!-- tool-cta:end -->

Mitä Core Web Vitals ei kerro

Core Web Vitals on hyödyllinen, mutta epätäydellinen.

Se ei kerro, onko sisältösi hyvää. Se ei kerro, onko navigaatiosi järkevä. Se ei takaa saavutettavuutta. Se ei mittaa yksityisyyttä, tietoturvaa, luottamusta, luettavuutta tai sitä, vastaako sivu käyttäjän kysymykseen.

Se ei myöskään korvaa harkintaa. Sivu voi läpäistä Core Web Vitals -mittarit ja olla silti epämiellyttävä. Monimutkainen sovellus voi jäädä raja-arvosta ja olla silti vastuullisesti toteutettu omien rajoitteidensa puitteissa.

Käsittele LCP:tä, INP:tä ja CLS:ää palovaroittimina. Kun ne hälyttävät, tutki asiaa. Kun ne ovat hiljaa, jatka rakennuksen ylläpitoa.