Mes daug rašome apie techninį SEO, svetainės greitį ir Core Web Vitals gerinimą. Tačiau klientai pagrįstai gali klausti: o jūsų pačių svetainė kaip? Šiame straipsnyje parodome tikrus seorun.lt PageSpeed Insights rezultatus ir tiksliai paaiškiname, kaip juos pasiekėme. Be marketingo — tik konkretūs techniniai sprendimai su realiomis reikšmėmis.
Mūsų PageSpeed rezultatai: tikri skaičiai
Prieš gilindamiesi į techninius sprendimus — štai ką rodo Google PageSpeed Insights seorun.lt svetainei šiandien:
Desktop rezultatai:
- Performance: 100
- Accessibility: 97
- Best Practices: 100
- SEO: 100
Core Web Vitals (desktop):
- FCP: 0,3 s · LCP: 0,3 s · TBT: 0 ms · CLS: 0 · Speed Index: 0,4 s
Mobile rezultatai:
- Performance: 100
- Accessibility: 97
- Best Practices: 100
- SEO: 100
Core Web Vitals (mobile):
- FCP: 0,9 s · LCP: 1,2 s · TBT: 0 ms · CLS: 0 · Speed Index: 0,9 s
Keletas pastebėjimų prieš einant toliau. Pirma — 97, o ne 100 accessibility bale. Tai sąmoningas dizaino sprendimas, ne techninė klaida — apie tai daugiau žemiau. Antra — mobilieji rezultatai vis tiek yra puikūs: LCP 1,2 s yra gerai po „geros" ribos (2,5 s), o TBT ir CLS — tobulūs. Trečia — šie rezultatai pasiekti be jokio specialaus „testinio" puslapio. Tai yra tikroji gyvoji svetainė su realia navigacija, cookie consent, Google Tag Manager ir visa kita.
Kodėl 97, o ne 100 accessibility?
Pirmiausia — svarbiausias klausimas, kurį greičiausiai užduosite. Lighthouse accessibility auditas mūsų svetainėje nurodo spalvų kontrastą, kuris neatitinka WCAG AA standarto tam tikruose elementuose. Tai mūsų brandos spalvų pasirinkimo rezultatas — kai kurios teksto ir fono spalvų kombinacijos yra šiek tiek per mažo kontrasto pagal Lighthouse skaičiavimą.
Mes žinome apie šią problemą. Ir mes ją sąmoningai paliekame, nes vizualinis identitetas mums svarbus, o realūs vartotojai šių elementų skaitymo problemų nepatirtų. Visi kiti accessibility aspektai — ARIA žymėjimai, klaviatūros navigacija, semantinė HTML struktūra, alternatyvūs tekstai paveikslėliams — yra tvarkoje. Jei accessibility 100 būtų griežtas mūsų kliento reikalavimas, mes tikrai žinotume, kaip tai pasiekti — tereikia pakeisti kelias spalvų kombinacijas.
Tai svarbu paminėti atvirai: 100/100 Performance ir SEO yra svarbiausi rodikliai šiame kontekste. Accessibility 97 vis tiek yra labai aukštas balas ir tikrai nekenkia reitingams.
1. Statinis HTML — greičio pagrindas
Didžiausias seorun.lt greičio pagrindas yra paprastas: mes nenaudojame CMS sistemos. Svetainė parašyta statiniu HTML, o PHP naudojamas tik šablonų komponentams — navigacijai ir footer'iui įtraukti per PHP include.
Ką tai reiškia praktiškai? Kai naršyklė prašo seorun.lt puslapio, serveris tiesiog grąžina jau paruoštą HTML failą. Nėra PHP apdorojimo, nėra duomenų bazės užklausų, nėra WordPress kešavimo įskiepių eilės. TTFB (Time to First Byte) yra minimalus — serveris reaguoja iš karto.
CMS sistemos turi daug privalumų — turinio valdymas, įskiepiai, komanda gali redaguoti be kodo žinių. Tačiau kiekvienas iš tų privalumų kainuoja serverio resursus ir papildomus milisekundes. Mūsų svetainei statinis HTML yra tinkamas pasirinkimas, ir tas pasirinkimas atsispindi rezultatuose.
2. GTM lazy loading — analytics be greičio aukų
Google Tag Manager yra beveik būtinas modernioms svetainėms — be jo negalima tinkamai fiksuoti konversijų, sekti vartotojų elgsenos ar valdyti rinkodaros žymų. Tačiau standartinis GTM diegimas — kodas HTML <head> — yra viena pagrindinių PageSpeed problemų.
Mūsų sprendimas: GTM įkeliamas tik po pirmosios vartotojų sąveikos — slinkties arba pelės paspaudimo. Konkrečiai tai atrodo taip:
- Puslapis įkeliamas be GTM
- Kai vartotojas pradeda slinkti arba spaudžia — suaktyvinamas GTM įkėlimas
- GTM įkeliamas asinchroniškai, neblokuodamas pagrindinio srauto
Rezultatas: LCP ir TBT matavimo metu GTM visiškai neegzistuoja naršyklei. Google PageSpeed Insights matuoja puslapio įkėlimą simuliuojant automatinį apsilankymą be sąveikos — todėl GTM tiesiog neįkeliamas matavimo metu. Tačiau realus vartotojas per pirmą sekundę tikrai paslinkia ar paspaudžia, tad GTM veikia ir visi įvykiai fiksuojami.
Svarbu: šis metodas veikia didžiąjai daliai svetainių. Jei jūsų svetainėje yra kritinių pirmo puslapio konversijų, kurias reikia fiksuoti net be sąveikos — reikia papildomai apgalvoti sprendimą.
3. Cookie consent optimizavimas — request chain problema išspręsta
Cookie consent sistema yra kitas klasikinis PageSpeed problemų šaltinis. Dauguma svetainių naudoja tokius įrankius kaip Cookiebot, OneTrust ar panašius, kurie įkeliami iš išorinių CDN. Tai sukuria ilgą request chain: DNS lookup → TCP jungtis → SSL handshake → failo atsisiuntimas — viskas prieš kad puslapis galėtų tinkamai veikti.
Mes naudojame atvirojo kodo orestbida/cookieconsent biblioteką su trimis pagrindiniais optimizavimais:
Lokalus talpinimas, ne CDN
Visi cookie consent failai — JavaScript ir CSS — yra mūsų pačių serveryje. Nėra papildomų DNS užklausų, nėra priklausomybės nuo trečiųjų šalių CDN greičio ar prieinamumo. Tai pašalina visą request chain problemą.
Vienas bundle failas
Originali biblioteka gali turėti kelis failus. Mes juos sujungėme į vieną cc-bundle.js — viena užklausa vietoje kelių. Tinkle tai reikšmingas skirtumas, ypač mobiliesiems su lėtesniu ryšiu.
Asinchroninis CSS įkėlimas
Cookie consent CSS įkeliamas su preload triuku, kuris leidžia jį įkelti neblokuojant renderinimo:
<link rel="preload" href="/css/cc-bundle.css" as="style"
onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/cc-bundle.css"></noscript>Inicializavimas po window load
Cookie consent JavaScript inicializuojamas tik tada, kai puslapis visiškai įkrautas — po window load įvykio. Tai reiškia, kad cookie consent nedalyvauja LCP matavime. Vartotojas mato cookie juostą po kelių milisekundžių po puslapio įkėlimo — praktiškai nepastebimai — tačiau pagrindiniai greičio rodikliai nuo to nenukenčia.
4. requestIdleCallback — animacijos be TBT
Animacijos ir IntersectionObserver (elementų atsiradimas slinkties metu) yra dažna TBT (Total Blocking Time) problema. Kodas, kuris nustato stebėjimo taškus ir prideda animacijų klases, vykdomas pagrindinėje naršyklės gijoje — ir jei jo per daug arba jis per lėtas, tai sukelia Long Tasks ir blokuoja vartotojo sąveiką.
Mūsų sprendimas: IntersectionObserver nustatymas vykdomas per requestIdleCallback:
requestIdleCallback(() => {
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
entry.target.classList.add('visible');
}
});
});
document.querySelectorAll('.animate').forEach(el => observer.observe(el));
});requestIdleCallback nurodo naršyklei: vykdyk šį kodą tik tada, kai naršyklė neturi svarbesnio darbo. Tai garantuoja, kad animacijų nustatymas niekada nesukels Long Task — jis visada vykdomas tarpais tarp kritinių operacijų. Rezultatas: TBT = 0 ms.
5. Preload ir WebP — kritiniai resursai pirma
Du klasikiniai, bet labai efektyvūs optimizavimai: preload žymos kritiniams resursams ir WebP paveikslėliai.
Preload kritiniams resursams
Pagrindinis CSS failas įkeliamas su preload žyma, kad naršyklė pradėtų jį atsisiųsti kuo anksčiau — dar prieš HTML analizės pabaigą:
<link rel="preload" href="/css/style.css?v=20260427" as="style">
<link rel="stylesheet" href="/css/style.css?v=20260427">Šis dvigubas derinys (pirma preload, tada stylesheet) leidžia naršyklei pradėti atsisiuntimą anksti, bet vis tiek taikyti stilius teisingai.
WebP paveikslėliai
Visi seorun.lt paveikslėliai yra WebP formatu. WebP vidutiniškai yra 25–35% mažesnis nei lygiavertis JPEG, o šiuolaikinės naršyklės jį palaiko universaliai. Tai tiesiogiai mažina LCP — mažesnis failas atsisiunčiamas greičiau.
Svarbus principas: LCP elementas (didžiausias matomas turinys) niekada neturi turėti loading="lazy" atributo. Lazy loading nurodo naršyklei atidėti paveikslėlio įkėlimą — tai tiesiogiai padidina LCP. Visiems kitiems paveikslėliams žemiau ekrano — lazy loading yra gera praktika ir mažina pradinį įkėlimo kiekį.
6. Consent Mode v2 — duomenų kokybė ir GDPR
Šis optimizavimas tiesiogiai neveikia PageSpeed balo, tačiau yra neatsiejama modernios SEO paslaugų dalies — todėl paminime jį.
Consent Mode v2 — tai Google sistema, kuri leidžia Analytics ir Ads skriptams veikti modeliavimo režimu, kai vartotojas atsisakė sutikimo. Tai svarbu dėl kelių priežasčių:
- GDPR atitiktis — nefiksuojami duomenys be sutikimo, bet išlieka agregavimas
- Konversijų duomenys — Google modeliuoja dalį prarastų konversijų, todėl kampanijų optimizavimas išlieka efektyvus
- Duomenų vientisumas — Analytics ataskaitos nėra iškraipytos dėl slapukų atsisakymo
Mūsų cookie consent sistema yra integruota su Consent Mode v2 — kai vartotojas priima arba atsisako, atitinkami signalai persiunčiami Google sistemoms teisingai.
Ką šie rezultatai reiškia praktikoje?
Grįžtant prie pagrindinių skaičių — kodėl jie svarbūs ne tik kaip trofėjus, bet ir praktiškai?
Desktop LCP 0,3 s ir Mobile LCP 1,2 s — tai ženkliai žemiau Google „gero" ribos (2,5 s). Realių vartotojų patirtis: puslapis atrodo iš karto, nėra jokio laukimo pojūčio nei kompiuteryje, nei telefone.
TBT 0 ms abiejuose įrenginiuose — tai reiškia, kad puslapio įkėlimo metu nėra jokių „Long Tasks", kurie blokuotų vartotojo sąveiką. Mygtukai, nuorodos, formos — viskas reaguoja iš karto.
CLS 0 abiejuose įrenginiuose — nė vienas elementas nesikeičia savo pozicija po puslapio įkėlimo. Vartotojas nesusiduria su situacija, kai tekstas „šokinėja" ar mygtukai pasislenka.
Šie rodikliai tiesiogiai veikia vartotojų patirtį — ir netiesiogiai — SEO audito metu randamas konkurencinis pranašumas. Kai du panašūs puslapiai rungiasi dėl pozicijos Google, puslapis su geresniais Core Web Vitals gali turėti pranašumą.
Ką galite pritaikyti savo svetainei
Ne kiekviena svetainė gali arba turi būti pastatyta ant statinio HTML. Tačiau dauguma šiame straipsnyje aprašytų metodų veikia ir su WordPress, ir su kitomis CMS sistemomis:
- GTM lazy loading — įgyvendinamas su bet kuria svetaine. Reikia pakeisti GTM diegimo kodą, ne pačią svetainę.
- Cookie consent optimizavimas — jei šiuo metu naudojate mokamą SaaS cookie consent sprendimą, apsvarstykite lokalų alternatyvą su tinkamu įkėlimo eilės valdymu.
- requestIdleCallback animacijoms — bet kuris JavaScript kūrėjas gali tai įgyvendinti.
- WebP paveikslėliai — WordPress Imagify, ShortPixel ar panašūs įskiepiai automatiškai konvertuoja į WebP. Tai vienas greičiausių ir pigiausių greičio pagerinimų.
- Preload žymos — paprastas HTML pakeitimas galvutėje, veikia su bet kuria sistema.
Jei norite žinoti, kur jūsų svetainė šiuo metu stovi ir kokie optimizavimai duotų didžiausią greitį — tai yra standartinė mūsų techninio SEO audito dalis. Audito metu ne tik patikriname PageSpeed rodiklius, bet ir nustatome tikslias priežastis bei prioritetuojame sprendimus pagal poveikio ir darbo santykį.