Kodėl puslapio greitis vis dar svarbus 2025-aisiais
Prisimenu laikus, kai interneto sparta buvo matuojama kilobitais per sekundę, o kiekvienas paveiksliukas puslapyje reikalavo strateginio sprendimo. Dabar turime 5G, šviesolaidį ir galingus įrenginius, bet kodėl vis dar kalbame apie optimizavimą? Atsakymas paprastas – vartotojų kantrybė neaugo proporcingai interneto spartai.
Tyrimai rodo, kad jei puslapis neužsikrauna per 3 sekundes, apie 53% mobiliųjų vartotojų tiesiog išeina. Google tai žino ir aktyviai baudžia lėtus puslapius žemesne pozicija paieškoje. Bet svarbiausia – tai tiesiog profesionalumo klausimas. Jei kuriate produktą, kuris lėtai veikia, jūs nepagarbiąte savo vartotojų laiko.
Critical rendering path (CRP) optimizavimas – tai ne dar vienas buzzword, o konkretus procesas, kaip naršyklė transformuoja HTML, CSS ir JavaScript į pikselius ekrane. Suprasdami šį procesą, galime radikaliai pagerinti puslapio veikimą.
Kaip naršyklė iš tikrųjų atvaizduoja puslapį
Kai vartotojas įveda jūsų puslapio adresą, prasideda įdomus procesas. Naršyklė gauna HTML dokumentą ir pradeda jį skaityti nuo viršaus žemyn. Čia svarbu suprasti, kad naršyklė nelaiko – ji nori kuo greičiau parodyti kažką vartotojui.
Pirmiausia kuriamas DOM (Document Object Model) medis iš HTML. Tai dar ne vizualinis dalykas – tiesiog duomenų struktūra atmintyje. Toliau naršyklė susiduria su CSS ir kuria CSSOM (CSS Object Model). Tik turint abu šiuos medžius, galima sukurti render tree – tai jau yra informacija apie tai, kas ir kaip bus rodoma.
Paskui vyksta layout (arba reflow) – naršyklė apskaičiuoja kiekvieno elemento tikslią poziciją ir dydį. Galiausiai – painting, kai pikseliai faktiškai nupiešiami ekrane. Skamba paprasta, bet kiekvienas šis žingsnis gali tapti buteliu kakleliu.
Praktiškai tai reiškia: jei jūsų CSS failas yra 500KB ir pilnas nenaudojamų stilių, naršyklė vis tiek turės jį visą parsisiųsti ir apdoroti prieš rodydama bet ką ekrane. Jei JavaScript failas manipuliuoja DOM anksti puslapio užsikrovimo metu, viskas sustoja ir laukia.
CSS – tylus greičio žudikas
CSS yra render-blocking resursas. Tai reiškia, kad naršyklė neleis atvaizduoti puslapio, kol nebus parsisiųstas ir apdorotas visas CSS. Kodėl? Nes naršyklė nori išvengti FOUC (Flash of Unstyled Content) – situacijos, kai vartotojas trumpam pamato nesustilizuotą turinį.
Štai kur dažniausiai suklysta: įtraukiame visą Bootstrap ar kažkokį kitą framework’ą, nors naudojame gal 15% jo funkcionalumo. Arba turime vieną didžiulį CSS failą visai svetainei, nors konkrečiam puslapiui reikia tik dalies tų stilių.
Praktiniai sprendimai čia tokie:
Critical CSS – ištraukite tik tuos stilius, kurie reikalingi „above the fold” turiniui (tam, kas matoma be slinkimo) ir įterpkite juos tiesiai į HTML <head> sekcijoje su <style> tagu. Likusį CSS kraukite asinchroniškai. Yra įrankių kaip Critical, PurgeCSS ar UnCSS, kurie tai automatizuoja.
Media queries – jei turite stilius tik spausdinimui ar tik tam tikroms ekrano raiškoms, pažymėkite tai su media atributu: <link rel="stylesheet" href="print.css" media="print">. Naršyklė vis tiek parsisiųs failą, bet neblokuos renderinimo.
CSS failų skaidymas – vietoj vieno milžiniško failo, turėkite atskirą kritinį CSS ir likusius stilius. Galite naudoti preload: <link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
Realus pavyzdys iš praktikos: optimizavau e-commerce puslapį, kuris turėjo 450KB CSS failą. Išskaidžius į critical CSS (12KB inline) ir likusį dalį, First Contentful Paint pagerėjo nuo 2.8s iki 1.1s. Vartotojai to nepastebėjo vizualiai, bet konversijos augo.
JavaScript ir jo įtaka renderingui
JavaScript yra dar didesnis render-blocking resursas nei CSS. Kai naršyklė susiduria su <script> tagu, ji sustoja, parsisiunčia failą, jį vykdo ir tik tada tęsia HTML apdorojimą. Kodėl? Nes JavaScript gali modifikuoti DOM ir CSSOM – naršyklė negali rizikuoti.
Tradiciškai script tagai buvo dedami prieš </body> uždarymą, kad puslapio turinys užsikrautų pirma. Bet dabar turime geresnius įrankius.
Async atributas – <script async src="analytics.js"></script> nurodo naršyklei parsisiųsti skriptą lygiagrečiai su kitu turiniu ir vykdyti iš karto kai tik jis parsisiųstas. Tinka skriptams, kurie neturi priklausomybių (analytics, reklamos).
Defer atributas – <script defer src="app.js"></script> parsisiunčia skriptą lygiagrečiai, bet vykdo tik kai visas HTML yra apdorotas. Skriptai su defer vykdomi eilės tvarka, todėl tinka aplikacijos logikai.
Module scripts – <script type="module" src="main.js"></script> automatiškai veikia kaip defer ir leidžia naudoti ES6 modulius.
Bet štai ko daugelis nežino: net su async/defer, didelių JavaScript failų parsisiuntimas vis tiek naudoja tinklo pralaidumą ir vėliau – parsing bei execution laiką. Todėl code splitting yra būtinas.
Jei naudojate Webpack, Rollup ar Vite, konfigūruokite dinaminį importavimą: import('./heavy-module.js').then(module => { /* use it */ }). Tai sukuria atskirą bundle’ą, kuris kraunamas tik kai reikia.
Vienas projektas, kurį peržiūrėjau, turėjo 890KB JavaScript bundle’ą pradiniame puslapio užkrovime. Po code splitting ir lazy loading įdiegimo, pradinis bundle sumažėjo iki 120KB. Time to Interactive pagerėjo nuo 5.2s iki 1.8s.
Šriftų optimizavimas – detalė, kuri daro skirtumą
Web šriftai – tai viena iš subtiliausių CRP optimizavimo sričių. Daugelis kūrėjų tiesiog įtraukia Google Fonts nuorodą ir užmiršta. Bet šriftai gali sukelti FOIT (Flash of Invisible Text) arba FOUT (Flash of Unstyled Text), kai tekstas trumpam pranyksta arba rodomas su sisteminiu šriftu.
Naršyklės skirtingai elgiasi su šriftų užkrovimu. Chrome ir Firefox slepia tekstą iki 3 sekundžių laukdami šrifto, Safari rodo sistemį šriftą iš karto. Tai gali sukelti nepatogią vartotojo patirtį.
font-display yra CSS savybė, kuri kontroliuoja šį elgesį:
@font-face {
font-family: 'Custom Font';
src: url('font.woff2') format('woff2');
font-display: swap;
}
Galimos reikšmės: auto (naršyklės sprendimas), block (slepia tekstą iki 3s), swap (rodo sisteminį šriftą iš karto, pakeičia kai užsikrauna), fallback (trumpas blokavimas, paskui swap su limitu), optional (naršyklė gali nuspręsti nenaudoti šrifto jei tinklas lėtas).
Dažniausiai rekomenduoju font-display: swap – vartotojas iš karto mato turinį, net jei šriftas dar kraunasi.
Kitas svarbus dalykas – šriftų failų optimizavimas. Naudokite tik WOFF2 formatą (puikus glaudinimas, plati parama). Jei reikia tik tam tikrų simbolių, naudokite subsetting – pavyzdžiui, jei svetainė tik lietuvių kalba, nereikia kinų hieroglifų.
Google Fonts leidžia nurodyti: ?family=Roboto&text=ABCDEFGabcdefgąčęėįšųūž – parsisiųsite tik reikalingus simbolius.
Ir dar vienas trikis – preload kritinių šriftų: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>. Tai nurodo naršyklei pradėti šrifto parsisiuntimą anksti, net prieš apdorojant CSS.
Paveikslėliai ir jų įtaka pirmai ekrano daliai
Paveikslėliai paprastai nėra render-blocking, bet jie gali užimti didžiulę tinklo pralaidumo dalį ir sulėtinti kitų kritinių resursų parsisiuntimą. Be to, jei paveikslėlis yra „above the fold”, vartotojas mato neužsikrovusį turinį – tai jaučiama kaip lėtas puslapis.
Moderniose svetainėse paveikslėliai sudaro 50-70% viso puslapio svorio. Čia yra didžiulė optimizavimo erdvė.
Lazy loading – paprasčiausias sprendimas: <img src="image.jpg" loading="lazy" alt="Description">. Naršyklė automatiškai atideda paveikslėlių, kurie nematomi, parsisiuntimą. Bet atsargiai – nenaudokite lazy loading paveikslėliams „above the fold”!
Responsive images – naudokite srcset ir sizes atributus:
<img
src="image-800.jpg"
srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
alt="Description">
Naršyklė pati pasirenka tinkamiausią paveikslėlio versiją pagal ekrano dydį ir raiškumą.
Modernūs formatai – WebP ir AVIF suteikia 25-50% mažesnius failus nei JPEG/PNG su ta pačia kokybe. Naudokite <picture> elementą fallback’ui:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Description">
</picture>
Preload LCP paveikslėlio – jei turite didelį hero paveikslėlį, kuris yra Largest Contentful Paint elementas, preload’inkite jį: <link rel="preload" as="image" href="hero.jpg">
Realus case: klientas turėjo 3.2MB hero paveikslėlį JPEG formatu. Konvertavus į WebP (680KB), pridėjus responsive variants ir preload – LCP pagerėjo nuo 4.1s iki 1.6s. Tai buvo vienas paprastas pakeitimas su dramatiškais rezultatais.
Resource hints ir jų protingas naudojimas
Naršyklės suteikia keletą mechanizmų, kaip „užuominos” apie tai, kokių resursų prireiks ateityje. Tai leidžia optimizuoti tinklo naudojimą ir pagreitinti užkrovimą.
dns-prefetch – atlieka DNS lookup iš anksto: <link rel="dns-prefetch" href="https://fonts.googleapis.com">. Naudinga third-party domenams (analytics, CDN, API).
preconnect – eina toliau nei dns-prefetch, atlieka visą connection setup (DNS, TCP, TLS): <link rel="preconnect" href="https://api.example.com">. Naudokite tik kritiniams third-party resursams, nes tai naudoja CPU ir tinklą.
prefetch – parsisiunčia resursus, kurie gali prireikti ateityje (kitas puslapis, vėliau reikalingas skriptas): <link rel="prefetch" href="next-page.html">. Naršyklė tai daro žemo prioriteto, kai yra laisva.
preload – parsisiunčia resursus, kurie tikrai prireiks šiame puslapyje, bet naršyklė gali jų „nematyti” iš karto: <link rel="preload" href="critical.css" as="style">. Didelis prioritetas.
Svarbu neperdirbti. Mačiau svetaines su 20+ preconnect ir preload direktyvų – tai tik kenkia. Naršyklė turi ribotą skaičių lygiagrečių ryšių. Jei preload’inate per daug, atidėsite tikrai kritinių resursų parsisiuntimą.
Mano taisyklė: maksimaliai 2-3 preconnect kritiniams third-party domenams, 1-2 preload tikrai kritiniams resursams (hero paveikslėlis, critical font), prefetch tik jei tikrai žinote vartotojo kelią (pvz., „Next” mygtukas).
Įdomus atvejis: SPA aplikacija su client-side routing. Naudojome prefetch, kai vartotojas užveda pelę ant nuorodos – kai jis spusteli, resursai jau parsisiųsti. Subjektyvus greitis padidėjo dramatiškai.
Serverio pusės optimizavimas CRP kontekste
Dažnai optimizuojame frontend’ą, bet pamirštame, kad serveris irgi turi įtakos CRP. Kuo greičiau naršyklė gauna HTML, tuo greičiau gali pradėti jį apdoroti.
HTTP/2 ir HTTP/3 – jei dar naudojate HTTP/1.1, praleidžiate daug. HTTP/2 leidžia multiplexing (keletas resursų per vieną ryšį), header compression, server push. HTTP/3 (QUIC) dar geresnis – greičiau užmezga ryšį, atsparesnis packet loss.
Compression – Gzip yra minimum, bet Brotli suteikia 15-25% geresnį glaudinimą. Visi modernūs naršyklės palaiko. Įsitikinkite, kad jūsų serveris (Nginx, Apache, CDN) naudoja Brotli tekstiniams resursams.
Caching headers – teisingi Cache-Control headeriai leidžia naršyklei išvengti nereikalingų užklausų. Statiniams resursams su hash’ais failo varde: Cache-Control: public, max-age=31536000, immutable. HTML: Cache-Control: no-cache (revalidate kiekvieną kartą, bet gali naudoti 304 Not Modified).
Early Hints (103) – naujas HTTP status kodas, kuris leidžia serveriui siųsti preload/preconnect hints dar prieš paruošiant pilną HTML atsakymą. Tai gali sutaupyti 100-200ms. Cloudflare ir kai kurie CDN jau palaiko.
Server-side rendering ar Static Generation – jei naudojate React, Vue ar panašų framework’ą, SSR arba SSG (Next.js, Nuxt, Astro) leidžia naršyklei gauti pilną HTML iš karto, vietoj tuščio <div id=”root”></div> ir laukimo kol JavaScript užkraus turinį.
Projektas su React SPA turėjo 4.5s First Contentful Paint. Perėjus į Next.js su SSR, FCP sumažėjo iki 1.2s. Vartotojai pagaliau matė turinį greitai, nors interaktyvumas dar užtrukdavo (bet tai jau kitas klausimas).
Matavimas, testavimas ir nuolatinis stebėjimas
Optimizavimas be matavimo – tai šaudymas tamsoje. Prieš pradėdami bet kokius pakeitimus, turite žinoti dabartinę situaciją ir įsigyti baseline metrics.
Lighthouse – įmontuotas Chrome DevTools, puikus pradžios taškas. Pateikia konkretų balą ir rekomendacijas. Bet atminkite – tai synthetic testing (simuliuota aplinka), ne realūs vartotojai.
WebPageTest – gilesnis įrankis, leidžia pasirinkti tikslią vietą, naršyklę, tinklo spartą. Waterfall diagrama puikiai parodo, kas ir kada kraunasi. Filmstrip view rodo vizualinę progresą.
Chrome DevTools Performance tab – detalus profiling, matote tiksliai kas vyksta: parsing, scripting, rendering, painting. Galite identifikuoti long tasks, kurios blokuoja main thread.
Core Web Vitals – Google oficialūs metrika:
– LCP (Largest Contentful Paint) – didžiausio elemento užkrovimo laikas, tikslas <2.5s – FID (First Input Delay) – laikas iki pirmojo interakcijos atsakymo, tikslas <100ms (keičiamas į INP) – CLS (Cumulative Layout Shift) – vizualinio stabilumo matas, tikslas <0.1 Šios metrikos tiesiogiai veikia SEO ir turėtų būti stebimos nuolat. Real User Monitoring (RUM) – synthetic testing rodo, kaip puslapis veikia idealiomis sąlygomis. RUM rodo, kaip jis veikia realiems vartotojams su jų įrenginiais, tinklais, lokacijomis. Įrankiai: Google Analytics 4 (Web Vitals), SpeedCurve, Sentry Performance, custom implementation su Navigation Timing API.
Praktinis patarimas: nustatykite performance budget. Pavyzdžiui: „Pradinis HTML <50KB, kritinis CSS <15KB, pradinis JS <150KB, LCP <2s, FCP <1.5s”. Integruokite į CI/CD – jei build viršija budget’ą, testas nepraėja. Webpack, Rollup turi plugins šiam tikslui. Vienas projektas, kurį konsultavau, įdiegė performance budget ir RUM. Per 3 mėnesius LCP pagerėjo 40%, nes kiekvienas naujas feature buvo vertinamas per performance prizmę. Tai tapo kultūros dalimi, ne vienkartine optimizavimo akcija.
Kai optimizavimas tampa gyvenimo būdu
Critical rendering path optimizavimas nėra vienkartinis projektas – tai nuolatinis procesas. Technologijos keičiasi, vartotojų lūkesčiai auga, jūsų produktas vystosi ir prideda naujų funkcijų. Kiekviena nauja funkcija gali sugriauti ankstesnį optimizavimą.
Svarbiausia pamoka, kurią išmokau per metus: greitis yra feature. Ne nice-to-have, ne „padarysime vėliau”, o pagrindinis produkto aspektas. Kaip saugumas, kaip prieinamumas, kaip funkcionalumas.
Pradėkite nuo low-hanging fruit: įdiekite lazy loading, optimizuokite paveikslėlius, pridėkite async/defer prie skriptų, suspauskite resursus. Tai gali suteikti 30-50% pagerijimą per kelias valandas darbo.
Toliau – gilesni dalykai: code splitting, critical CSS, resource hints, server-side optimizavimas. Čia jau reikia daugiau laiko ir supratimo, bet rezultatai būna dramatiški.
Ir nepamirškite matuoti. Optimizavimas be matavimo – tai tik spėliojimai. Nustatykite metrics, stebėkite jas, eksperimentuokite, mokykitės. Performance optimization – tai iteratyvus procesas, ne vienkartinis veiksmas.
Galiausiai, dalinkitės žiniomis su komanda. Jei tik vienas žmogus komandoje supranta performance, optimizavimas nebus ilgalaikis. Darykite code reviews su performance perspektyva, diskutuokite trade-off’us, švęskite pagerinimus.
Greitas puslapis – tai gerbiami vartotojai, didesnis engagement, geresnis SEO, daugiau konversijų. Investicija į CRP optimizavimą atsipirks su kaupu. Ir kas svarbiausia – jūs galėsite didžiuotis savo darbu, žinodami, kad sukūrėte kažką, kas veikia greitai ir sklandžiai.