Core Web Vitals: Kas Tai, Kaip Matuoti ir Kaip Pagerinti (Pilnas Gidas 2026)

Jūsų svetainė gali turėti puikų turinį, profesionalų dizainą ir stiprų prekės ženklą. Bet jei puslapis kraunasi per lėtai, mygtukai reaguoja su uždelsimu arba turinys šokinėja ekrane, lankytojas išeina. Ir Google tai mato.

2021 metais Google pristatė Core Web Vitals, tris konkrečius rodiklius, kurie matuoja, kaip realūs žmonės patiria jūsų svetainę. Nuo tada šie rodikliai tapo reitingavimo signalu paieškos rezultatuose. Tai reiškia, kad jie tiesiogiai veikia, kiek žmonių randa jūsų svetainę ir ar joje lieka.

Šiame straipsnyje išnagrinėsime kiekvieną rodiklį atskirai, paaiškinsime, kaip juos matuoti, ir pateiksime konkrečius veiksmus, kurie pagerina rezultatus.

Kas yra Core Web Vitals?

Core Web Vitals yra trys standartizuoti rodikliai, kuriuos Google naudoja svetainės naudotojo patirčiai (user experience) vertinti. Kiekvienas rodiklis matuoja kitą patirties aspektą:

Rodiklis	Ką matuoja	Geras rezultatas
LCP (Largest Contentful Paint)	Krovimosi greitį	≤ 2,5 sekundės
INP (Interaction to Next Paint)	Interaktyvumą ir reagavimą	≤ 200 milisekundžių
CLS (Cumulative Layout Shift)	Vizualinį stabilumą	≤ 0,1

Šie trys rodikliai apima tai, kas žmogui svarbiausia: ar puslapis greitai atsidaro, ar reaguoja į paspaudimus ir ar turinys nestumdo vienas kito ekrane.

Google vertina kiekvieną rodiklį trimis lygiais:

Geras (žalias): pasiektas tikslas
Reikia tobulinti (oranžinis): yra problemų, bet ne kritinių
Prastas (raudonas): reikia skubiai taisyti

Rodiklis laikomas „geru”, kai bent 75 % visų realių apsilankymų patenka į žaliąją zoną. Tai reiškia, kad vertinamas ne vidurkis, o 75-asis procentilis (p75). Tokiu būdu net lėtesni apsilankymai turi atitikti standartą.

LCP: Largest Contentful Paint

Ką matuoja LCP?

LCP matuoja, kiek laiko praeina nuo puslapio užklausos iki tol, kol didžiausias matomas turinio elementas pilnai atvaizduojamas ekrane. Paprasčiau tariant: kiek laiko lankytojas turi laukti, kol pamato pagrindinį puslapio turinį.

Didžiausias turinio elementas gali būti:

Didelis paveikslėlis (hero image)
Vaizdo įrašo kadras (poster image)
Tekstinis blokas (antraštė arba pastraipa)
Foninis paveikslėlis, rodomas per CSS

LCP nematuoja viso puslapio krovimo. Jis matuoja tik tą momentą, kai lankytojas gauna vizualinį patvirtinimą, kad puslapis veikia ir turinys pasiekiamas.

Kodėl LCP svarbus?

Pirmasis įspūdis formuojasi per sekundes. Jei lankytojas mato tuščią ekraną 4–5 sekundes, jis daro išvadą, kad svetainė neveikia arba yra per lėta. Net jei likęs turinys kraunasi greitai, pirmasis lūkestis jau sugadintas.

Tyrimai rodo, kad kiekviena papildoma sekundė krovimosi laiko sumažina konversijų rodiklį 7–12 %. E-komercijos svetainėms tai tiesiogiai reiškia prarastus pardavimus.

LCP tiksliniai rodikliai

Geras: ≤ 2,5 sekundės
Reikia tobulinti: 2,5–4,0 sekundės
Prastas: > 4,0 sekundės

Kas sulėtina LCP?

Lėtas serverio atsakymas (TTFB)

Prieš bet ką rodant ekrane, naršyklė turi gauti atsakymą iš serverio. Jei serveris reaguoja lėtai (didelis Time to First Byte), viskas vėluoja.

Priežastys: lėtas hostingas, nenaudojama talpykla (cache), per daug duomenų bazės užklausų, serveris fiziškai toli nuo lankytojo.

Sprendimai:

Naudokite CDN (Cloudflare, Fastly, Bunny CDN), kad turinys būtų arčiau lankytojo
Įjunkite serverio lygio talpyklą (Redis, Memcached)
Optimizuokite duomenų bazės užklausas
Pasirinkite greitesnį hostingą, jei esamas serveris yra kliūtis

Blokuojantis JavaScript ir CSS

Naršyklė negali atrodyti puslapio, kol neatsisiunčia ir neapdoroja CSS ir JavaScript failų, kurie yra puslapio <head> dalyje. Jei šie failai dideli, viskas stoja.

Sprendimai:

Kritinį CSS (above-the-fold stiliams) įterpkite tiesiogiai į HTML (inline CSS)
Likusį CSS kraukite asinchroniškai
JavaScript failus žymėkite defer arba async atributu
Pašalinkite nenaudojamą CSS ir JavaScript kodą

Neoptimizuoti paveikslėliai

Jei LCP elementas yra paveikslėlis (o dažniausiai taip ir yra), jo dydis ir formatas tiesiogiai lemia LCP laiką.

Sprendimai:

Naudokite šiuolaikinius formatus: WebP arba AVIF (30–50 % mažesni nei JPEG)
Nurodykite width ir height atributus
Naudokite srcset atributą, kad naršyklė pasirinktų tinkamo dydžio paveikslėlį
LCP paveikslėliui pridėkite fetchpriority="high" atributą
Nenaudokite lazy loading LCP paveikslėliui (jis turi krautis iš karto)

Šriftų krovimas

Jei puslapis naudoja pasirinktinius šriftus ir LCP elementas yra tekstas, naršyklė gali laukti, kol šriftas atsisiųs, prieš rodydama tekstą.

Sprendimai:

Naudokite font-display: swap, kad tekstas matytųsi iš karto su atsarginiu šriftu
Iš anksto kraukite šriftus su <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
Ribokite šriftų skaičių iki 2 šeimų
Naudokite WOFF2 formatą (mažiausias dydis)

Praktinis LCP gerinimo pavyzdys

Tarkime, jūsų pagrindinis puslapis turi hero sekciją su dideliu paveikslėliu ir antrašte. LCP rodiklis rodo 4,8 sekundes. Štai žingsniai:

Patikrinkite, kas yra LCP elementas (PageSpeed Insights tai parodo)
Jei tai paveikslėlis: konvertuokite į WebP, sumažinkite iki reikiamo dydžio, pridėkite fetchpriority="high"
Perkelkite kritinį CSS į HTML <head> tiesiogiai
JavaScript failus pažymėkite defer
Įjunkite naršyklės talpyklą ir CDN

Dažnai šie penki žingsniai sumažina LCP nuo 4–5 sekundžių iki 1,5–2 sekundžių.

INP: Interaction to Next Paint

Ką matuoja INP?

INP (Interaction to Next Paint) matuoja, kiek laiko praeina nuo naudotojo veiksmo (paspaudimo, bakstelėjimo, klavišo paspaudimo) iki tol, kol naršyklė vizualiai sureaguoja. Tai reagavimo greičio rodiklis.

INP pakeitė ankstesnį rodiklį FID (First Input Delay) 2024 metų kovo mėnesį. Skirtumas: FID matavo tik pirmojo veiksmo uždelsimą, o INP vertina visas interakcijas per visą apsilankymą ir paima prasčiausią rezultatą (su tam tikra statistine korekcija).

Kodėl INP svarbus?

Įsivaizduokite: paspaudžiate mygtuką „Pridėti į krepšelį” ir nieko nevyksta. Paspaudžiate dar kartą. Ir dar. Po dviejų sekundžių krepšelyje atsiranda trys prekės. Tai prasta INP patirtis.

Lėtas reagavimas sukelia frustraciją ir nepasitikėjimą. Naudotojas nežino, ar veiksmas pavyko, ar svetainė „užlūžo”. Tai ypač svarbu mobiliuosiuose įrenginiuose, kur procesoriai silpnesni ir interakcijų daugiau.

INP tiksliniai rodikliai

Geras: ≤ 200 milisekundžių
Reikia tobulinti: 200–500 milisekundžių
Prastas: > 500 milisekundžių

200 milisekundžių yra riba, kurią žmogaus smegenys suvokia kaip „momentinį” atsaką. Viskas, kas ilgiau, jaučiama kaip uždelsimas.

Kas lėtina INP?

Ilgi JavaScript vykdymo procesai (Long Tasks)

Naršyklė turi vieną pagrindinę giją (main thread), kuri apdoroja ir JavaScript, ir vizualinius atnaujinimus. Jei JavaScript vykdymas užima 50 ir daugiau milisekundžių be pertraukos, naršyklė negali reaguoti į naudotojo veiksmus.

Šie „ilgi procesai” atsiranda, kai:

Kraunamos didelės JavaScript bibliotekos
Vykdomas sudėtingas duomenų apdorojimas
Trečiųjų šalių skriptai (reklamos, analitika, pokalbių valdikliai) blokuoja giją

Didelis DOM medis

Jei jūsų puslapyje yra tūkstančiai HTML elementų, kiekvienas vizualinis atnaujinimas reikalauja daugiau laiko. Naršyklė turi perskaičiuoti stilius ir perpiešti atnaujintą vaizdą.

Per daug klausytojų (event listeners)

Kai prie daugybės elementų pridedami JavaScript klausytojai, kiekvienas veiksmas gali sukurti „grandinę” procesų, kurie sulėtina atsaką.

Kaip pagerinti INP?

Suskaidykite ilgus procesus

Vietoj vieno ilgo JavaScript vykdymo, suskaidykite jį į mažesnes dalis, naudodami requestAnimationFrame() arba scheduler.yield():

// Blogai: vienas ilgas procesas
function processAllItems(items) {
    items.forEach(item => heavyComputation(item));
}

// Gerai: suskaidytas procesas
async function processAllItems(items) {
    for (const item of items) {
        heavyComputation(item);
        await scheduler.yield(); // leidžia naršyklei reaguoti
    }
}

Atidėkite nesvarbų JavaScript

Ne visas JavaScript yra reikalingas iš karto. Analitikos skriptai, pokalbių valdikliai, socialinių tinklų mygtukai gali būti kraunami po pagrindinės interakcijos.

Naudokite dinaminį importą:

// Kraukite komponentą tik kai jo reikia
button.addEventListener('click', async () => {
    const module = await import('./heavy-module.js');
    module.doSomething();
});

Mažinkite DOM dydį

Siekite, kad jūsų puslapyje būtų mažiau nei 1 500 DOM elementų. Kiekvieną kartą, kai naršyklė atnaujina vaizdą, ji turi apdoroti visą DOM medį. Mažesnis medis reiškia greitesnį apdorojimą.

Praktiškai tai reiškia:

Nenaudokite giliai įdėtų <div> elementų, kai to galima išvengti
Naudokite virtualų slinkimą (virtual scrolling) ilgiems sąrašams
Kraukite turinį dalimis (pvz., „Rodyti daugiau” mygtukas vietoj begalinio slinkimo su 500 elementų)

Optimizuokite trečiųjų šalių skriptus

Trečiųjų šalių skriptai (Google Analytics, Facebook Pixel, reklaminiai tinklai, pokalbių robotai) dažnai yra didžiausias INP priešas. Jie vykdo savo JavaScript jūsų puslapyje ir konkuruoja dėl pagrindinės gijos.

Sprendimai:

Kraukite trečiųjų šalių skriptus su async arba defer
Naudokite Google Tag Manager su nustatytais trigeriais (pvz., kraukite pokalbių valdiklį tik po 5 sekundžių)
Periodiškai peržiūrėkite, ar visi trečiųjų šalių skriptai vis dar reikalingi
Naudokite Partytown biblioteką, kuri perkelia trečiųjų šalių skriptus į web worker giją

CLS: Cumulative Layout Shift

Ką matuoja CLS?

CLS matuoja, kiek puslapio elementai netikėtai pasislenka krovimosi metu ir po jo. Tai vizualinio stabilumo rodiklis.

Kiekvienas netikėtas poslinkis gali sugadinti naudotojo patirtį. Klasikinis pavyzdys: pradėjote skaityti straipsnį, bet staiga viršuje „iššoko” reklamos baneris ir tekstas nuslinko žemyn. Arba jau taikėtės pirštu paspausti mygtuką, bet tuo metu pakrauta nuotrauka pastūmė viską ir paspaudėte visiškai kitą elementą.

Kaip skaičiuojamas CLS?

CLS skaičiuojamas pagal formulę:

$$\text{CLS} = \text{Impact Fraction} \times \text{Distance Fraction}$$

Impact Fraction: kiek ekrano ploto buvo paveikta poslinkio
Distance Fraction: kiek toli elementas pasislinkė (pikseliais, proporciniu santykiu su ekranu)

Kuo daugiau elementų slenka ir kuo toliau jie slenka, tuo didesnis CLS. Rezultatas kaupiamas per visą apsilankymo sesiją, todėl rodiklis vadinamas „kumuliaciniu” (cumulative).

Nuo 2024 metų Google vertina CLS naudodamas „sesijų langus” (session windows). Poslinkiai grupuojami į 5 sekundžių langus, tarp kurių yra bent 1 sekundės pertrauka. Vertinamas prasčiausias langas. Tai reiškia, kad pavieniai maži poslinkiai mažiau kenkia nei staigūs, didelio masto pokyčiai.

CLS tiksliniai rodikliai

Geras: ≤ 0,1
Reikia tobulinti: 0,1–0,25
Prastas: > 0,25

Kas sukelia CLS problemas?

Paveikslėliai ir vaizdo įrašai be dydžio atributų

Kai naršyklė pradeda krauti puslapį, ji nežino paveikslėlio dydžio, kol jis neatsisiųstas. Jei <img> elemente nėra width ir height atributų, naršyklė iš pradžių neskiria vietos paveikslėliui. Kai paveikslėlis pakraunamas, viskas aplink jį pasislenka.

Sprendimas:

<!-- Blogai: nėra dydžio -->
<img src="nuotrauka.webp" alt="Produktas">

<!-- Gerai: nurodytas dydis -->
<img src="nuotrauka.webp" alt="Produktas" width="800" height="600">

<!-- Gerai: CSS aspect-ratio -->
<img src="nuotrauka.webp" alt="Produktas" style="aspect-ratio: 4/3; width: 100%;">

Dinamiškai įterpiamas turinys

Reklamos, naujienlaiškių formos, cookie pranešimai ir kiti elementai, kurie atsiranda po pradinio krovimo, stumia esamą turinį. Tai ypač dažna problema naujienų svetainėse ir tinklaraščiuose.

Sprendimai:

Iš anksto rezervuokite vietą reklamoms su fiksuoto dydžio konteineriais
Cookie pranešimus rodykite ekrano apačioje (overlay), o ne viršuje (inline)
Naujienlaiškių formas integruokite į turinio eigą, o ne terpkite dinamiškai

Šriftų krovimas ir FOUT/FOIT

Kai pasirinktas šriftas dar nekraunamas, naršyklė gali:

Rodyti tekstą atsarginiu šriftu ir pakeisti, kai tikrasis pakraunamas (FOUT, Flash of Unstyled Text). Tai sukelia CLS, nes šriftai turi skirtingus dydžius
Slėpti tekstą, kol šriftas pakraunamas (FOIT, Flash of Invisible Text). Tai sukelia LCP problemų

Sprendimai:

Naudokite font-display: optional (geriausias CLS atžvilgiu, bet šriftas gali nebūti rodomas lėtame ryšyje)
Arba font-display: swap su size-adjust korekcija, kad atsarginis šriftas užimtų panašią vietą kaip tikrasis
Iš anksto kraukite šriftus su <link rel="preload">

Vėluojantis CSS

Jei CSS kraunamas asinchroniškai ir stiliai pritaikomi po to, kai turinys jau matomas, elementai gali staigiai pakeisti savo poziciją, dydį ir tarpus.

Sprendimas: kritinį CSS (stiliams, kurie matomi pirmo ekrano vaizde) visada įterpkite tiesiogiai į HTML.

CLS derinimo įrankis

Chrome DevTools turi specialų CLS derinimo režimą:

Atidarykite DevTools (F12)
Eikite į „Performance” skiltį
Įjunkite „Web Vitals” žymeklį
Užfiksuokite puslapio krovimą
Laiko juostoje matysite kiekvieną layout shift, jo dydį ir kuris elementas pasislinkė

Tai padeda tiksliai nustatyti, kuris elementas sukelia problemą, o ne spėlioti.

Kaip matuoti Core Web Vitals?

Core Web Vitals matavimas skirstomas į dvi kategorijas: lauko duomenis (field data) ir laboratoriniai duomenis (lab data). Abu yra svarbūs, bet jie rodo skirtingus dalykus.

Lauko duomenys (Field Data)

Lauko duomenys rodo, kaip tikri naudotojai patiria jūsų svetainę realiomis sąlygomis, su tikrais įrenginiais, tikru interneto greičiu ir tikru elgesiu.

Google renka šiuos duomenis per Chrome naudotojų patirties ataskaitą (Chrome User Experience Report, CrUX). Tik lauko duomenys naudojami kaip reitingavimo signalas.

Kur matyti lauko duomenis:

Google Search Console → Core Web Vitals ataskaita: rodo, kiek puslapių yra „gerame”, „reikia tobulinti” ir „prastu” lygyje. Grupuoja panašius puslapius, todėl matote bendrą situaciją
PageSpeed Insights: viršutinėje dalyje rodo lauko duomenis (jei jų pakanka). Rodiklis pagrįstas paskutinių 28 dienų realiais apsilankymais
CrUX Dashboard (Data Studio): vizualizuoja Core Web Vitals tendencijas per laiką

Svarbu: lauko duomenys atsiranda tik kai svetainė turi pakankamai lankytojų. Mažos svetainės gali neturėti lauko duomenų, ir PageSpeed Insights rodys tik laboratorinius rezultatus.

Laboratoriniai duomenys (Lab Data)

Laboratoriniai duomenys gaunami kontroliuojamoje aplinkoje, su fiksuotais tinklo ir įrenginio parametrais. Jie naudingi diagnostikai ir optimizavimui, bet neatspindi realios naudotojų patirties.

Įrankiai:

Google Lighthouse: integruotas Chrome DevTools, teikia detalią analizę su konkrečiomis rekomendacijomis
PageSpeed Insights (apatinė dalis): rodo Lighthouse rezultatus
WebPageTest: leidžia testuoti iš skirtingų lokacijų ir su skirtingais įrenginiais
Chrome DevTools Performance panel: detalus laiko juostos vaizdas

Skirtumas tarp lauko ir laboratorinių duomenų

Aspektas	Lauko duomenys	Laboratoriniai duomenys
Šaltinis	Tikri naudotojai	Simuliuota aplinka
Įrenginiai	Įvairūs (pigūs telefonai, galingi kompiuteriai)	Standartizuotas (vidutinis telefonas)
Interneto greitis	Realus (4G, Wi-Fi, lėtas 3G)	Fiksuotas (dažniausiai 4G)
SEO poveikis	Tiesioginis (reitingavimo signalas)	Netiesioginis (diagnostikai)
Atnaujinimo dažnis	Kas 28 dienas	Iš karto po testo

Praktinis patarimas: naudokite laboratorinius duomenis problemoms identifikuoti ir sprendimams testuoti, bet sėkmę vertinkite pagal lauko duomenis. Laboratorijoje galite gauti 95 balus, bet jei tikri naudotojai su senesniais telefonais patiria lėtą svetainę, lauko duomenys tai parodys.

Core Web Vitals ir SEO: koks ryšys?

Google patvirtino, kad Core Web Vitals yra reitingavimo signalas. Tai reiškia, kad jie daro įtaką jūsų pozicijai paieškos rezultatuose. Bet svarbu suprasti šio signalo svorį kontekste.

Core Web Vitals yra vienas iš daugelio signalų

Turinio kokybė, raktažodžių atitikimas, nuorodų profilis, E-E-A-T (patirtis, ekspertizė, autoritetingumas, patikimumas) vis dar yra stipresni signalai nei puslapio greitis. Puslapis su puikiu turiniu ir vidutiniais Core Web Vitals rezultatais dažniausiai lenks puslapį su tuščiu turiniu ir tobulais greičio rodikliais.

Bet kai du puslapiai turi panašios kokybės turinį ir panašų nuorodų profilį, Core Web Vitals gali nuspręsti, kuris rodomas aukščiau.

Kur Core Web Vitals turi didžiausią poveikį?

Konkurencingose nišose: kai daugelis svetainių turi panašų turinį, patirties rodikliai tampa lemiami
Vietinėje paieškoje: mobilioji patirtis ypač svarbi vietiniams rezultatams, kur žmonės ieško greitų atsakymų
Google Discover: Google Discover srautas priklauso nuo turinio kokybės ir puslapio patirties. Core Web Vitals yra vienas iš tinkamumo kriterijų
Top Stories karuselėje: naujienų svetainėms geri Core Web Vitals rodikliai yra privalomi norint patekti į viršutinę naujienų karuselę

Netiesioginis poveikis

Net jei ignoruotumėte tiesioginį SEO signalą, Core Web Vitals gerinimas sukuria grandinę teigiamų efektų:

Greičiau besikreipiantis puslapis → mažesnis atmetimo rodiklis (bounce rate)
Mažesnis atmetimo rodiklis → ilgesnis sesijos laikas
Ilgesnis sesijos laikas → daugiau puslapių per apsilankymą
Daugiau interakcijų → geresnės konversijos
Google mato šiuos elgsenos signalus → geresnės pozicijos

Tai uždaras ratas, kuriame greitis ir patirtis maitina vienas kitą.

Optimizavimo prioritetai: nuo ko pradėti?

Jei visi trys rodikliai rodo raudoną spalvą, gali atrodyti, kad viskas blogai ir nežinote, nuo ko pradėti. Štai rekomenduojama eilės tvarka:

Pirmas prioritetas: CLS

CLS dažnai galima sutvarkyti greičiausiai ir su mažiausiomis pastangomis. Pridėti width ir height atributus paveikslėliams, rezervuoti vietą reklamoms, sutvarkyti šriftų krovimą. Šie pakeitimai yra mažos rizikos ir duoda greitus rezultatus.

Antras prioritetas: LCP

LCP gerinimas dažniausiai reikalauja paveikslėlių optimizavimo, CSS pertvarkymo ir serverio greičio gerinimo. Tai gali užtrukti ilgiau, bet poveikis yra didelis, nes LCP tiesiogiai veikia pirmąjį lankytojo įspūdį.

Trečias prioritetas: INP

INP yra sudėtingiausias rodiklis, nes jis priklauso nuo JavaScript architektūros. Gerinimas gali reikalauti kodo refaktorizavimo, trečiųjų šalių skriptų peržiūros ir kartais visiškai kitokio požiūrio į interaktyvumą. Pradėkite nuo didžiausių kaltininkų (dažniausiai trečiųjų šalių skriptai) ir eikite gilyn.

Platforma kiekvienai situacijai

Skirtingos svetainių platformos turi skirtingus Core Web Vitals iššūkius ir sprendimus.

WordPress

WordPress svetainės dažnai kenčia nuo lėto LCP ir didelio CLS. Priežastys: per daug įskiepių, neoptimizuotos temos, neapdoroti paveikslėliai.

Sprendimai:

Naudokite talpyklos (caching) įskiepį: WP Rocket, LiteSpeed Cache arba W3 Total Cache
Optimizuokite paveikslėlius su ShortPixel arba Imagify
Naudokite lengvą, greitą temą (GeneratePress, Kadence, Astra)
Atidėkite nebūtiną JavaScript su WP Rocket arba Flying Scripts
Mažinkite aktyvių įskiepių skaičių

Shopify

E-komercijos svetainės turi papildomų iššūkių: produktų paveikslėliai, kainos atnaujinimai, krepšelio funkcionalumas.

Sprendimai:

Pasirinkite greitą temą (Dawn yra oficiali greita tema)
Ribokite trečiųjų šalių programėles
Naudokite „native” lazy loading produktų paveikslėliams
Optimizuokite Liquid šablonus

Custom svetainės (React, Vue, Next.js)

JavaScript frameworks svetainės dažnai turi INP problemas, nes kliento pusėje vykdomas didelis kiekis kodo.

Sprendimai:

Naudokite serverio pusės atvaizdavimą (SSR) arba statinę generaciją (SSG)
Taikykite kodo skaidymą (code splitting) ir dinaminį importavimą
Naudokite React Server Components (Next.js App Router)
Stebėkite JavaScript paketo dydį ir ribokite jį

Stebėjimas ir nuolatinis gerinimas

Core Web Vitals optimizavimas nėra vienkartinė užduotis. Naujas įskiepis, nauja reklama, naujas turinio blokas gali pabloginti rodiklius bet kuriuo metu. Todėl stebėjimas turi būti nuolatinis.

Automatizuotas stebėjimas

Nustatykite reguliarų stebėjimą, kad žinotumėte apie problemas anksčiau nei jas pamatys Google:

Google Search Console: tikrinkite Core Web Vitals ataskaitą bent kartą per savaitę. Jei staiga atsiranda raudonų puslapių, reaguokite greitai
SpeedCurve arba Calibre: komerciniai įrankiai, kurie testuoja jūsų svetainę automatiškai ir siunčia perspėjimus, kai rodikliai pablogėja
web-vitals JavaScript biblioteka: integruokite tiesiai į savo svetainę ir siųskite duomenis į analitikos platformą

import {onLCP, onINP, onCLS} from 'web-vitals';

onLCP(metric => sendToAnalytics('LCP', metric));
onINP(metric => sendToAnalytics('INP', metric));
onCLS(metric => sendToAnalytics('CLS', metric));

Reguliari peržiūra

Kartą per mėnesį skirkite laiko šiam patikrinimui:

Ar visi pagrindiniai puslapiai turi „gerus” Core Web Vitals rodiklius?
Ar yra naujų trečiųjų šalių skriptų, kurie galėjo sulėtinti svetainę?
Ar naujas turinys (paveikslėliai, vaizdo įrašai) yra optimizuotas?
Ar buvo atnaujintas koks nors įskiepis ar tema, kurie galėjo paveikti greitį?

Dažniausios klaidos optimizuojant Core Web Vitals

Optimizuoti tik pagrindįnį puslapį

Daugelis žmonių testuoja tik pagrindinį puslapį (homepage) ir mano, kad to pakanka. Google vertina kiekvieną puslapį atskirai. Jūsų tinklaraščio įrašai, produktų puslapiai, kategorijų puslapiai gali turėti visiškai kitokius rodiklius.

Search Console Core Web Vitals ataskaita grupuoja panašius puslapius, todėl galite matyti, kurios puslapių grupės turi problemų.

Pasikliauti tik Lighthouse balu

Lighthouse balas (0–100) yra naudingas orientyras, bet jis nematuoja realios naudotojų patirties. Galite gauti 95 balus laboratorijoje, o realūs naudotojai su senais telefonais ir lėtu internetu patirs visiškai kitokią svetainę.

Žiūrėkite lauko duomenis (CrUX). Tai yra tikrasis matas.

Per daug optimizuoti vienoje vietoje

Kartais, bandant pagerinti LCP, galite pabloginti CLS. Pavyzdžiui, agresyvus lazy loading gali sukurti layout shift, kai paveikslėliai pakraunami. Arba JavaScript atidėjimas gali pabloginti INP, jei skriptai kraunami visi iš karto vėliau.

Optimizuokite visus tris rodiklius kartu ir po kiekvieno pakeitimo patikrinkite, ar nepablogėjo kitas rodiklis.

Ignoruoti mobiliąją versiją

Google naudoja mobile-first indeksavimą. Core Web Vitals vertinami pagal mobiliąją versiją. Jei optimizuojate tik darbalaukio greitį, praleidžiate tai, kas tikrai svarbu.

Visada pirmiausia testuokite mobiliąją versiją. Jei mobilioji versija rodo gerus rodiklius, darbalaukio versija beveik visada bus dar geresnė (nes turi daugiau resursų).

Core Web Vitals ateitis

Google reguliariai peržiūri ir atnaujina Core Web Vitals rodiklius. FID pakeitimas INP rodikliu 2024 metais parodė, kad sistema evoliucionuoja.

Keletas tendencijų, kurios gali paveikti ateitį:

Sudėtingesnių interakcijų matavimas: su vis sudėtingesnėmis web aplikacijomis (SPA, PWA), interaktyvumo matavimas gali tapti dar detalesnis
Sklandaus slinkimo (smoothness) rodiklis: Google yra tyrinėjęs animacijų ir slinkimo sklandumo matavimą kaip galimą naują rodiklį
Prieinamumo (accessibility) integracija: prieigos galimybės gali tapti dar vienu puslapio patirties aspektu, kurį Google vertina
AI sugeneruoto turinio greitis: kadangi vis daugiau turinio generuojama dinamiškai, serverio apdorojimo greitis tampa dar svarbesnis

Ką daryti šiandien?

Pradėkite nuo trijų veiksmų:

Išmatuokite dabartinę situaciją: atidarykite Google Search Console → Core Web Vitals ir pažiūrėkite, kiek puslapių turi problemų. Jei neturite Search Console, pradėkite nuo PageSpeed Insights ir patikrinkite 5 svarbiausius puslapius
Išspręskite didžiausią problemą: pasirinkite rodiklį, kuris rodo prasčiausią rezultatą, ir taikykite šiame straipsnyje aprašytus sprendimus. Dažniausiai tai bus CLS (lengviausia sutvarkyti) arba LCP (didžiausias poveikis)
Nustatykite stebėjimą: pridėkite web-vitals biblioteką arba nustatykite reguliarų PageSpeed Insights tikrinimą, kad matytumėte, ar pakeitimai veikia ir ar nauji pakeitimai nepablogina situacijos

Geri Core Web Vitals rodikliai nėra tik techninė metrika. Jie yra signalas, kad jūsų svetainė gerbia lankytojo laiką. O svetainė, kuri gerbia lankytojo laiką, pelno ir jo pasitikėjimą, ir Google palankumą.