Kodulehe kiirus ja Google: mida Core Web Vitals päriselt mõõdab

Lighthouse'i skoor võib laua taga näidata rohelist tulemust, samal ajal kui Google Search Console näitab samal saidil punaseid Core Web Vitalsi hoiatusi. See kombinatsioon ajab enamiku kliente segadusse, ja õigustatult. Kaks tööriista mõõdavad kaht erinevat asja ja kui aru ei saa, mida kumbki tegelikult näitab, on lihtne kulutada aega valele probleemile.

Kolm mõõdikut, lihtsas keeles

LCP (Largest Contentful Paint) mõõdab, kui kaua kulub suurima nähtava elemendi, tavaliselt hero-pildi või peapealkirja, täieliku kuvamiseni. Kasutaja jaoks on see vahe "leht on tühi" ja "leht on olemas" vahel. Hea tulemus on 2,5 sekundit või vähem.

INP (Interaction to Next Paint) mõõdab, kui kiiresti leht reageerib klõpsule, puudutusele või klahvivajutusele. Kui vajutad nuppu ja midagi juhtub alles poole sekundi pärast, on see INP probleem: leht tundub "kinni jäänud", isegi kui see lõpuks reageerib. Hea tulemus on 200 millisekundit või vähem.

CLS (Cumulative Layout Shift) mõõdab, kui palju elemendid lehel laadimise ajal paigast nihkuvad. Kõige tuttavam näide: hakkad lugema teksti, pilt laadub tekstipealsele reale ja kogu sisu hüppab allapoole täpselt hetkel, kui sõrmega ekraanil edasi sirvid. Hea tulemus on 0,1 või vähem, number, mis kirjeldab nihke suurust, mitte sekundeid.

Väliandmed, mitte laborihinne

Lighthouse käivitab saidi ühe korra kontrollitud tingimustes ja annab hinnangu selle ühe käivituse põhjal. Core Web Vitals, mida Google Search Console näitab, tuleb hoopis CrUX-ist (Chrome User Experience Report): reaalsete Chrome'i kasutajate mõõdetud andmetest viimase 28 päeva jooksul, kes külastasid sinu lehte oma päris seadmega ja oma päris internetiühendusega.

Need kaks erinevad süstemaatiliselt. Sinu enda sülearvuti kiirel kontoriühendusel saab Lighthouse'is rohelise tulemuse, samal ajal kui suur osa päris külastajatest avab lehte odavama telefoniga 4G-ühenduse peal, kus samad pildid ja skriptid laaduvad märgatavalt aeglasemalt. Roheline Lighthouse ei garanteeri rohelist Core Web Vitalsi. See näitab ainult, et parimatel tingimustel on leht kiire, mitte et see on kiire su tegelikele külastajatele.

Google hindab Core Web Vitalsi ka rangema reegli järgi, kui enamik arvab: lävendile peab vastama vähemalt 75 protsenti reaalsetest lehelaadimistest, mitte keskmine tulemus. See tähendab, et üksikud väga kiired külastused ei kata kinni suurt hulka aeglasi, ja saidil, mida osa külastajaid avab vanema telefoniga nõrgal ühendusel, on see lävend päriselt raske ületada, isegi kui enamik külastusi on täiesti korras.

Kiiruse tegelik kaal otsingutulemustes

Google on selgelt kinnitanud, et Core Web Vitals on osa järjestuslogikast, aga see on väike ja spetsiifiline osa. See on tasavägiste vahel otsustaja, mitte sisu asendaja: kui kaks lehte vastavad päringule võrdselt hästi, võib kiirem neist saada eelise. Kiirus ei tõsta sisuliselt nõrka lehte kolmandalt otsingutulemuste lehelt esimesele. Kui orgaaniline liiklus on väike sisu või vähese relevantsuse tõttu, ei ole kiiruse parandamine see, mis seda probleemi lahendab.

Kiiruse suurem ja päriselt tuntav mõju on ostuteel, mitte otsingutulemustes: iga sekund, mille jooksul kasutaja lehe laadimist ootab, suurendab tõenäosust, et ta lahkub enne, kui jõuab sisu üldse näha. See mõjutab konversiooni ja tagasipöördumismäära palju otsesemalt kui positsiooni Google'is.

Eesti väikeettevõtete saitide tüüpilised patud

Enamikul juhtudel korduvad samad probleemid ja igaühel on selge seos ühe konkreetse mõõdikuga:

• Tihendamata hero-pilt. Kui hero-pilt ongi enamasti täpselt see element, mida LCP mõõdab, lükkab mitme megabaidine originaalfail LCP-tulemuse otse punasesse tsooni. See on kõige suurem üksik mõjur, mida saidil üldse leiab.
• WebP või AVIF formaadi puudumine. Sama efekt väiksemas mastaabis: JPEG on samal kvaliteedil kaks kuni kolm korda suurem fail, mis lisab LCP-le sekundi murdosa igal laadimisel, eriti aeglasemal mobiiliühendusel.
• Karussell, mille kõrgus muutub slaidide vahel. Peamiselt CLS-probleem: iga vahetus, mis muudab konteineri kõrgust, loetakse uueks nihkeks. Kui karussell on lehe ülaosas, kannatab kaudselt ka LCP, sest brauser peab paigutust mitu korda ümber arvutama, enne kui see stabiliseerub.
• Font, mis laadub hilja ilma font-display: swap määranguta. Peidetud tekst, mis ilmub hilinemisega, tekitab CLS-nihke, kui ilmumine muudab rea kõrgust või laiust. Kui LCP element ise on tekst, mõjutab see otse ka LCP-d, sest brauser ootab fonti enne, kui midagi näitab.
• Neli-viis kolmanda osapoole skripti enne sisu (Google Analytics, Facebooki piksel, jututoa vidin, mõni turundustööriist). Peamiselt INP probleem: iga skript hõivab brauseri põhilõime just hetkel, mil kasutaja üritab juba klõpsata, ja nupuvajutus jääb näiliselt reageerimata. Aeglasel telefonil on efekt kõige nähtavam.
• Küpsisebänner, mis lükkab sisu allapoole. Kõige otsesem ja kindlam CLS-tekitaja saidil, sest see ilmub peaaegu igal esmakülastusel ja nihutab kogu nähtava sisu täpselt hetkel, mil külastaja alustab lugemist.

Mis päriselt aitab, tähtsuse järjekorras

Järjekord pole suvaline. Hero-pilt kaalub tüüpiliselt kõige rohkem baite kogu lehel, tihti rohkem kui kõik teised ressursid kokku, ja on enamasti otse see element, mida LCP mõõdab, seega annab selle parandamine kõige suurema ühekordse võidu. Skriptide viivitamine parandab peamiselt INP-d, mis on samuti reaalne probleem, aga tavaliselt väiksema kaaluga kui mitme megabaidine pilt, ja mõjub kõige rohkem just aeglasematel telefonidel. Sellepärast tuleb pilditöö esimesena, mitte sellepärast, et skriptid oleksid ebaolulised.

Esimesena: hero-pildi optimeerimine, õige mõõt, korralik tihendus, WebP või AVIF formaat. See üksi parandab LCP-d rohkem kui enamik muid muudatusi kokku.

Teiseks, reserveeri piltidele, karussellidele ja manustatud elementidele fikseeritud ruum juba enne, kui need laaduvad. See kõrvaldab suurema osa CLS-probleemidest kohe.

Kolmandaks, lisa fondi laadimisele font-display: swap ja eellae kriitiline font, nii ei jää tekst nähtamatuks ega nihku hiljem paigast.

Neljandaks, lükka kolmanda osapoole skriptid, jututoad, mittekriitilised analüütikatööriistad, laaduma alles pärast põhisisu kuvamist või esimese kasutaja interaktsiooni järel, mitte lehe laadimise algfaasis.

Viiendaks, kujunda küpsisebänner nii, et see ei lükka sisu paigast, vaid kattub sellega fikseeritud positsioonina.

Ükski neist pole eraldiseisvana keerukas, aga koos annavad need vahe, mis on tunda nii Google Search Console'is kui, mis olulisem, lehel klõpsavas kasutajas. Kui disain ise loob probleemi, näiteks karussell, mille kõrgus muutub sisu järgi, on see sageli koht, kus UI/UX disain ja tehniline jõudlus käivad käsikäes. Ja kui kaalud, kas praegune koduleht vajab põhjalikumat ülevaatust, on kiirus enamasti esimene koht, kust vaadata.

E-poe puhul on kiirus veel otsesemalt rahaga seotud, sest iga laadimissekund kaotab ostukorve, sellest kirjutasin pikemalt e-poe loomise postituses. Ja kui praegune sait on WordPressil ja pistikprogrammide kuhi on kiiruse põhjus, tasub lugeda, millal see kuhjumine muutub probleemiks, mida lihtsam on ümber ehitada kui parandada.

Roheline number Search Console'is pole eesmärk omaette. Eesmärk on külastaja, kes ei jõua kunagi mõelda, kas leht on kiire, sest ta ei märka seda üldse.