Jūsų svetainė gali turėti puikų turinį ir stiprias nuorodas — tačiau jei ji lėtai įkeliama ar elementai „šokinėja“ ekrane, Google tai mato ir tai veikia reitingus. Core Web Vitals tapo neatskiriama techninio SEO dalimi, ir 2026 m. jų reikšmė tik auga. Šiame vadove — išsami kiekvieno rodiklio analizė su konkrečiais optimizavimo veiksmais.

Kas yra Core Web Vitals ir kodėl Google juos vertina

Core Web Vitals (CWV) — tai Google apibrėžta trijų rodiklių sistema, matuojanti realią naudotojų patirtį svetainėje. Jie buvo įvesti kaip oficialus reitingavimo veiksnys 2021 m. ir nuo tada reguliariai atnaujinami.

Kodėl Google rūpinasi šiais rodikliais? Nes Google pelnas priklauso nuo to, ar vartotojai pasitiki jo paieška. Jei Google nukreipia žmones į lėtas, nestabilias svetaines — naudotojai praranda pasitikėjimą ir pereina prie alternatyvų. Core Web Vitals yra Google garantija, kad jo rekomenduojamos svetainės veikia sklandžiai.

Trys pagrindiniai rodikliai:

  • LCP (Largest Contentful Paint) — įkėlimo greitis: per kiek laiko ekrane atsiranda didžiausias matomas turinys
  • INP (Interaction to Next Paint) — interaktyvumas: kaip greitai puslapis reaguoja į vartotojo veiksmus
  • CLS (Cumulative Layout Shift) — vizualinis stabilumas: kiek elementai juda įkėlimo metu

Atlikus SEO auditą, Core Web Vitals problemos dažniausiai yra tarp pirmųjų techninių trūkumų, kuriuos randame Lietuvos svetainėse — ypač mobiliosiose versijose.

LCP (Largest Contentful Paint) — kaip pagerinti įkėlimo greitį

LCP matuoja, per kiek laiko nuo puslapio atidarymo ekrane pasirodo didžiausias matomas elementas — dažniausiai tai hero paveikslėlis, didelis antraštės tekstas arba vaizdo įrašo miniatiūra.

Geri, vidutiniai ir blogi LCP rezultatai

  • Geras: iki 2,5 sekundės — žalias indikatorius PageSpeed Insights
  • Reikia tobulinti: 2,5–4,0 sekundės — geltonas indikatorius
  • Blogas: virš 4,0 sekundžių — raudonas indikatorius, reikalingas skubus veiksmas

Serverio atsakymo laikas (TTFB)

TTFB (Time to First Byte) — tai laikas nuo užklausos iki pirmo serverio atsakymo baito. Blogas TTFB automatiškai reiškia blogą LCP, nes viskas prasideda čia. Rekomenduojamas TTFB — iki 600 ms.

Ką daryti:

  • Pereikite prie greito hostingo — VPS ar dedikuoto serverio, ne pigaus shared hosting
  • Įjunkite serverio lygio kešavimą (Redis, Memcached)
  • Optimizuokite duomenų bazės užklausas (ypač WordPress su daug įskiepių)
  • Naudokite HTTP/2 arba HTTP/3 protokolą — jie žymiai spartesni nei HTTP/1.1

Render-blocking resursai

Render-blocking — tai CSS ir JavaScript failai, kurie stabdo puslapio atvaizdavimą tol, kol pilnai įkeliami. Tai viena dažniausių LCP problemų.

Sprendimai:

  • Kritinį CSS (above-the-fold) įdėkite tiesiai į HTML <head> kaip inline stilius
  • Nekritinį CSS įkelkite asinchroniškai: <link rel="stylesheet" media="print" onload="this.media='all'">
  • JavaScript failams pridėkite defer arba async atributą
  • Perkelkite <script> žymes į <body> pabaigą

Paveikslėlių optimizavimas

Paveikslėliai yra dažniausia LCP elemento priežastis — ir dažniausia problema. Trys pagrindiniai principai:

  • WebP formatas — vidutiniškai 25–35% mažesni nei JPEG, palaikomas visų šiuolaikinių naršyklių. Naudokite <picture> elementą su fallback: <source type="image/webp" srcset="hero.webp"><img src="hero.jpg">
  • Preload LCP paveikslėliui — pridėkite <head>: <link rel="preload" as="image" href="hero.webp" fetchpriority="high">. Tai vieninteliam LCP elementui, ne visiems paveikslėliams.
  • Lazy loading ne LCP elementui — visiems kitiems paveikslėliams naudokite loading="lazy", bet LCP elementui — jokiu būdu ne, tai jį sulėtins

CDN naudojimas

CDN (Content Delivery Network) talpina jūsų svetainės failus skirtinguose pasaulio serveriuose ir pateikia juos iš artimiausio vartotojui taško. Lietuvos svetainėms rekomenduojame CDN su serveriais Vakarų Europoje (Frankfurtas, Amsterdamas). Populiarios parinktys: Cloudflare (yra nemokamas planas), Bunny.net, AWS CloudFront.

INP (Interaction to Next Paint) — interaktyvumo optimizavimas

INP pakeitė FID (First Input Delay) 2024 m. kovą. Skirtumas esminis: FID matė tik pirmą sąveiką, o INP stebi visas sąveikas per viso puslapio gyvavimo laikotarpį ir pateikia 98-ą procentilį.

Geri, vidutiniai ir blogi INP rezultatai

  • Geras: iki 200 milisekundžių
  • Reikia tobulinti: 200–500 ms
  • Blogas: virš 500 ms

Kaip matuoti INP

INP sunkiau matuoti nei LCP, nes reikia realios sąveikos. Metodai:

  • Chrome DevTools → Performance — įrašykite sesiją ir analizuokite Long Tasks (ilgiau nei 50 ms trunkančios užduotys)
  • web-vitals JavaScript biblioteka — pridėkite į svetainę ir siųskite duomenis į Analytics
  • Chrome User Experience Report (CrUX) — realių vartotojų duomenys per PageSpeed Insights

JavaScript optimizavimas

JavaScript yra pagrindinė INP problemų priežastis. Pagrindinis tikslas — sumažinti darbo krūvį pagrindinėje gijoje (main thread).

  • Code splitting — skaidykite didelį JS bundle į mažesnius failus, įkeliamus tik tada, kai reikia. React ir Vue tai daro automatiškai su dinaminiais importais.
  • Tree shaking — pašalinkite nenaudojamą kodą iš bibliotekų. Vietoj pilno lodash importo: import debounce from 'lodash/debounce'
  • Trečiųjų šalių skriptai — Google Tag Manager, chat widgetai, reklamos skriptai gali rimtai pakenkti INP. Įkelkite juos asinchroniškai ir po puslapio įkėlimo.

Ilgos užduotys (Long Tasks)

Long Task — tai bet kokia JavaScript užduotis, trunkanti ilgiau nei 50 ms. Kol ji vyksta, naršyklė negali reaguoti į vartotojo veiksmus. Sprendimas — suskaidyti jas į mažesnes dalis naudojant setTimeout(fn, 0) arba scheduler.yield() (nauja API):

async function processLargeList(items) {
  for (const item of items) {
    processItem(item);
    await scheduler.yield(); // grąžina valdymą naršyklei
  }
}

Input handlers optimizavimas

Kiekvieną kartą paspaudus mygtuką ar įvedus tekstą, naršyklė vykdo event handler funkciją. Jei ji lėta — INP kenčia. Naudokite debounce paieškos laukams (ne kiekvienam klavišo paspaudimui siųskite užklausą) ir passive event listeners slinkties įvykiams: addEventListener('scroll', fn, { passive: true }).

CLS (Cumulative Layout Shift) — vizualinio stabilumo taisymas

CLS matuoja, kiek elementai juda ekrane be vartotojo iniciatyvos. Klasikinis pavyzdys: skaitote straipsnį, atsikrauna reklama ir visas tekstas sujuda žemyn — paspaudžiate ne tą nuorodą. Tai blogas CLS.

Geri, vidutiniai ir blogi CLS rezultatai

  • Geras: iki 0,1
  • Reikia tobulinti: 0,1–0,25
  • Blogas: virš 0,25

Paveikslėlių ir vaizdo įrašų dimensijos

Dažniausia CLS priežastis — paveikslėliai be nurodytų matmenų. Naršyklė nežino, kiek vietos rezervuoti, kol paveikslėlis neįkrautas — ir perskaičiuoja išdėstymą jam pasirodžius.

Sprendimas: visada nurodykite width ir height atributus:

<img src="produktas.webp" width="800" height="600" alt="Produkto nuotrauka">

Šiuolaikinės naršyklės naudoja šiuos atributus apskaičiuoti aspektų santykį dar prieš įkeliant paveikslėlį, net jei CSS pakeičia faktinį dydį.

Šriftų įkėlimas (font-display)

Kai svetainė naudoja Google Fonts ar kitus web šriftus, naršyklė gali trumpam rodyti tekstą sisteminiu šriftu, tada persijungti į web šriftą — tai sukelia CLS. Sprendimas — font-display: swap:

@font-face {
  font-family: 'Roboto';
  font-display: swap; /* rodyti sistemini šriftą iš karto, pakeisti kai įkeliama */
  src: url('roboto.woff2') format('woff2');
}

Dar geriau — naudokite šriftų preload su <link rel="preload" as="font"> ankstyvo įkėlimo šriftų.

Dinamiškai įkeliamas turinys (skelbimai, banneriai)

Reklamos blokai, chat widgetai ir kiti dinamiškai įkeliami elementai yra bene didžiausia CLS problema komercinėse svetainėse. Sprendimas — visada rezervuokite vietą šiems elementams:

.ad-container {
  min-height: 250px; /* rezervuota vieta reklamai */
  width: 100%;
}

Jei reklama neįkeliama — vieta lieka tuščia, bet išdėstymas nesikeičia. Tai geriau nei CLS bausmė.

Kaip išmatuoti Core Web Vitals

Yra du duomenų tipai: laboratoriniai (lab) ir lauko (field) duomenys. Kiekvienas įrankis teikia skirtingus duomenis.

PageSpeed Insights (pagespeed.web.dev)

Greičiausias pradinis patikrinimas. Pateikia tiek lab, tiek field duomenis (jei svetainė turi pakankamai srauto). Įveskite URL ir gaukite momentinę ataskaitą. Pirmiausia žiūrėkite į mobiliuosius rezultatus — jie svarbesni.

Google Search Console

Search Console → Core Web Vitals ataskaita rodo realių jūsų vartotojų duomenis per 28 dienų laikotarpį. Ši ataskaita grupuoja panašius URL ir identifikuoja sistemines problemas. Labai svarbi, nes parodo faktinę vartotojų patirtį, o ne simuliuotą.

Lighthouse (Chrome DevTools)

Atidarykite Chrome DevTools (F12) → Lighthouse → Generate report. Pateikia detaliausią analizę su konkrečiomis rekomendacijomis ir galimų sutaupymų skaičiavimais. Galima paleisti lokaliai, todėl tinka testavimui prieš publikuojant pakeitimus.

Chrome DevTools Performance įrankis

Pažangesnis įrankis JavaScript problemų diagnostikai. Įrašykite puslapio įkėlimą arba sąveikos sesiją ir analizuokite, kurios užduotys blokuoja pagrindinę giją. Būtinas INP optimizavimui.

Skirtumai tarp lab duomenų ir field duomenų

Tai vienas dažniausių nesusipratimų šaltinių, su kuriuo susiduriame per SEO auditą:

  • Lab duomenys (laboratoriniai) — simuliuojami standartizuotomis sąlygomis (konkretus įrenginys, konkretus tinklas). Pateikia Lighthouse, PageSpeed Insights simuliacija. Naudingi problemų diagnostikai, bet neatspindi realių vartotojų patirties.
  • Field duomenys (lauko) — surinkti iš realių Chrome naršyklės vartotojų, naudoja CrUX duomenų bazę. Pateikia PageSpeed Insights viršutinė dalis ir Search Console. Šie duomenys nulemia faktinį SEO poveikį.

Galimas scenarijus: Lighthouse rodo gerą LCP, bet Search Console rodo blogą — nes realūs vartotojai naudoja lėtesnius įrenginius ar ryšius nei simuliacija. Visada patikrinkite abu.

Mobilioji vs. kompiuterio CWV — kodėl mobilioji svarbesnė

Google naudoja mobile-first indexing — tai reiškia, kad svetainę indeksuoja ir reitinguoja pagal mobiliosios versijos turinį ir greitį. Core Web Vitals taip pat vertinami pirmiausia pagal mobiliosios versijos rezultatus.

Lietuvos statistika (pagal Gemius/Kantar): apie 60–65% interneto srauto ateina iš mobilių įrenginių. Jei jūsų svetainė kompiuteryje veikia puikiai, bet mobiliojoje — vidutiniškai, jūs prarandate daugiau nei pusę potencialios auditorijos ir reitingų galimybių.

Pagrindinės mobiliojo CWV problemos:

  • Didelio dydžio paveikslėliai, neadaptuoti mažesniam ekranui
  • Šriftų dydžiai ir mygtukai, neoptimizuoti prisilietimui
  • Lėtesnis 4G ryšys, palyginti su stacionariu internetu
  • Mažesnė procesoriaus galia — JS optimizavimas dar svarbiau

Core Web Vitals ir SEO reitingai — koks realus poveikis?

Google oficialiai patvirtino, kad CWV yra reitingavimo signalas, tačiau kiek stiprus? Remiantis industrinių tyrimų duomenimis (Searchmetrics, Semrush, Ahrefs studijomis), CWV tiesioginis poveikis reitingams yra vidutinis — apie 1–5% koreliacija su pozicijomis.

Tačiau netiesioginis poveikis gali būti žymiai didesnis:

  • Atmetimo rodiklis — lėta svetainė = daugiau žmonių grįžta atgal į paiešką, o tai Google interpretuoja kaip prastos kokybės signalą
  • Laiko svetainėje rodiklis — stabili, greita svetainė = ilgesnė sesija
  • Konversijų rodiklis — studijos rodo, kad 1 sekundės LCP pagerėjimas gali padidinti konversiją iki 7%

Optimali SEO optimizacija 2026 m. neatsiejama nuo CWV — jie yra bazinis techninis reikalavimas, be kurio kiti SEO veiksmai duoda mažesnį efektą.

Labiausiai paplitusios CWV problemos Lietuvos svetainėse

Remdamiesi praktikos patirtimi ir svetainių kūrimo projektais, dažniausiai randame šias problemas:

1. Neoptimizuoti hero paveikslėliai

Lietuvos verslo svetainės dažnai naudoja 3–5 MB JPEG hero paveikslėlius — tai automatiškai reiškia LCP virš 4 sekundžių mobiliuosiuose. Sprendimas: kompresuoti iki WebP, iki 200–400 KB, naudojant Squoosh.app arba Sharp biblioteką.

2. Google Fonts be optimizavimo

Standartinis Google Fonts embed kodas — viena iš dažniausių CLS ir LCP priežasčių. Geriausia praktika: atsisiųskite šriftus ir talpinkite savo serveryje (self-hosting), pridėkite font-display: swap.

3. WordPress su per daug įskiepių

Kiekvienas WordPress įskiepis gali pridėti papildomų JS ir CSS failų. Svetainės su 40–60 įskiepių dažnai turi 2–5 MB JS bundle — tai tiesiai veikia INP. Audituokite įskiepius su Query Monitor ir šalinkite nenaudojamus.

4. Trečiųjų šalių skriptai

Google Tag Manager su daugybe žymų, Facebook Pixel, Hotjar, tiesioginių pokalbių widgetai — visi jie gali pridėti 200–500 ms prie INP. Naudokite GTM su Partytown biblioteka arba įkelkite skriptus tik po puslapio įkėlimo su window.addEventListener('load', fn).

5. Nereguliuojamas šriftų dydis mobiliesiems

Dideli H1–H2 antraštės šriftai kompiuteryje, neadaptuoti mobiliesiems, kartais sukelia netikėtus CLS variantus mažuose ekranuose — ypač jei šriftas įkeliamas vėliau nei HTML struktūra.

Dažnai užduodami klausimai

Core Web Vitals — tai Google nustatyti trys pagrindiniai svetainės naudotojų patirties rodikliai: LCP (Largest Contentful Paint) matuoja įkėlimo greitį, INP (Interaction to Next Paint) matuoja interaktyvumą, o CLS (Cumulative Layout Shift) matuoja vizualinį stabilumą. Nuo 2021 m. jie yra oficialus Google reitingavimo veiksnys, o nuo 2024 m. INP pakeitė senąjį FID rodiklį.
Geri rezultatai: LCP — iki 2,5 sekundės, INP — iki 200 milisekundžių, CLS — iki 0,1. Rezultatai 2,5–4,0 s (LCP), 200–500 ms (INP) ir 0,1–0,25 (CLS) laikomi vidutiniais — reikia tobulinti. Viršijant šias ribas rodoma raudona žyma PageSpeed Insights ir Search Console, o tai signalizuoja reikalingą skubų optimizavimą.
Pagrindiniai įrankiai: Google PageSpeed Insights (pagespeed.web.dev) — greičiausias būdas patikrinti, pateikia tiek simuliuotus, tiek realių vartotojų duomenis; Google Search Console → Core Web Vitals ataskaita — rodo realių vartotojų duomenis per 28 dienų laikotarpį ir grupuoja probleminius URL; Lighthouse Chrome DevTools — detaliausia analizė su konkrečiomis rekomendacijomis.
Taip, tačiau tiesioginis poveikis yra vienas iš daugelio veiksnių — ne dominuojantis. Google patvirtino CWV kaip reitingavimo signalą nuo 2021 m. Praktikoje turinio kokybė ir paieškos intencijos atitikimas išlieka svarbiausi, tačiau vienodo turinio atveju gerų CWV turinčios svetainės gali aplenkti blogesnius konkurentus. Netiesioginis poveikis — per geresnę vartotojų patirtį ir mažesnį atmetimo rodiklį — gali būti didesnis.
LCP (Largest Contentful Paint) matuoja, per kiek laiko įkeliamas didžiausias matomas elemento turinys — dažniausiai hero paveikslėlis ar pagrindinė antraštė. INP (Interaction to Next Paint) matuoja, kaip greitai puslapis reaguoja į vartotojo veiksmus — mygtuko paspaudimus, formos pildymą. CLS (Cumulative Layout Shift) matuoja vizualinį stabilumą — kiek elementai neplanuotai juda ekrane įkėlimo metu. Kiekvienas matuoja skirtingą patirties dimensiją.
Priklauso nuo problemų sudėtingumo. Paprastos korekcijos — paveikslėlių konvertavimas į WebP, font-display: swap pridėjimas, paveikslėlių dimensijų nurodymas — gali duoti laboratorinių duomenų pagerėjimą per 1–2 savaites. Sudėtingesni darbai — JavaScript refaktorizavimas, serverio infrastruktūros keitimai — gali užtrukti 1–3 mėnesius. Lauko duomenys (Search Console) atsinaujina po 28 dienų, kai Google surenka naujus CrUX duomenis.