Mis on Core Web Vitals ja kuidas mõjutab lehe kiirus konversioone?

Kui küsite, mis on Core Web Vitals, on lühike vastus järgmine: kolm kasutajakogemuse mõõdikut, mida Google on pingereastamise signaalina kasutanud alates 2021. aastast. Kuid pingereastamine pole õige vaatenurk — aeglased saidid kaotavad külastajaid, kiired saidid hoiavad neid. Punkt.

Mis on Core Web Vitals?

Aastaid püüdis Google lehe kiirust väljendada ühe millisekundi arvuga. See ei olnud piisav, sest "laaditud" ei tähenda kasutajale midagi. Kasutajat huvitab: näha sisu ekraanil, saada klikile vastus ja lugeda ilma, et tekst hüpleks. Core Web Vitals kvantifitseerib täpselt need kolm kogemust: LCP, INP ja CLS.

Mõõdikud põhinevad Chrome'i kaudu kogutud reaalsetel kasutajaandmetel (CrUX) — mitte sünteetilistel laboritestidel. Iga tehtud täiustus mõõdetakse tegelike külastajate alusel, mis tähendab, et iga edusamm on reaalne.

LCP — suurim sisuline joonistamine

LCP tähistab hetke, mil brauseris joonistatakse suurim vaateaknas olev sisulement — tavaliselt hero-pilt või suur pealkiri. See on hetk, mil kasutajad tunnevad, et leht on valmis.

• ▸Hea: 2,5 sekundit või vähem
• ▸Vajab parandamist: 2,5 – 4,0 sekundit
• ▸Halb: üle 4,0 sekundi

Peamised LCP-d kahjustavad tegurid: aeglane serveri vastusaeg (TTFB), suured optimiseerimata pildid, renderdamist blokeeriv CSS/JS ja hiline fondilaadimine. Lahendused järjekorras: CDN-i kasutamine, üleminek WebP/AVIF-formaadile, kriitiliste ressursside eellaadimiseks `<link rel='preload'>` ja font-display: swap rakendamine.

INP — interaktsioonist järgmise joonistamiseni

INP asendas FID-i (First Input Delay) märtsis 2024. Erinevus on kriitiline: FID mõõtis ainult esimest klõpsu; INP mõõdab kõigi klõpsude, puudutuste ja klaviatuuriinteraktsioonide latentsust lehel ning raporteerib väärtuse, mis esindab halvimat 95. protsentiili.

• ▸Hea: 200 ms või vähem
• ▸Vajab parandamist: 200 – 500 ms
• ▸Halb: üle 500 ms

INP-probleemid tulenevad tavaliselt pikkadest JavaScripti ülesannetest, mis blokeerivad peamise lõime — kolmandate osapoolte skriptid, rasked sündmuste töötlejad ja tarbetud ümberrenderimise tsüklid on tavalised süüdlased. Lahendused: jaotage pikad ülesanded `scheduler.postTask()` abil tükkideks, teisaldage rasked toimingud Web Workerisse ja kõrvaldage raamistiku tasemel tarbetud ümberrenderimised.

CLS — kumulatiivne paigutuse nihe

CLS mõõdab, kui palju elemendid lehe laadimisel ootamatult nihkuvad. Me kõik oleme seda kogenud — loeme artiklit, kui tekst hüppab äkki, vajutame valele nupule, sest bänner ilmus vahele. CLS hindab seda halba kogemust.

• ▸Hea: 0,1 või vähem
• ▸Vajab parandamist: 0,1 – 0,25
• ▸Halb: üle 0,25

Peamised CLS-i põhjused: pildid ja videod ilma selgesõnaliste mõõtmeteta, hiljem laadivad reklaamid või manustused, dünaamiliselt lisatud sisu (bännerid, teatised) ja hiljem laadivad veebifondid. Määrake alati piltidele `width` / `height`, reserveerige reklaamikohtadele minimaalne kõrgus ja kasutage font-display: optional või swap.

Kuidas mõõta Core Web Vitalsi?

Mõõtke kahest nurgast: laboriandmed (simuleeritud tingimused) ja välitingimustes andmed (reaalsed kasutajad). Mõlemad on olulised, kuid pingereastamise mõju määrab välitingimustes andmed.

• ▸Google Search Console → Core Web Vitalsi aruanne — rühmitab lehed kategooriatesse Hea / Vajab parandamist / Halb koos prioriteetsuse järjestusega
• ▸PageSpeed Insights — näitab nii Lighthouse'i laboriandmeid kui ka CrUX-i välitingimustes andmeid ühel lehel
• ▸Chrome DevTools → jõudluspaneel + Web Vitalsi laiendus — reaalajas silumiseks
• ▸web-vitals JS teek — edastage reaalsete kasutajate andmed otse oma analüütikasüsteemi

Kuidas parandada Core Web Vitalsi?

Kõigepealt diagnoosimine, siis parandamine. Tehke kindlaks, milline mõõdik ebaõnnestub PageSpeed Insightsi või Search Console'i kaudu, seejärel võtke mõõdikuspetsiifiline tegevus. Kõigi kolme samaaegne parandamine lõpeb tavaliselt sellega, et ükski ei parane.

1. 01Avage Search Console'is Core Web Vitalsi aruanne, loetlege halvad URL-rühmad.
2. 02Käivitage PageSpeed Insights iga rühma jaoks — milline mõõdik, milline element?
3. 03LCP puhul: optimeerige serveri TTFB, laadige hero-pilt eelnevalt, vähendage faili suurust.
4. 04INP puhul: leidke pikad ülesanded Chrome DevToolsi jõudluspaneelist ja jaotage need.
5. 05CLS puhul: lisage piltidele mõõtmed, rakendage font-display: swap, reserveerige dünaamilisele sisule ruumi.
6. 06Juurutage, oodake 28 päeva CrUX-i andmete uuendamist, seejärel kontrollige Search Console'i uuesti.

Kiirus ei ole funktsioon — see on tootemislik otsus. Iga lisanduv sekund, iga paigutuse nihe kujundab vastust küsimusele, mida külastajad vaikselt esitavad: "Kas ma saan sellele saidile usaldada?"

— POI369 veebitiim

Kiiruse ja konversioonide vaheline seos

Core Web Vitals on oluline ka väljaspool SEO-d — tegelik surve tuleb konversioonide poolt. Tööstusuuringud näitavad järjepidevalt: mida kauem laadimine võtab, seda kõrgem on põrkemäär, vähem täidetakse vorme ja tehingud jäävad pooleli. Mobiilsed kasutajad on töölauakasutajatest palju kärsitumad ning Google indekseerib esmalt mobiili.

Investeerimine konversiooni optimeerimisse, ignoreerides tehnilist kiirust, on nagu lekist ämbri täitmine. Olenemata sellest, kui hästi on konversioonile orienteeritud maandumisleht kujundatud, lahkub külastaja enne selle nägemist, kui leht laadib aeglaselt.

Siiski ei piisa ainult Core Web Vitalsi parandamisest. Kiirus on usalduse esimene kiht — kuid seejärel peavad sisu, sõnumi selgus ja Next.js-iga ehitatud kiire ettevõtte saidi pakutav kasutajakogemus oma osa mängima. Mõlemad töötavad koos.