Kas iš tikrųjų slepiasi po „Core Web Vitals” pavadinimu
Jei dirbate su svetainėmis bent kelerius metus, tikriausiai esate girdėję apie Core Web Vitals – Google metrikas, kurios matuoja realią vartotojo patirtį puslapyje. Bet čia prasideda įdomiausia dalis: dauguma žmonių žino, kad jos egzistuoja, tačiau nedaugelis supranta, ką jos iš tikrųjų reiškia praktiškai ir kodėl optimizacija čia nėra vien tik techninis reikalas.
Core Web Vitals – tai trys pagrindiniai rodikliai: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) ir CLS (Cumulative Layout Shift). Kiekvienas iš jų matuoja skirtingą puslapio elgesio aspektą – greitį, interaktyvumą ir vizualinį stabilumą. Google juos oficialiai įtraukė į paieškos reitingavimo algoritmą 2021 metais, o 2024-aisiais FID (First Input Delay) buvo pakeistas INP, nes pastarasis tiksliau atspindi realią vartotojo sąveikos patirtį.
Svarbu suprasti: tai nėra tik SEO žaidimas. Tai realūs rodikliai, kurie parodo, ar jūsų svetainė veikia taip, kaip turėtų veikti iš vartotojo perspektyvos. Jei LCP yra blogas – žmonės mato tuščią ekraną per ilgai. Jei CLS yra blogas – mygtukai šokinėja po puslapį ir vartotojas paspaudžia ne tai, ką norėjo. Tai ne abstrakcija – tai tikros problemos, kurios kainuoja konversijas ir vartotojų pasitikėjimą.
LCP – kodėl jūsų puslapis atrodo lėtas net kai jis nėra
LCP matuoja, per kiek laiko ekrane atsiranda didžiausias matomas turinys – dažniausiai tai būna hero paveikslėlis, didelis antraštės tekstas arba video miniatiūra. Geras rezultatas yra iki 2,5 sekundės, priimtinas – iki 4 sekundžių. Viskas, kas ilgiau – jau problema.
Praktikoje LCP dažniausiai kenčia dėl kelių priežasčių:
- Neoptimizuoti paveikslėliai – tai klasika. PNG failas, kuris sveria 3 MB, kai galėtų sverti 200 KB WebP formatu.
- Render-blocking resursai – CSS ir JavaScript failai, kurie blokuoja puslapio atvaizdavimą, kol nesikraunami.
- Lėtas serverio atsakas (TTFB) – jei serveris atsako ilgiau nei 600 ms, LCP automatiškai kenčia.
- Lazy loading ant LCP elemento – tai dažna klaida. Jei hero paveikslėliui pritaikote
loading="lazy", naršyklė jo nekraus iš karto, ir LCP šaus į viršų.
Vienas iš efektyviausių sprendimų – naudoti <link rel="preload"> LCP elementui. Pavyzdžiui:
<link rel="preload" as="image" href="hero-image.webp" fetchpriority="high">Tai liepia naršyklei šį resursą krauti pirmiausiai, dar prieš pradedant analizuoti likusį HTML. fetchpriority=”high” atributas – palyginti naujas papildymas, bet jau puikiai palaikomas visose moderniose naršyklėse ir gali sumažinti LCP keliais šimtais milisekundžių.
Kita dažnai pamirštama detalė – šriftai. Google Fonts ar kiti išoriniai šriftai gali sulėtinti LCP, nes naršyklė turi laukti, kol jie atsisiųs, prieš rodydama tekstą. Sprendimas: arba self-host šriftus, arba naudoti font-display: swap, kad tekstas būtų rodomas su atsarginiu šriftu, kol pagrindinis kraunasi.
INP – naujasis metrikų žaidėjas, kurį visi pamiršta
INP (Interaction to Next Paint) pakeitė FID 2024 metų kovą, ir tai buvo reikšmingas pokytis. Skirtumas tarp jų esminis: FID matavo tik pirmąją sąveiką su puslapiu, o INP stebi visas sąveikas per visą sesijos laiką – paspaudimus, klaviatūros įvedimą, jutiklinio ekrano gestus – ir paima blogiausią rezultatą (tiksliau, 98-ąjį percentilį).
Geras INP – iki 200 ms. Tai reiškia, kad nuo vartotojo veiksmo iki vizualinio atsakymo ekrane turi praeiti ne daugiau nei 200 milisekundžių. Tai gana griežtas reikalavimas, ypač puslapiams su daug JavaScript logikos.
Pagrindinės INP problemos kyla dėl:
- Ilgų užduočių (Long Tasks) pagrindiniame gijoje – JavaScript, kuris veikia ilgiau nei 50 ms vienu metu, blokuoja naršyklę nuo reagavimo į vartotojo veiksmus.
- Perteklinio JavaScript kiekio – kiekvienas framework’as, kiekvienas plugin’as prideda svorį. React, Vue, Angular – visi jie turi savo kainą.
- Neefektyvių event handler’ių – jei paspaudus mygtuką vykdoma sunki operacija sinchroniškai, INP kenčia.
Praktinis patarimas: naudokite Chrome DevTools Performance panelį arba DebugBear įrankį, kad identifikuotumėte ilgas užduotis. Ieškokite raudonais pažymėtų blokų „Main” gijoje – tai jūsų priešai. Sprendimas dažnai yra sunkias operacijas suskaidyti į mažesnius gabalus naudojant setTimeout arba scheduler.yield() API, kuris leidžia naršyklei „kvėpuoti” tarp operacijų.
Taip pat verta peržiūrėti, ar naudojate trečiųjų šalių skriptus – analytics, chat widget’us, reklamos kodus. Jie dažnai yra INP problemų šaltinis, nes vykdo savo kodą pagrindiniame gijoje ir jūs neturite jokios kontrolės virš to, ką jie daro.
CLS – kai puslapis šokinėja kaip gyvas
Cumulative Layout Shift matuoja, kiek vizualiai nestabilus yra puslapis kraunantis. Jei paveikslėlis atsiranda ir pastumia tekstą žemyn, jei reklama įsiterpia ir išstumia mygtuką – tai CLS. Geras rezultatas yra mažiau nei 0,1.
CLS skaičiuojamas pagal formulę: impact fraction × distance fraction. Paprastai tariant – kiek ekrano ploto buvo paveikta ir kiek tas elementas pajudėjo. Kuo didesnis plotas ir kuo didesnis judėjimas, tuo blogesnė metrika.
Dažniausios CLS priežastys ir sprendimai:
Paveikslėliai be nurodytų dimensijų. Tai klasikinė problema. Kai naršyklė nežino paveikslėlio dydžio prieš jį atsisiunčiant, ji nepaskiria vietos ir vėliau, kai paveikslėlis atsiranda, visas turinys šokteli. Sprendimas paprastas – visada nurodykite width ir height atributus:
<img src="foto.webp" width="800" height="600" alt="aprašymas">Modernūs naršyklės naudoja šiuos atributus, kad apskaičiuotų aspect ratio ir paskiria vietą dar prieš paveikslėliui atsisiunčiant.
Dinamiškai įkeliamas turinys. Reklamos, embed’ai, cookie banner’iai – visi jie gali sukelti layout shift’ą. Jei žinote, kad reklama bus rodoma, paskirite jai vietą iš anksto naudodami CSS min-height. Taip pat verta apsvarstyti, ar cookie banner’is tikrai turi atsirasti virš turinio – galbūt jis gali būti rodomas apačioje kaip sticky elementas.
Web šriftai. FOUT (Flash of Unstyled Text) ir FOIT (Flash of Invisible Text) abu gali sukelti layout shift’ą, jei šrifto metrikos skiriasi nuo atsarginio šrifto. Čia padeda size-adjust, ascent-override ir kiti CSS šrifto deskriptoriai, kurie leidžia „suderinti” atsarginį šriftą su pagrindiniu, kad perjungimas būtų kuo sklandesnis.
Matavimo įrankiai – kuo matuoti ir kaip interpretuoti
Prieš pradedant optimizuoti, reikia žinoti, kur yra problema. Čia svarbu suprasti skirtumą tarp lab duomenų ir field duomenų.
Lab duomenys – tai sintetiniai matavimai, atlikti kontroliuojamomis sąlygomis. Pagrindiniai įrankiai:
- Google PageSpeed Insights – greičiausias būdas gauti pradinį vaizdą. Rodo ir lab, ir field duomenis.
- Lighthouse – integruotas į Chrome DevTools, leidžia testuoti lokaliai. Naudingas, kai norite pamatyti, kaip pakeitimai veikia prieš publikuojant.
- WebPageTest – galingesnis įrankis su detalesniais filmstrip vaizdais, connection throttling galimybėmis ir multi-step testais.
Field duomenys – tai realių vartotojų patirtis, surinkta per Chrome User Experience Report (CrUX). Juos galite matyti Google Search Console skiltyje „Core Web Vitals”. Tai svarbiau nei lab duomenys, nes Google reitingavimui naudoja būtent field duomenis.
Svarbi pastaba: jei jūsų svetainė nauja arba turi mažai srauto, CrUX duomenų gali nebūti pakankamai, ir Google negalės įvertinti jūsų Core Web Vitals. Tokiu atveju reitingavimui naudojami lab duomenys kaip atsarginis variantas.
Reguliariam monitoringui verta naudoti DebugBear, Calibre arba tiesiog Google Search Console su nustatytais alert’ais. Automatizuotas monitoringas yra esminis – be jo galite nepastebėti, kad koks nors atnaujinimas ar naujas plugin’as sugadino metrikas.
WordPress ir kiti CMS – specifiniai iššūkiai
Didelė dalis interneto veikia ant WordPress, ir čia Core Web Vitals optimizacija turi savo niuansų. WordPress iš prigimties nėra greičiausias, bet su tinkamais sprendimais galima pasiekti puikius rezultatus.
Pirmas žingsnis – caching. WP Rocket, W3 Total Cache arba LiteSpeed Cache (jei hostingas palaiko LiteSpeed) gali dramatiškai pagerinti TTFB ir LCP. WP Rocket šiuo metu laikomas geriausiu pasirinkimu dėl paprastumo ir efektyvumo – jis automatiškai tvarko daugumą optimizacijų, įskaitant paveikslėlių lazy loading, CSS/JS minification ir preloading.
Antra problema – paveikslėliai. WordPress automatiškai generuoja kelias paveikslėlių versijas, bet ne visada WebP formatu. Smush, Imagify arba ShortPixel plugin’ai gali automatiškai konvertuoti paveikslėlius į WebP ir optimizuoti jų dydį. Taip pat verta patikrinti, ar tema nenaudoja paveikslėlių kaip CSS background-image ten, kur galėtų naudoti <img> elementus – CSS background paveikslėliai negauna preload prioriteto automatiškai.
Trečia – JavaScript ir CSS bloat. Kiekvienas plugin’as prideda savo skriptus ir stilius, ir dažnai jie kraunami visuose puslapiuose, net jei nereikalingi. WP Rocket turi funkciją „Load JS Deferred” ir „Delay JS Execution”, kuri gali padėti, bet reikia testuoti kiekvieną atvejį individualiai – kartais agresyvus JS atidėjimas sulaužo funkcionalumą.
Jei naudojate page builder’ius kaip Elementor ar Divi – žinokite, kad jie generuoja daug inline CSS ir JavaScript. Tai natūraliai kenks Core Web Vitals. Čia nėra lengvo sprendimo – arba priimate kompromisą, arba pereinat prie lengvesnio sprendimo.
Hostingo ir serverio pusės optimizacija – pamatas, be kurio kita neturi prasmės
Galite optimizuoti paveikslėlius, minifikuoti JavaScript ir daryti viską teisingai kliento pusėje, bet jei serveris atsako lėtai – viskas veltui. TTFB (Time to First Byte) tiesiogiai veikia LCP, ir jei jis viršija 600 ms, turite serverio problemą, ne frontend problemą.
Keletas konkrečių rekomendacijų:
CDN naudojimas yra beveik privalomas šiandien. Cloudflare nemokamas planas suteikia globalų CDN, DDoS apsaugą ir automatinį paveikslėlių optimizavimą (su Pro planu). Alternatyvos – BunnyCDN (puikus kainos ir kokybės santykis), Fastly, AWS CloudFront. CDN sumažina fizinį atstumą tarp serverio ir vartotojo, kas tiesiogiai mažina TTFB.
HTTP/2 arba HTTP/3 turėtų būti įjungtas jūsų serveryje. HTTP/2 leidžia multiplexing – kelių resursų siuntimą vienu ryšiu vienu metu, kas reikšmingai pagreitina puslapio krovimą. HTTP/3 (QUIC protokolas) dar greitesnis, ypač nestabiliuose ryšiuose. Patikrinkite su curl -I https://jusudomenas.lt – atsakyme turėtumėte matyti HTTP/2 arba HTTP/3.
Serverio pusės caching – Redis arba Memcached gali radikaliai sumažinti duomenų bazės užklausų laiką dinaminiuose puslapiuose. Jei naudojate managed WordPress hostingą kaip Kinsta, WP Engine ar Cloudways – jie tai tvarko automatiškai.
Resursų glaudinimas – Brotli glaudinimas yra efektyvesnis nei gzip ir turėtų būti naudojamas, jei serveris palaiko. Brotli gali sumažinti tekstinių resursų dydį 15-25% daugiau nei gzip.
Kai metrikų žalia spalva nereiškia, kad viskas gerai
Čia norisi pasakyti ką, ko dažnai nepasakoma: pasiekti žalią spalvą PageSpeed Insights – tai tikslas, bet ne pabaiga. Galima turėti puikius Core Web Vitals ir vis tiek turėti lėtą, nemalonią svetainę. Ir atvirkščiai – galima turėti šiek tiek prastesnius rodiklius, bet vartotojams svetainė atrodo greita ir patogi.
Metrikų žaidimas gali tapti pavojingas, kai pradedama optimizuoti rodikliai, o ne realios problemos. Pavyzdžiui, galima „pagerinti” LCP pašalinant hero paveikslėlį – techniškai metrika pagerės, bet dizainas nukentės. Arba galima atidėti visą JavaScript, kad INP atrodytų gerai laboratoriniuose testuose, bet realūs vartotojai susidurs su neveikiančiais elementais.
Todėl optimizacija visada turėtų prasidėti nuo realių vartotojų duomenų – Google Search Console, Google Analytics 4 (kuris turi Core Web Vitals duomenis), arba RUM (Real User Monitoring) įrankių kaip Sentry, Datadog ar New Relic. Tik suprasdami, kur realūs žmonės susiduria su problemomis, galite priimti teisingus sprendimus.
Galiausiai – Core Web Vitals optimizacija nėra vienkartinis projektas. Kiekvienas naujas plugin’as, kiekvienas dizaino pakeitimas, kiekvienas naujas turinys gali paveikti metrikas. Reguliarus monitoringas, automatizuoti testai CI/CD pipeline’e ir aiški atsakomybė komandoje – štai kas leidžia išlaikyti gerus rezultatus ilgalaikėje perspektyvoje. Techninis darbas čia susipina su procesais ir kultūra, ir tai, beje, yra svarbiausia pamoka, kurią galima išmokti dirbant su Core Web Vitals.
