Arendus 14. juuli 2026
Core Web Vitals: mis mõjutab positsioone ja mis lihtsalt häirib kasutajat
Core Web Vitals on kolm mõõdikut: LCP, INP ja CLS. 2025. aasta Web Almanac näitab, et alla poole mobiilsaitidest läbib kõik kolm. Siin on, mis tasub parandada.
Core Web Vitals mõõdab, kuidas leht kasutajale tundub: kui kiiresti põhisisu ilmub, kui kiiresti leht klikile vastab ja kas elemendid hüplevad. Need on kolm mõõdikut ja igaühe jaoks on selge piir.
Kolm mõõdikut ja piirid
- LCP (suurima sisu ilmumine): hea kuni 2,5 sekundit
- INP (vastus interaktsioonile): hea kuni 200 millisekundit, kehv üle 500 ms
- CLS (paigutuse nihe): hea kuni 0,1
Hindamine käib 75. protsentiili järgi päris kasutajate andmetest, eraldi mobiilil ja töölaual. Labori skoor (näiteks Lighthouse) on abivahend, mitte otsustaja.
Kuidas turg seisab
Näide: HTTP Archive’i Web Almanac 2025 järgi läbis kõik kolm mõõdikut 48% mobiilsaitidest (aasta varem 44%) ja 56% töölauasaitidest. Mobiilis oli INP heal tasemel 77%, LCP 62% ja CLS 81% saitidest. LCP on seega kõige nõrgem lüli.
See tähendab, et enamik saite kaotab LCP-l, mitte INP-l. Kui sinu leht on samal tasemel kui keskmine, on LCP parandamine suurim kiire võit.
INP: kust viivitus tuleb
INP asendas FID-i ja mõõdab kogu külastuse jooksul kõige pikemat interaktsiooni (erandid välja arvatud). See jaguneb kolmeks: sisendi viivitus, töötlusaeg ja joonistamise viivitus.
- pikad JavaScripti ülesanded põhilõimes blokeerivad klikkide töötlemist
- suur DOM ja kallid stiiliarvutused pikendavad joonistamist
- kolmandate osapoolte skriptid (vestlus, analüütika, reklaam) varastavad aega kõigilt
Mis tõesti mõjutab positsioone
Google nimetab lehe kogemust üheks kvaliteedisignaaliks, kuid sisu asjakohasus on olulisem. Kiirus üksi harva otsustab, kes on tipus, aga kehv LCP ja hüplev paigutus panevad kasutaja lahkuma. Kiirus on seetõttu eelkõige konversiooni küsimus ja alles seejärel järjestuse küsimus.
Mida teha: parandusjärjekord
- Mõõda esmalt päris andmeid (Search Console’i Core Web Vitals aruanne, PageSpeed Insights’i CrUX-osa)
- LCP: eelista serveris renderdatud HTML-i, anna põhipildile õiged mõõtmed ja kõrge prioriteet, ära laadi seda laisalt
- CLS: määra piltidele ja reklaamikohtadele width ja height, laadi fondid ilma hüppeta
- INP: jaga pikad ülesanded, lükka kolmanda osapoole skriptid edasi, vähenda DOM-i
- Kontrolli tulemust 28 päeva pärast, sest väljamõõdetud andmed uuenevad libiseva aknaga
Näide praktikast
Selle saidi lehed genereeritakse ette staatilise HTML-ina, nii et esimene baitide vastus on kiire ja põhisisu on olemas ilma JavaScriptita. Pildid on mõõtmetega, et paigutus ei nihkuks. See on LCP ja CLS jaoks odavaim viis, mis töötab ka INP jaoks, sest vähem JavaScripti tähendab vähem pikki ülesandeid.
Kiire kontrollnimekiri enne väljalaset
- Põhipildil on mõõtmed ja see ei ole laisalt laetud
- Fondid ei põhjusta nähtavat hüpet
- Kolmanda osapoole skriptid laadivad pärast põhisisu
- Interaktiivsed elemendid vastavad klikile ilma silmatorkava viivituseta
Kolm küsimust
Miks Lighthouse’i skoor ja Search Console erinevad?
Lighthouse on labori mõõtmine ühe seadme ja ühe sirvimisega. Search Console näitab päris kasutajate andmeid 75. protsentiili järgi. Otsustamisel loeb teine.
Kui kiiresti parandus nähtavale tuleb?
Väljamõõdetud andmed uuenevad libiseva 28 päeva aknaga, seega täielik efekt ilmneb umbes kuu pärast. Ära tee järeldust kolme päeva põhjal.
Kumb on tähtsam: mobiil või töölaud?
Mõlemat hinnatakse eraldi, kuid mobiil on nõrgem: Web Almanac 2025 järgi läbib kõik kolm mõõdikut 48% mobiilsaitidest ja 56% töölauasaitidest. LCP-s on mobiilis „kehvade“ saitide osa peaaegu kaks korda suurem (13% versus 7%).
Kokkuvõte
Alusta päris andmetest, paranda esmalt LCP, siis CLS ja INP, ning vaata tulemust kuu aja pärast. Kiire sait ei taga positsiooni, aga aeglane sait kaotab kindlasti külastajaid.

