Tavo svetainė gali turėti puikų turinį, tobulą dizainą ir geriausius backlinks pasaulyje — bet jei ji kraunasi lėtai, Google ją nubaus. Nuo 2021 metų svetainės greitis yra oficialus reitingavimo faktorius, o Core Web Vitals tapo esminiu SEO elementu. Ir 2026 metais tai dar svarbiau nei bet kada anksčiau.
Šiame straipsnyje paaiškinu, kas yra Core Web Vitals, kaip juos optimizuoti ir kodėl greita svetainė ne tik padeda SEO, bet ir tiesiogiai didina pardavimus.
Kas yra Core Web Vitals
Core Web Vitals — tai trys Google metrikai, kurie matuoja realią vartotojo patirtį tavo svetainėje. Ne teorinį greitį, o tai, ką iš tikrųjų jaučia lankytojas.
Trys Core Web Vitals metrikai
LCP (Largest Contentful Paint): Kiek laiko užtrunka, kol užsikrauna pagrindinis puslapio elementas (dažniausiai hero nuotrauka ar didžiausia teksto sekcija). Tikslas: iki 2,5 sekundžių.
INP (Interaction to Next Paint): Kiek laiko praeina nuo vartotojo veiksmo (paspaudimo, klavišo) iki vizualaus atsako. Pakeitė senąjį FID metriką 2024 m. Tikslas: iki 200 milisekundžių.
CLS (Cumulative Layout Shift): Kiek puslapio elementai „šokinėja" krautis — kai mygtukas pasislenka, kai baneris atsiranda ir nustumia turinį. Tikslas: iki 0,1.
Kodėl greitis veikia SEO pozicijas
Google tikslas — duoti vartotojui geriausią patirtį. Lėna svetainė = bloga patirtis. Tai paprasta logika, bet skaičiai dar įdomesni:
- 53% mobiliųjų vartotojų palieka svetainę, jei ji kraunasi ilgiau nei 3 sekundes (Google duomenys)
- Kiekviena papildoma sekundė mažina konversiją 7%
- Svetainės su gerais Core Web Vitals gauna 24% daugiau organinio trafiko vidutiniškai
- Amazon apskaičiavo, kad 100ms vėlavimas kainuoja 1% pardavimų — tai milijardai dolerių per metus
- Google oficialiai patvirtino, kad Core Web Vitals yra reitingavimo faktorius nuo 2021 m.
Bet greitis veikia ne tik per Google algoritmą. Greitesnė svetainė = mažesnis bounce rate = ilgesnis laikas svetainėje = daugiau puslapių per sesiją. Visi šie signalai netiesiogiai gerina SEO.
Kaip patikrinti savo svetainės greitį
1. Google PageSpeed Insights (nemokamas)
Pagrindinė priemonė. Eik į pagespeed.web.dev, įvesk savo svetainės URL ir gauk detalų raportą. Svarbu: PageSpeed Insights naudoja ir lauko duomenis (realių vartotojų), ir laboratoriniais duomenis (simuliuotus). Lauko duomenys yra svarbesni SEO kontekste.
2. Google Lighthouse (Chrome DevTools)
Integruotas Chrome naršyklėje. Dešiniu pelės klavišu > Inspect > Lighthouse skirtukas. Duoda detalų auditą: greitis, prieinamumas, SEO, geriausios praktikos. Puiku kūrimo procese.
3. GTmetrix
Detalesnė analizė su „waterfall" diagrama — matai, kuris failas kiek laiko kraunasi. Nemokamas planas leidžia testuoti iš vieno serverio. Mokamas (nuo 15 USD/mėn.) — iš skirtingų lokacijų.
4. WebPageTest
Pažangiausias nemokamas įrankis. Gali testuoti iš skirtingų šalių, skirtingų ryšio greičių, skirtingų įrenginių. Duoda filmstrip — matai, kaip svetainė kraunasi sekundė po sekundės.
LCP optimizavimas — pagrindinis greičio metrikas
LCP (Largest Contentful Paint) dažniausiai yra didžiausia problema. Tai laikas, per kurį užsikrauna pagrindinis puslapio elementas — dažniausiai hero nuotrauka arba didžiausias teksto blokas.
8 būdai pagerinti LCP
- Optimizuok nuotraukas: Konvertuok į WebP formatą (30-50% mažesnės nei JPEG). Naudok responsive images su srcset. Nuotraukos dydis turėtų atitikti rodymą — nekelk 4000px nuotraukos, jei rodosi 800px
- Preload hero nuotrauką: Pridėk <link rel="preload" as="image" href="hero.webp"> į <head> — naršyklė pradės krauti nuotrauką anksčiau
- Naudok CDN: Cloudflare (nemokamas) arba Vercel Edge Network. Turinys pateikiamas iš artimiausio serverio — Lietuvoje tai reikšmingai sutrumpina TTFB
- Minifikuok CSS ir JS: Pašalink nereikalingus tarpus, komentarus, nenaudojamą kodą. Naudok tree shaking JavaScript'e
- Venk render-blocking resursų: Perkelk ne kritinį CSS ir JS į async/defer. Kritinį CSS (above the fold) inline'ink į HTML
- Optimizuok serverio atsakymą (TTFB): Time to First Byte turi būti žemiau 200ms. Jei ne — reikia geresnio hostingo arba caching strategijos
- Naudok font-display: swap: Šriftai neturi blokuoti renderinimo. Pridėk font-display: swap prie @font-face
- Lazy loading (bet ne hero): Nuotraukos žemiau pirmo ekrano turėtų krautis tik kai vartotojas nuslenkia. BET hero nuotrauka — niekada lazy loading
INP optimizavimas — interaktyvumo greitis
INP (Interaction to Next Paint) pakeitė FID (First Input Delay) kaip oficialų Core Web Vital 2024 m. kovą. INP matuoja ne tik pirmąjį, bet VISUS vartotojo veiksmus — kiekvieną paspaudimą, kiekvieną klavišo paspaudimą.
Dažniausios INP problemos ir sprendimai:
- Sunkūs JavaScript paketai: Jei tavo bundle.js yra 500KB+ — vartotojas jaučia vėlavimą. Sprendimas: code splitting, dynamic imports, tree shaking
- Long tasks: JavaScript operacijos, kurios trunka ilgiau nei 50ms, blokuoja main thread. Sprendimas: skaidyk ilgas operacijas į mažesnes, naudok Web Workers
- Per daug DOM elementų: Jei tavo puslapyje 3 000+ DOM elementų — naršyklei sunku greitai atnaujinti ekraną. Sprendimas: virtualizacija (react-window), turinio optimizavimas
- Third-party skriptai: Google Analytics, Facebook Pixel, chat widget'ai — kiekvienas prideda latency. Sprendimas: defer, asinchroninis krovimas, Partytown
CLS optimizavimas — vizualus stabilumas
CLS (Cumulative Layout Shift) matuoja, kiek puslapio elementai šokinėja. Tai labiausiai erzinanti vartotojo patirtis — kai mygtukas, kurį nori paspausti, staiga pasislenka ir paspaudai ne tą.
Dažniausios CLS problemos
- Nuotraukos be dydžio: Jei nenurodytas width ir height atributas — naršyklė nežino, kiek vietos palikti, ir turinys „šoka" kai nuotrauka užsikrauna. Sprendimas: VISADA nurodyti width ir height arba naudoti aspect-ratio CSS
- Dinaminis turinys: Reklaminiai baneriai, cookie pranešimai, popup'ai, kurie atsiranda ir nustumia turinį. Sprendimas: rezervuoti vietą iš anksto arba naudoti overlay vietoj push
- Web šriftai: Kai custom šriftas užsikrauna, jis gali turėti kitokį dydį nei fallback šriftas — tekstas „šoka". Sprendimas: font-display: swap + size-adjust
- Inject'inamas turinys: JavaScript, kuris prideda elementus virš jau matomo turinio. Sprendimas: pridėk elementus po matomu turiniu arba naudok CSS transform animacijas
WordPress vs Next.js — greičio palyginimas
Tai klausimas, kurį man dažnai užduoda klientai. Ir atsakymas labai priklauso nuo to, kaip svetainė padaryta.
| Metrikas | WordPress (vidutinis) | WordPress (optimizuotas) | Next.js (SSG/SSR) |
|---|---|---|---|
| LCP | 4,5 – 8,0 sek. | 1,8 – 3,0 sek. | 0,8 – 2,0 sek. |
| INP | 300 – 800 ms | 100 – 250 ms | 50 – 150 ms |
| CLS | 0,15 – 0,40 | 0,05 – 0,10 | 0,01 – 0,05 |
| PageSpeed score | 30 – 55 | 70 – 85 | 90 – 100 |
| Puslapio dydis | 3 – 8 MB | 1 – 3 MB | 200KB – 1 MB |
| HTTP užklausos | 80 – 150+ | 30 – 60 | 10 – 30 |
Kodėl WordPress dažnai lėtas? Dažniausiai ne dėl pačio WordPress, o dėl to, kaip jis naudojamas: 20-30 pluginų (kiekvienas prideda CSS ir JS), neoptimizuotos nuotraukos, pigus shared hostingas, sunkios temos (Divi, Elementor generuoja daug nereikalingo kodo).
Ar galima WordPress padaryti greitą? Taip, bet reikia darbo: pašalinti nereikalingus pluginus, naudoti WP Rocket arba W3 Total Cache, optimizuoti nuotraukas (ShortPixel, Imagify), naudoti gerą hostingą (Kinsta, Cloudways — nuo 30 EUR/mėn.), minifikuoti CSS/JS.
Kodėl Next.js greitas „iš dėžutės"? Static Site Generation (SSG) — puslapiai sugeneruojami build metu kaip statinis HTML. Nėra duomenų bazės užklausų kiekvieno vizito metu. Automatic code splitting — vartotojas krauna tik tą JavaScript, kurio reikia šiam puslapiui. Image optimization — built-in next/image komponentas automatiškai optimizuoja nuotraukas.
Daugiau apie WordPress ir custom svetainių palyginimą skaitykite atskirame straipsnyje.
Praktinis optimizavimo planas
5 žingsnių greičio optimizavimo planas
- Auditas (1 diena): Paleisk PageSpeed Insights ir GTmetrix. Užsirašyk LCP, INP, CLS reikšmes. Identifikuok didžiausias problemas
- Nuotraukos (1-2 dienos): Konvertuok visas nuotraukas į WebP. Pridėk width/height atributus. Įdiek lazy loading. Tai dažniausiai duoda 40-60% greičio pagerėjimo
- Caching ir CDN (kelios valandos): Įdiek Cloudflare (nemokamas). Sukonfigūruok naršyklės caching (Cache-Control headers). WordPress — WP Rocket
- CSS/JS optimizavimas (1-3 dienos): Pašalink nenaudojamą kodą (Chrome DevTools > Coverage). Minifikuok. Critical CSS inline. Defer non-critical JS
- Serveris (jei reikia): Jei TTFB > 400ms — svarstyk hostingo pakeitimą. Vercel, Cloudways, Kinsta — visi duoda <200ms TTFB Europoje
Nemokamų įrankių sąrašas
| Įrankis | Paskirtis | Kaina |
|---|---|---|
| PageSpeed Insights | Core Web Vitals testavimas | Nemokamas |
| Lighthouse | Detalus svetainės auditas | Nemokamas (Chrome) |
| GTmetrix | Waterfall analizė | Nemokamas (bazinis) |
| Cloudflare | CDN, DDoS apsauga, cache | Nemokamas planas |
| Squoosh | Nuotraukų optimizavimas | Nemokamas |
| PurgeCSS | Nenaudojamo CSS pašalinimas | Nemokamas (open source) |
| WebPageTest | Pažangus greičio testavimas | Nemokamas |
Greičio įtaka konversijai — skaičiai nekelia abejonių
Greitis veikia ne tik SEO — jis tiesiogiai veikia tavo pelną. Štai keletas statistikų, kurios turėtų motyvuoti optimizuoti svetainę:
- Walmart: kiekviena 1 sekundės pagerėjimas padidino konversiją 2%
- BBC: kiekviena papildoma sekundė prarado 10% lankytojų
- Pinterest: 40% greičio pagerinimas padidino registracijas 15%
- Vodafone: LCP pagerinimas 31% padidino pardavimus 8%
Lietuvos kontekste: jei tavo svetainė gauna 5 000 lankytojų per mėnesį ir konversiją padidintum nuo 2% iki 2,5% vien greičio optimizavimu — tai 25 papildomos konversijos per mėnesį. Jei vienos konversijos vertė 100 EUR — tai 2 500 EUR papildomų pajamų per mėnesį. Ir tai — vienkartinė investicija, kuri veikia kiekvieną mėnesį.
Daugiau apie SEO optimizavimo kainas ir naudą rašau atskirame straipsnyje.
Preguntas frecuentes (FAQ)
Nori, kad profesionaliai optimizuočiau tavo svetainės greitį? Užpildyk mūsų projekto konfiguratorių ir susisiekime per 24 valandas su konkrečiu planu.
\n¿Cuánto costará su proyecto?
\nEnvíe una descripción — presupuesto en 24h.
\n Obtener presupuesto \n