Svetainės greičio gerinimas

Kodėl greitis iš tikrųjų svarbus – ne tik SEO sumetimais

Daugelis žmonių, kai girdi apie svetainės greitį, iš karto galvoja apie Google reitingus. Taip, tai svarbu, bet tai tik viena medalio pusė. Realybė tokia, kad lėta svetainė tiesiogiai kerta per kišenę – ir tai ne metafora.

Amazon kažkada apskaičiavo, kad kiekvienas papildomas puslapio įkrovimo sekundės delsimas jiems kainuoja apie 1,6 milijardo dolerių per metus. Žinoma, jūsų projektas greičiausiai nėra Amazon masto, bet proporcija išlieka ta pati. Jei lankytojas laukia ilgiau nei 3 sekundes, pusė jų tiesiog išeina. Ir dažniausiai negrįžta.

Be to, Google nuo 2021 metų oficialiai įtraukė Core Web Vitals į reitingavimo algoritmą. Tai reiškia, kad LCP (Largest Contentful Paint), FID (First Input Delay) ir CLS (Cumulative Layout Shift) dabar yra ne tik techniniai rodikliai, kuriuos žiūri programuotojai – jie tiesiogiai veikia, kur jūsų svetainė atsiduria paieškos rezultatuose.

Taigi greičio optimizavimas – tai ne kažkoks techninis hobis. Tai verslo sprendimas.

Pirmiausia išmatuok, tada taisyk

Čia daro klaidą labai daug žmonių – pradeda taisyti, nežinodami, kas iš tikrųjų sulėtina svetainę. Tai panašu į tai, kaip gydytojas rašo receptą neapžiūrėjęs paciento.

Geriausi įrankiai, kuriuos reikia žinoti:

• Google PageSpeed Insights – nemokamas, parodo ir mobiliojo, ir stalinio kompiuterio rezultatus, pateikia konkrečias rekomendacijas. Pradėkite čia.
• GTmetrix – šiek tiek gilesnis, leidžia pasirinkti serverio lokaciją testavimui, rodo vandens krioklio (waterfall) diagramą, iš kurios matyti, kurie resursai užtrunka ilgiausiai.
• WebPageTest – profesionalų įrankis, leidžia testuoti iš skirtingų lokacijų, skirtingomis ryšio sąlygomis, net imituoti lėtą mobilųjį internetą.
• Chrome DevTools – tiesiog atidarykite naršyklę, paspauskite F12, eikite į Network arba Performance skirtuką ir pamatysite viską realiu laiku.

Svarbus dalykas – testuokite ne tik iš savo kompiuterio. Jūsų mašina gali turėti talpykloje (cache) sukauptus duomenis, greitas procesorius, greitą internetą. Realus lankytojas gali naudoti seną telefoną su 3G ryšiu. GTmetrix ir WebPageTest leidžia imituoti tokias sąlygas.

Kai turėsite rezultatus, susifokusuokite į tai, kas duoda didžiausią efektą – paprastai tai būna vaizdai, JavaScript ir serverio atsakymo laikas.

Vaizdai – didžiausias greičio žudikas, kurį lengviausia sutvarkyti

Statistiškai, vaizdai sudaro apie 50-70% vidutinio tinklalapio svorio. Ir dažniausiai jie yra visiškai neoptimizuoti. Žmonės įkelia 4000×3000 pikselių nuotrauką tiesiai iš fotoaparato, o svetainė ją rodo 400×300 pikselių dydžio langelyje. Naršyklė vis tiek atsisiunčia visą failą.

Ką reikia daryti:

• Naudokite tinkamą formatą. WebP formatas yra maždaug 25-35% mažesnis nei JPEG, išlaikant panašią kokybę. AVIF dar geresnis, bet palaikymas dar ne visur. Šiandien WebP yra geras pasirinkimas – jį palaiko visi modernūs naršykliai.
• Keiskite dydį prieš įkeldami. Jei vaizdas bus rodomas 800px pločio, įkelkite 800px (arba 1600px retina ekranams) – ne 4000px.
• Suspausti, bet protingai. Squoosh.app leidžia vizualiai palyginti originalą ir suspaustą versiją. TinyPNG/TinyJPEG automatiškai suspaudžia be didelio kokybės praradimo.
• Lazy loading. Vaizdai, kurie yra žemiau puslapio, neturėtų būti kraunami iš karto. HTML atributas loading="lazy" tai padaro automatiškai – ir tai vienas paprasčiausių pagerinimų, kurį galite padaryti šiandien.

Jei naudojate WordPress, tokie įskiepiai kaip ShortPixel, Imagify arba Smush gali automatizuoti didžiąją dalį šio proceso. Bet net ir be jų – tiesiog pakeiskite formatą į WebP ir sumažinkite dydį. Efektas bus akivaizdus.

JavaScript – galinga, bet brangi

JavaScript yra viena iš pagrindinių priežasčių, kodėl modernios svetainės yra lėtesnės nei tos, kurios buvo prieš 10 metų, nors interneto greitis per tą laiką išaugo kelis kartus. Paradoksas? Ne visai – tiesiog svetainės tapo daug sudėtingesnės, o JavaScript kiekis išaugo eksponentiškai.

Problema ta, kad JavaScript yra „blokuojantis” resursas. Kai naršyklė randa <script> žymą, ji sustoja parsisiuntinėti ir apdoroti puslapį, kol tas skriptas nebus įvykdytas. Todėl svarbu:

• Naudoti defer arba async atributus. defer reiškia „parsisiųsk, bet vykdyk tik kai HTML bus apdorotas”. async – „parsisiųsk ir vykdyk iš karto, bet neblokuok”. Daugumoje atvejų defer yra geresnis pasirinkimas.
• Pašalinti nenaudojamus skriptus. Kiek kartų matėte svetainę su 5 skirtingais analitikos įrankiais, 3 chat widgetais ir dešimtimis trečiųjų šalių skriptų? Kiekvienas iš jų kainuoja. Peržiūrėkite, kas iš tikrųjų naudojama.
• Code splitting. Jei naudojate React, Vue ar kitą modernų framework’ą, nereikia krauti viso kodo iš karto. Lazy loading komponentams leidžia krauti tik tai, kas reikalinga konkrečiam puslapiui.
• Minifikacija ir bundling. Webpack, Vite, Rollup – šie įrankiai suspaudžia ir sujungia failus. Jei dar nenaudojate build proceso, laikas pradėti.

Praktinis patarimas: Chrome DevTools Coverage skirtukas parodo, kiek procentų jūsų JavaScript kodo iš tikrųjų naudojama puslapyje. Dažnai skaičius šokiruoja – 70-80% nenaudojamo kodo nėra retenybė.

Serverio pusė – hosting ir talpykla

Galite optimizuoti viską kliento pusėje, bet jei serveris atsako per 2 sekundes, niekas kitas nepadės. TTFB (Time to First Byte) – laikas nuo užklausos iki pirmojo serverio atsakymo baito – turėtų būti mažesnis nei 200ms. Jei jis didesnis nei 500ms, problema yra serveryje.

Kelios pagrindinės kryptys:

Hosting pasirinkimas. Pigiausias shared hosting gali būti priežastis, kodėl jūsų svetainė lėta. Jei rimtai žiūrite į projektą, VPS arba cloud hosting (DigitalOcean, Hetzner, AWS, Google Cloud) duos žymiai geresnį TTFB. Hetzner šiuo metu yra puikus kainos ir kokybės santykis Europoje.

Talpykla (caching). Kiekvienas puslapio užkrovimas neturėtų generuoti visko iš naujo. Serverio pusės talpykla (Redis, Memcached) saugo dažnai naudojamus duomenis atmintyje. WordPress atveju W3 Total Cache arba WP Rocket gali dramatiškai pagerinti situaciją.

CDN (Content Delivery Network). Cloudflare yra nemokamas ir vienas geriausių sprendimų. Jis saugo jūsų svetainės kopijas serveriuose visame pasaulyje, todėl lankytojas iš Japonijos gauna turinį iš artimiausio serverio, o ne iš jūsų serverio Vokietijoje. Tai gali sumažinti įkrovimo laiką keliais šimtais milisekundžių.

HTTP/2 arba HTTP/3. Patikrinkite, ar jūsų serveris palaiko HTTP/2. Jis leidžia siųsti kelis failus vienu ryšiu vienu metu, vietoj to, kad kiekvienas failas lauktų savo eilėje. Dauguma modernių hostingų tai palaiko, bet verta patikrinti.

CSS ir šriftai – smulkmenos, kurios sudaro didelį vaizdą

CSS paprastai nėra didžiausia problema, bet yra keletas dalykų, kurie gali ženkliai pagerinti suvokiamą greitį (perceived performance) – tai, kaip greita svetainė atrodo vartotojui, net jei techniniai rodikliai yra tie patys.

Critical CSS. Tai CSS, kuris reikalingas tam, kas matoma ekrane be slinkimo (above the fold). Jei šis CSS yra inline HTML dokumente, naršyklė gali iš karto pradėti piešti puslapį, nelaukdama išorinio CSS failo. Įrankiai kaip Critical arba Penthouse gali automatiškai ištraukti šį CSS.

Šriftai. Google Fonts yra patogus, bet kiekvienas šriftas – tai papildoma HTTP užklausa ir papildomas failas. Kelios rekomendacijos:

• Naudokite tik tuos šriftų svorius (weights), kurie iš tikrųjų naudojami – ne visus 9 variantus.
• font-display: swap leidžia iš karto rodyti tekstą sisteminiu šriftu, o kai Google Fonts šriftas bus parsisiųstas – jį pakeisti. Taip vartotojas mato turinį greičiau.
• Svarstykite self-hosting šriftus – tai pašalina priklausomybę nuo trečiosios šalies serverio ir leidžia geriau kontroliuoti talpyklą.
• Variable fonts – vienas šrifto failas, kuris apima visus svorius ir stilius. Daug efektyviau nei kelios atskiros bylos.

Unused CSS. Jei naudojate Bootstrap ar kitą didelę CSS biblioteką, bet naudojate tik 10% jos, likusieji 90% vis tiek kraunami. PurgeCSS automatiškai pašalina nenaudojamas CSS taisykles.

Mobilieji įrenginiai – čia negalima daryti kompromisų

Daugiau nei 60% interneto srauto šiandien ateina iš mobiliųjų įrenginių. Ir mobiliojo ryšio sąlygos yra žymiai prastesnės nei stacionaraus interneto – lėtesnis ryšys, didesnis latency, mažiau procesoriaus galios. Tai reiškia, kad optimizavimas mobiliesiems yra ne papildoma funkcija, o pagrindas.

Google jau seniai perėjo prie „mobile-first indexing” – tai reiškia, kad jie pirmiausia indeksuoja ir vertina jūsų svetainės mobiliąją versiją. Jei ji lėta, kenčia visas reitingas.

Praktiniai žingsniai:

• Testuokite su lėtu ryšiu. Chrome DevTools Network skirtuke galite pasirinkti „Slow 3G” ir pamatyti, kaip jūsų svetainė atrodo realiam vartotojui su prasta jungtimi.
• Responsive images. HTML srcset atributas leidžia nurodyti skirtingus vaizdus skirtingiems ekrano dydžiams. Telefonas parsisiunčia mažesnį failą, stalinis kompiuteris – didesnį.
• Touch targets. Mygtukai ir nuorodos turi būti pakankamai dideli pirštui. Tai ne tik UX klausimas – Google tai vertina kaip kokybės rodiklį.
• Mažiau animacijų. Sudėtingos CSS animacijos gali perkrauti mobiliojo procesoriaus GPU. Naudokite will-change atsargiai ir testuokite realiuose įrenginiuose.

Kai greitis tampa kultūra, o ne projektas

Čia norisi pasakyti kažką svarbaus: greičio optimizavimas nėra vienkartinis projektas. Tai nuolatinis procesas. Svetainės auga, pridedami nauji įskiepiai, nauji skriptai, nauji vaizdai – ir kiekvienas iš jų gali po truputį lėtinti visumą. Po metų grįžtate ir matote, kad PageSpeed balas nukrito nuo 90 iki 60, nors nieko „nedarėte”.

Todėl verta sukurti paprastą rutinos sistemą: kartą per mėnesį paleiskite GTmetrix testą, pažiūrėkite, ar kas pasikeitė, ir jei taip – išsiaiškinkite kodėl. Google Search Console taip pat rodo Core Web Vitals duomenis realiems vartotojams – tai vertingesnė informacija nei laboratoriniai testai.

Jei dirbate komandoje, verta nustatyti „performance budgets” – maksimalius leistinus puslapio dydžius ir įkrovimo laikus. Kai naujas kodas viršija biudžetą, CI/CD pipeline gali automatiškai perspėti arba net blokuoti deploy’ą. Lighthouse CI tai padaro gana paprastai.

Galiausiai – greitis yra ne tik techninė, bet ir dizaino problema. Kiekvienas naujas elementas, kiekvienas šriftas, kiekvienas trečiosios šalies widgetas turi kainą. Geras web dizaineris ir programuotojas visada klausia: „Ar tai tikrai reikalinga? Ar nauda verta kainos?” Tokia mąstysena ilgainiui duoda daugiau nei bet koks optimizavimo įrankis.

Pradėkite nuo matavimo, susifokusuokite į didžiausias problemas (dažniausiai vaizdai ir JavaScript), nepamirškite serverio pusės, ir padarykite greičio stebėjimą įprastu procesu. Tai nėra raketų mokslas – bet reikia nuoseklumo.