Svetainės greitis yra vienas nedaugelio veiksnių, kuris vienu metu veikia ir jūsų Google pozicijas, ir vartotojų patirtį, ir konversijų rodiklius. Lėta svetainė tiesiogine prasme kainuoja pinigus. Šiame straipsnyje rasite 15 konkrečių ir įgyvendinamų metodų, kuriuos galite taikyti jau šiandien — nuo paprasčiausių paveikslėlių optimizavimo iki serverio lygio sprendimų. Jei domina išsamesnė techninio SEO pusė, čia aptariame platesnį greičio gerinimo vaizdą.

Kodėl svetainės greitis svarbus SEO

Google oficialiai patvirtino, kad puslapio greitis yra reitingavimo signalas nuo 2010 m. kompiuterių paieškos rezultatams ir nuo 2018 m. — mobiliosioms. Tačiau greičio svarba neapsiriboja vien pozicijomis.

Google algoritmas ir greitis

2021 m. Google įdiegė Page Experience atnaujinimą, kuriame Core Web Vitals tapo oficialiais reitingavimo signalais. Tai reiškia, kad lėtas puslapis gali prarasti pozicijas net turėdamas puikų turinį. Daugiau apie specifinius metrikas rasite mūsų Core Web Vitals gerinimo vadovą.

Vartotojų elgsena

Duomenys kalba patys už save:

  • Kiekviena papildoma sekundė mobiliojo įkėlimo laikotarpio padidina atsisakymo rodiklį 32% (Google duomenys)
  • 53% mobiliųjų vartotojų palieka puslapį, jei jis neįkraunamas per 3 sekundes
  • Vidutinis pirkėjas tikisi, kad e. parduotuvė įsikraus per 2 sekundes ar greičiau
  • Amazon apskaičiavo, kad 100 ms lėtesnis puslapio įkėlimas sumažina pardavimus 1%

Konversijų ryšys su greičiu

Walmart pastebėjo, kad kiekviena 1 sekundės pagerinimas padidino konversijas 2%. Mobiliojo prekybos tyrimai rodo, kad svetainės, veikiančios per 1 sekundę, konvertuoja 3 kartus geriau nei veikiančios per 5 sekundes. Greičio optimizavimas nėra tik techninis reikalas — tai tiesiogiai veikianti verslo metrika.

Kaip išmatuoti svetainės greitį

Prieš optimizuodami turite žinoti, kur esate. Trys pagrindiniai įrankiai:

Google PageSpeed Insights

Pasiekiamas adresu pagespeed.web.dev — nemokamas ir oficialus Google įrankis. Ypač vertingas dėl to, kad naudoja realius vartotojų duomenis iš Chrome User Experience Report (CrUX), ne tik laboratorinius matavimus. Pateikia atskirą stalinio ir mobiliojo vertinimą bei konkrečias optimizavimo rekomendacijas.

GTmetrix

Siūlo detalesnę analizę su vandens krentančiu grafikas (waterfall chart), kuris parodo, kuris resursas konkrečiai lėtina puslapį ir kiek laiko užtrunka kiekvieno resurso įkėlimas. Galima pasirinkti serverio lokaciją — rekomenduojame testuoti iš Europos serverio Lietuvos svetainėms.

Google Lighthouse

Integruotas tiesiai į Chrome naršyklę (F12 → Lighthouse skirtukas). Tinka greitos patikros dirbant su svetaine — rezultatai momentiniai, nereikia siųsti URL į išorinį įrankį. Matuoja tik laboratorinę aplinką, todėl rezultatai gali skirtis nuo PageSpeed Insights lauko duomenų.

Svarbi pastaba: visada testuokite ir staliniams, ir mobiliesiems įrenginiams atskirai. Dažnai mobilioji versija veikia ženkliai lėčiau, o būtent ji lemia didžiąją dalį srauto.

15 metodų svetainės greičiui pagerinti

1. Paveikslėlių optimizavimas

Neoptimizuoti paveikslėliai yra dažniausia lėtos svetainės priežastis. Kompleksinis sprendimas:

  • WebP ir AVIF formatai — WebP yra 25–35% mažesnis nei JPEG išlaikant tą pačią kokybę. AVIF dar efektyvesnis, tačiau palaikomas ne visų naršyklių. Naudokite <picture> elementą su fallback į JPEG.
  • Tinkamas dydis — niekada nekelkite 3000px paveikslėlio, jei jis rodomas 800px plačiame konteineryje. Keiskite dydį prieš įkeldami.
  • Lazy loading — paveikslėliams žemiau ekrano lango pridėkite loading="lazy" atributą. Naršyklė įkels juos tik kai vartotojas priartės.
  • srcset atributas — pateikite skirtingų dydžių paveikslėlius skirtingiems ekranams: srcset="img-400.webp 400w, img-800.webp 800w".

2. Serverio atsakymo laikas (TTFB)

TTFB (Time to First Byte) — laikas, per kurį serveris pradeda siųsti duomenis. Turėtų būti mažiau nei 200 ms. Jei didesnis — problema hosting pasirinkime.

Bendras (shared) hosting, kur viename serveryje tūkstančiai svetainių, dažnai duoda TTFB 500–1500 ms. VPS ar dedikuotas serveris, tinkamas hosting teikėjas Lietuvoje (pvz., serveriai.lt, interneto vizija su europiniais duomenų centrais) gali drastiškai sumažinti TTFB. Tai ir svetainių kūrimo etape svarbu tinkamai pasirinkti hosting platformą.

3. Browser caching nustatymas

Caching nurodo naršyklei saugoti statinius failus (CSS, JS, paveikslėlius) vartotojo įrenginyje tam tikrą laikotarpį. Tada pakartotinis apsilankymas įkraunamas daug greičiau, nes failai neatsiunčiami iš naujo.

Apache serveriui .htaccess faile:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png  "access plus 1 year"
  ExpiresByType text/css   "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

4. Gzip ir Brotli kompresija

Kompresija sumažina perduodamų failų dydį serveryje prieš siunčiant juos naršyklei. Gzip sumažina tekstinius failus (HTML, CSS, JS) 60–80%. Brotli (naujesnė technologija) yra dar 20–26% efektyvesnė nei Gzip.

Patikrinkite ar kompresija veikia: GTmetrix → Waterfall → bet kuris tekstinis failas → Headers → Content-Encoding: gzip/br. Jei nėra — kreipkitės į hosting teikėją arba pridėkite .htaccess direktyvas.

5. CSS ir JavaScript minifikavimas bei agregavimas

Minifikavimas pašalina iš kodo tarpus, komentarus ir sutrumpina kintamųjų pavadinimus — failai tampa 20–40% mažesni. Agregavimas sujungia kelis failus į vieną, sumažindamas HTTP užklausų skaičių.

WordPress: WP Rocket, LiteSpeed Cache arba Autoptimize priedai atlieka tai automatiškai. Rankiniams projektams — Webpack, Vite ar Gulp.

6. Kritinio CSS inline įkėlimas

Kritiniu CSS vadinama ta stiliaus lapų dalis, kuri reikalinga virš ekrano ribos (above-the-fold) esančiam turiniui. Jei CSS failas įkeliamas išoriškai, naršyklė blokuoja puslapio rodymą kol jis visiškai įsikrauna.

Sprendimas: išskirkite kritinį CSS ir įdėkite jį tiesiai į <head> <style> žymoje. Likusį CSS failą įkelkite asinchroniškai: <link rel="preload" href="style.css" as="style" onload="this.rel='stylesheet'">.

7. Šriftų optimizavimas

Išoriniai šriftai (Google Fonts ir kt.) gali sulėtinti puslapio rodymą, nes naršyklė laukia šrifto įkėlimo prieš rodydama tekstą.

  • font-display: swap — CSS direktyva, kuri nurodo naršyklei iš karto rodyti tekstą sistemos šriftu, kol įsikraus pagrindinis šriftas.
  • <link rel="preload"> — iš anksto įkelkite svarbius šriftų failus: <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
  • Apsvarstykite patalpinti šriftus savo serveryje (ne naudoti Google Fonts CDN) — tai pašalina papildomą DNS nustatymą.

8. CDN naudojimas

CDN (Content Delivery Network) — pasaulinė serverių tinklas, kuris saugo jūsų svetainės kopiją arčiausiai vartotojo esančiame serveryje. Vietoje to, kad vartotojas Vilniuje jungtųsi į serverį Londone, jis jungiasi į CDN serverį Varšuvoje ar Frankfurte.

Kada verta? CDN ypač naudingas, jei jūsų auditorija yra geografiškai išsisklaidžiusi arba svetainė turi daug statinių resursų (paveikslėliai, vaizdo įrašai). Cloudflare siūlo nemokamą CDN planą, kuris tinka daugumai Lietuvos svetainių.

9. HTTP/2 ir HTTP/3 protokolai

HTTP/2 leidžia siųsti kelis failus vienu metu per vieną jungtį (multiplexing), vietoje senosios HTTP/1.1, kur kiekvienas failas laukė eilėje. HTTP/3 (pagrįstas QUIC protokolu) dar greitesnis, ypač nestabiliuose tinkluose.

Patikrinkite: naršyklės kūrėjų įrankyje (F12 → Network → Protocol stulpelis) turėtumėte matyti „h2" arba „h3". Jei rodoma „http/1.1" — kreipkitės į hosting teikėją dėl HTTP/2 įjungimo.

10. Trečiųjų šalių skriptų valdymas

Kiekvienas išorinis skriptas (Google Analytics, Facebook Pixel, chat widgetai, reklamos tinklai) prideda papildomą DNS nustatymą, TCP jungtį ir failo atsisiuntimą. 5–10 trečiųjų šalių skriptų gali pridėti 1–3 sekundes prie įkėlimo laiko.

  • Auditas: GTmetrix ataskaitoje peržiūrėkite visus trečiųjų šalių skriptus ir jų poveikį
  • Atidėtas įkėlimas: nepagrindiniai skriptai su defer arba async atributais
  • Fasado metodas: vietoje tiesioginės „YouTube" ar chat vaizdo versijos — statinis paveikslėlis, kuris pakeičiamas tikru iframe tik paspaudus
  • Google Tag Manager: konsoliduokite visus stebėjimo skriptus per vieną konteinerį

11. Duomenų bazės optimizavimas (WordPress)

WordPress duomenų bazė ilgainiui kaupia šiukšles: peržiūrų istorija, spam komentarai, nepriskirti medijos failai, pasenusios priedų lentelės. Tai lėtina duomenų bazės užklausas.

  • Naudokite WP-Optimize arba Advanced Database Cleaner priedus reguliariam valymui
  • Ribokite saugomų peržiūrų skaičių: define('WP_POST_REVISIONS', 5); wp-config.php faile
  • Įdiekite objektų caching (Redis arba Memcached) — duomenų bazės užklausų rezultatai saugomi atmintyje

12. Resource hints: preload, preconnect, prefetch

Resource hints leidžia nurodyti naršyklei iš anksto atlikti tam tikrus veiksmus:

  • <link rel="preconnect" href="https://fonts.googleapis.com"> — iš anksto užmezga jungtį su išoriniu domenu
  • <link rel="preload" href="/css/style.css?v=20260427" as="style"> — iš anksto atsiunčia svarbų resursą
  • <link rel="prefetch" href="/kitas-puslapis"> — iš anksto atsiunčia kitą puslapį, kurį vartotojas greičiausiai aplankys
  • <link rel="dns-prefetch" href="//fonts.googleapis.com"> — iš anksto atlieka DNS nustatymą

13. Pirmojo ekrano turinio prioritizavimas

Turinio, esančio pirmajame ekrano vaizde (above-the-fold), įkėlimas turi būti kuo greitesnis — tai tiesiogiai veikia LCP metriką. Praktiniai žingsniai:

  • Hero paveikslėliui nenaudokite lazy loading — jis turi įsikrauti kuo greičiau
  • Hero paveikslėlį nurodykite su fetchpriority="high" atributu
  • Kritinį CSS pirmojo ekrano elementams įdėkite inline į <head>
  • Venkite didelių JavaScript failų, kurie blokuoja puslapio rodymą

14. Lazy loading iframe elementams

Panašiai kaip paveikslėliai, iframe elementai (įterpti YouTube vaizdo įrašai, žemėlapiai, socialinių tinklų įdėtiniai) gali ženkliai lėtinti puslapį, jei įkeliami iš karto. Sprendimas:

  • HTML5 loading="lazy" atributas veikia ir su iframe: <iframe loading="lazy" src="...">
  • YouTube fasado metodas: vietoje tiesioginės vaizdo versijos rodykite tik miniatiūrą (paveikslėlį iš YouTube), tikrą iframe įkelkite tik paspaudus
  • Google Maps pakeiskite statiniu žemėlapio paveikslėliu su nuoroda į Google Maps

15. Serverio lokacija Lietuvos vartotojams

Fizinis atstumas tarp vartotojo ir serverio tiesiogiai veikia TTFB. Dėl šviesos greičio apribojimų, serveris Frankfurte duos mažesnį TTFB Lietuvos vartotojams nei serveris Singapūre.

Rekomenduojama serverio lokacija Lietuvos auditorijai: Vilnius, Ryga, Varšuva arba Frankfurtas. Vengkite serverių JAV ar Azijoje, jei dauguma jūsų vartotojų yra Baltijos šalyse. SEO audito metu visada tikriname serverio lokaciją ir TTFB rodiklius.

Greičio optimizavimas pagal platformą

WordPress

WordPress yra lankstiausia platforma greičio optimizavimui, nes egzistuoja daugybė specializuotų priedų:

  • WP Rocket — geriausias mokamas sprendimas (49–249 USD/m.), apima viską: caching, minifikavimą, lazy loading, CDN integraciją
  • LiteSpeed Cache — nemokamas, bet reikia LiteSpeed serverio; labai efektyvus
  • Autoptimize + W3 Total Cache — nemokama kombinacija, reikalauja daugiau rankinio konfigūravimo
  • Vengkite per daug priedų — kiekvienas prideda papildomą apkrovą duomenų bazei ir PHP vykdymui

Individualios svetainės (custom)

Individualiai sukurtoms svetainėms greičio optimizavimas priklauso nuo kūrėjų kompetencijos. Pagrindiniai principai: Vite/Webpack resursų surinkimas su code splitting, statinių failų CDN, serverio pusės renderinimas (SSR) arba statinis generavimas (SSG) kur įmanoma.

Shopify

Shopify riboja serverio lygio konfigūravimą, tačiau galite optimizuoti: tema (pasirinkite greičiausias temas — Dawn, Impulse), paveikslėlių optimizavimą, trečiųjų šalių programėlių skaičių (kiekviena Shopify programėlė dažnai prideda savo skriptus) ir CDN naudojimą medijai.

Mobiliosios svetainės greitis

Google naudoja mobile-first indexing — tai reiškia, kad jūsų svetainės mobilioji versija yra pagrindinė reitingavimui. Todėl mobiliojo greičio optimizavimas turi gauti ne mažiau dėmesio nei stalinio.

Pagrindiniai mobiliosios versijos greičio iššūkiai:

  • Lėtesnis tinklas — mobiliojo ryšio (4G/5G) latentumas didesnis nei stacionaraus; optimizuokite HTTP užklausų skaičių
  • Silpnesnis procesorius — didelės JavaScript bibliotekos mobiliajame gali trukti 3–5x ilgiau nei staliniame; mažinkite JS dydį
  • Paveikslėlių dydžiai — mobiliajam ekranui nereikia tų pačių didelių paveikslėlių; naudokite srcset
  • Šriftų įkėlimas — papildomi šriftų variantai (bold, italic, skirtingi storiai) sudaro didelę dalį šriftų failo svorio; apribokite iki būtiniausių

Tikslinis mobiliosios versijos PageSpeed Insights balas: 75+. 90+ yra puiku. Žemiau 50 — rimtas techninis SEO trūkumas, kurį rekomenduojame nedelsiant šalinti.

Dažnai užduodami klausimai

Rekomenduojamas tikslas — svetainė turi įsikrauti per mažiau nei 2–3 sekundes staliniame kompiuteryje, o mobiliajame — per 3–4 sekundes. Google duomenimis, kiekviena papildoma sekundė mobilaus įkėlimo laiko padidina atsisakymo rodiklį 32%. Puikiems PageSpeed Insights rezultatams siekite LCP (Largest Contentful Paint) mažesnio nei 2,5 sek.
Pagrindiniai įrankiai: Google PageSpeed Insights (pagespeed.web.dev) — nemokamas, rodo realius lauko duomenis; GTmetrix — detalesnė analizė su vandens krentančiu grafiku; Google Lighthouse — integruotas naršyklėje (F12 → Lighthouse). Rekomenduojame tikrinti visais trim, nes rezultatai gali skirtis.
Dažniausios priežastys: neoptimizuoti paveikslėliai (pernelyg didelė raiška, JPEG vietoje WebP), per daug trečiųjų šalių skriptų (chat widgetai, reklamos, socialinių tinklų mygtukai), blogas hosting (bendras serveris su dideliu apkrovos lygiu), nenaudojamas caching ir per didelis nesuglaudintas JavaScript.
Taip. Google oficialiai patvirtino, kad puslapio greitis yra reitingavimo signalas tiek staliniams, tiek mobiliesiems rezultatams. 2021 m. įdiegtus Core Web Vitals (LCP, INP, CLS) Google naudoja kaip Page Experience signalus. Lėta svetainė ne tik mažina pozicijas, bet ir blogina konversijų rodiklius.
Priklauso nuo svetainės sudėtingumo ir problemos šaltinio. Pagrindinė optimizacija (paveikslėliai, caching, minifikavimas) WordPress svetainei kainuoja nuo 150–400 EUR kaip vienkarinis darbas. Sudėtingesnė serverio konfigūracija, CDN diegimas ar individuali priekinės dalies optimizacija gali kainuoti 500–1500 EUR. Greičio optimizavimas paprastai greitai atsipirka per pagerintas konversijas.
PageSpeed Insights naudoja ir realius vartotojų duomenis (Chrome User Experience Report), ir laboratorinius matavimus. GTmetrix matuoja tik laboratorinėje aplinkoje, bet pateikia detalesnę vandens krentančio grafiko analizę, kuri padeda nustatyti konkrečius lėtinančius resursus. Abiejų įrankių rezultatai gali skirtis dėl skirtingų serverio lokacijų ir metodikos.