Kodėl mobilusis greitis tapo ne privalumu, o būtinybe
Prisimenu, kaip prieš kelerius metus klientas skambino panikos apimtas – jo e-parduotuvės konversijos krito kaip akmuo, nors niekas svetainėje nebuvo keista. Pasirodo, Google atnaujino savo algoritmus, o jo svetainė mobiliuosiuose įrenginiuose kraudavosi lėčiau nei Windows 98 paleidimas. Skamba pažįstama?
Šiandien mobilusis srautas sudaro daugiau nei 60% viso interneto trafiko, o Google nuo 2021-ųjų oficialiai naudoja Core Web Vitals kaip reitingavimo faktorių. Tai nebe kažkokia abstrakti metrika, kurią galima ignoruoti – tai tiesiogiai veikia jūsų verslo rezultatus. Tyrimai rodo, kad kiekviena papildoma sekundė krovimo metu sumažina konversijas apie 7%. Kai jūsų svetainė mobiliajame kraunasi 5 sekundes vietoj 2, tai jau ne smulkmena.
Core Web Vitals – tai trys pagrindiniai rodikliai, kuriuos Google laiko esminiais naudotojo patirčiai įvertinti: Largest Contentful Paint (LCP), First Input Delay (FID) ir Cumulative Layout Shift (CLS). Skamba kaip NASA terminologija? Supaprastinsiu.
LCP arba „kada pagaliau matau turinį”
Largest Contentful Paint matuoja, kiek laiko užtrunka, kol ekrane atsiranda didžiausias matomas turinio elementas. Paprastai tai būna hero vaizdas, antraštė ar tekstinis blokas. Google nori, kad tai įvyktų per 2.5 sekundes ar greičiau.
Praktikoje su šiuo rodikliu susiduria beveik visi, kurie dirba su vaizdiniais elementais. Štai keletas konkrečių būdų, kaip tai optimizuoti:
**Vaizdų optimizavimas yra alfa ir omega.** Naudokite modernias formatų alternatyvas – WebP arba AVIF vietoj tradicinių JPEG ir PNG. Skirtumas dramiškas: tas pats vaizdas WebP formate gali būti 25-35% mažesnis be jokių vizualinių nuostolių. Įgyvendinti tai galite naudodami <picture> elementą su fallback variantais senesnėms naršyklėms:
„`html
**Lazy loading – jūsų geriausias draugas.** Kodėl krauti vaizdus, kurie yra puslapio apačioje, kai naudotojas dar tik pradėjo skaityti viršų? Šiuolaikinėse naršyklėse tai įgyvendinti tapo juokingai paprasta:
„`html
„`
Tačiau atsargiai – nenaudokite lazy loading pirmam ekrane matomam turiniui! Tai klasikinė klaida, kurią matau nuolat. Jūsų hero vaizdas turi krautis iš karto, kitaip LCP tik pablogės.
**Prioritetų nustatymas kritiniams resursams.** Naudokite fetchpriority="high" atributą svarbiausiam vaizdui:
„`html
„`
Taip pat įsitikinkite, kad serveris palaiko HTTP/2 ar HTTP/3 – tai leidžia krautis keliems resursams vienu metu, o ne eilėje kaip senovėje.
FID ir jo įpėdinis INP – interaktyvumo galvos skausmas
First Input Delay matuoja laiką nuo pirmo naudotojo veiksmo (paspaudimo, mygtuko paspaudimo) iki momento, kai naršyklė gali į jį sureaguoti. Nuo 2024 kovo Google oficialiai pakeitė FID į Interaction to Next Paint (INP), kuris matuoja visų puslapio interakcijų atsakomumą, ne tik pirmos.
Čia paprastai kalti JavaScript. Daug JavaScript. Per daug JavaScript.
Mobilieji įrenginiai, net ir šiuolaikiniai, turi gerokai silpnesnius procesorius nei stalinis kompiuteris. Kai jūsų svetainė siunčia 2MB JavaScript kodo, kuris turi būti parsitas, sukompiliuotas ir vykdomas, mobilusis telefonas tiesiog spjauna į akis.
**Pirmasis žingsnis – auditas.** Atidarykite Chrome DevTools, eikite į Coverage skiltį ir perkraukite puslapį. Pamatysite, kiek jūsų JavaScript kodo iš tikrųjų naudojama. Dažnai rezultatas šokiruojantis – 60-70% kodo nėra naudojami pirminiame puslapio įkėlime.
**Code splitting yra privalomas.** Jei naudojate React, Vue ar kitą šiuolaikinį framework’ą, įsitikinkite, kad naudojate dinaminį importą:
„`javascript
// Blogai
import HeavyComponent from ‘./HeavyComponent’;
// Gerai
const HeavyComponent = lazy(() => import(‘./HeavyComponent’));
„`
Webpack, Vite ar kiti bundleriai automatiškai sukurs atskirus failus, kurie bus kraunami tik kai reikia.
**Third-party skriptai – tylieji žudikai.** Google Analytics, Facebook Pixel, reklaminiai skriptai, chat widgetai – visi jie vykdomi jūsų puslapyje ir lėtina interakcijas. Naudokite Partytown arba panašias bibliotekas, kad perkeltumėte šiuos skriptus į Web Worker:
„`html
„`
Taip jie veiks fone, neblokuodami pagrindinio thread’o.
CLS arba „kodėl viskas šokinėja”
Cumulative Layout Shift matuoja vizualinio stabilumo stoką. Ar pažįstama situacija, kai bandote paspausti mygtuką, bet paskutinę akimirką įsikrauna reklama ir paspaudžiate ją vietoj mygtuko? Tai ir yra CLS problema.
Google nori, kad šis rodiklis būtų mažesnis nei 0.1. Praktikoje tai reiškia, kad jūsų turinys neturi šokinėti kraunantis puslapiui.
**Rezervuokite vietą vaizdams ir video.** Visada nurodykite width ir height atributus:
„`html
„`
Šiuolaikinės naršyklės automatiškai apskaičiuos aspect ratio ir rezervuos reikiamą vietą prieš įsikraunant vaizdui. Tai veikia net jei naudojate responsive dizainą su CSS.
**Šriftų įkėlimas – dažnai ignoruojama problema.** Kai naudojate custom šriftus (Google Fonts, Adobe Fonts ir pan.), tekstas gali „šoktelėti”, kai šriftas įsikrauna. Naudokite font-display: swap arba dar geriau – font-display: optional:
„`css
@font-face {
font-family: ‘Custom Font’;
src: url(‘font.woff2’) format(‘woff2’);
font-display: optional;
}
„`
Su optional naršyklė naudos sisteminį šriftą, jei custom šriftas neįsikrauna pakankamai greitai. Taip išvengiama FOUT (Flash of Unstyled Text) efekto.
**Dinaminiam turiniui – aiškūs dydžiai.** Jei turite reklaminius banerius, embed’us ar dinaminį turinį, rezervuokite jiems vietą su min-height:
„`css
.ad-container {
min-height: 250px;
background: #f0f0f0;
}
„`
Geriau matyti pilką plotą trumpam nei leisti turiniui šokinėti.
Serverio atsakymo laikas – pamirštasis herojus
Galite optimizuoti front-end’ą kiek norite, bet jei serveris atsako 3 sekundes, viskas veltui. Time to First Byte (TTFB) turėtų būti mažesnis nei 600ms, idealiu atveju – apie 200-300ms.
**CDN nėra prabanga, o būtinybė.** Content Delivery Network paskirstys jūsų turinį po visą pasaulį, todėl naudotojas Lietuvoje gaus duomenis iš Varšuvos ar Frankfurto, o ne iš Kalifornijos. Cloudflare, Fastly, AWS CloudFront – pasirinkimų gausu, o kainos pradeda nuo nulio.
**Caching strategijos – ne tik apie max-age.** Naudokite stale-while-revalidate strategiją Service Worker’iuose:
„`javascript
self.addEventListener(‘fetch’, event => {
event.respondWith(
caches.open(‘dynamic’).then(cache => {
return cache.match(event.request).then(response => {
const fetchPromise = fetch(event.request).then(networkResponse => {
cache.put(event.request, networkResponse.clone());
return networkResponse;
});
return response || fetchPromise;
});
})
);
});
„`
Naudotojas iš karto gauna cached versiją, o fone atnaujinama nauja. Geriausias iš abiejų pasaulių.
**Database optimizavimas – backend’o dalis.** Jei naudojate WordPress, WooCommerce ar panašias CMS, įsitikinkite, kad turite object caching (Redis, Memcached). Skirtumas tarp puslapio, kuris kiekvieną kartą daro 50 database query, ir puslapio, kuris naudoja cache, yra diena ir naktis.
Testavimas ir monitoringas – kaip žinoti, ar pavyko
Optimizavimas be matavimo yra šaudymas tamsoje. Štai įrankiai, kuriuos naudoju kasdien:
**PageSpeed Insights** – Google’o oficialus įrankis. Įvedate URL, gaunate Core Web Vitals rezultatus ir konkrečias rekomendacijas. Tačiau atminkite – tai laboratoriniai duomenys, ne realūs naudotojų.
**Chrome DevTools Lighthouse** – tas pats variklis kaip PageSpeed Insights, bet lokaliai. Galite testuoti development versijas prieš deploy’inant. Naudokite throttling, kad simuliuotumėte lėtą mobilųjį ryšį:
„`
Lighthouse -> Settings -> Throttling -> Slow 4G
„`
**WebPageTest** – mano asmeninis favoritas. Galite pasirinkti tikslią vietą, įrenginį, ryšio greitį. Waterfall diagrama parodo kiekvieną resursą, kas ir kada blokuoja krovimą. Tai kaip rentgenas jūsų svetainei.
**Real User Monitoring (RUM)** – laboratoriniai testai yra geri, bet realūs naudotojų duomenys yra aukso vertės. Google Search Console rodo Core Web Vitals duomenis iš realių naudotojų. Taip pat galite naudoti:
„`javascript
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(‘LCP:’, entry.renderTime || entry.loadTime);
// Siųskite į analytics
}
}).observe({entryTypes: [‘largest-contentful-paint’]});
„`
**Continuous monitoring** – ne vienkartinis dalykas. Naudokite Lighthouse CI savo deployment pipeline’e, kad automatiškai tikrintumėte performance prieš kiekvieną release’ą. Jei Core Web Vitals pablogėja, build’as nepraeina.
Mobilieji framework’ai ir jų svertai
Pasirinktas framework’as gali lemti jūsų Core Web Vitals likimą. React, Vue, Angular – visi turi savo stipriąsias ir silpnąsias puses mobiliajame performance.
**React ir Next.js** – populiariausi, bet ne lengviausi. Bazinis React bundle yra apie 40KB gzipped, o su visomis dependencies lengvai peršoksite 100KB. Next.js su Server Components ir streaming SSR gali drastiškai pagerinti LCP, bet reikia mokėti teisingai konfigūruoti.
Praktinis patarimas: naudokite next/dynamic su ssr: false komponentams, kurie nereikalingi pirminiame render’e:
„`javascript
const HeavyChart = dynamic(() => import(‘./Chart’), {
ssr: false,
loading: () =>
});
„`
**Vue ir Nuxt** – šiek tiek lengvesni už React. Vue 3 su Composition API ir <script setup> generuoja efektyvesnį kodą. Nuxt 3 su Nitro serveriu ir auto-imports sumažina boilerplate’ą ir bundle dydį.
**Svelte ir SvelteKit** – mano asmeninė rekomendacija performance-critical projektams. Svelte kompiliuoja komponentus į vanilla JavaScript build metu, todėl runtime’as minimalus. SvelteKit su adapters leidžia deploy’inti bet kur – nuo serverless iki edge.
**Astro** – jei jūsų svetainė daugiausia statinė su interaktyvumo salomis, Astro yra šaunus pasirinkimas. Defaultu siunčia zero JavaScript, o komponentus galite „hydrate’inti” tik kai reikia:
„`astro
„`
Komponentas taps interaktyvus tik kai bus matomas viewport’e.
Edge computing ir naujos galimybės
Tradicinis serveris yra vienoje vietoje – Amerikoje, Europoje ar Azijoje. Naudotojas iš kitos žemyno pusės laukia, kol duomenys atkeliaus. Edge computing keičia šią paradigmą.
**Cloudflare Workers, Vercel Edge Functions, Deno Deploy** – tai platformos, kurios vykdo jūsų kodą geografiškai arti naudotojo. Latency krenta nuo šimtų milisekundžių iki dešimčių.
Pavyzdys su Cloudflare Workers:
„`javascript
export default {
async fetch(request) {
const url = new URL(request.url);
// Personalizuotas turinys pagal geolokaciją
const country = request.cf.country;
// Cache su edge
const cache = caches.default;
let response = await cache.match(request);
if (!response) {
response = await fetch(request);
response = new Response(response.body, response);
response.headers.set(‘Cache-Control’, ‘max-age=3600’);
await cache.put(request, response.clone());
}
return response;
}
};
„`
Kodas vykdomas <100ms nuo naudotojo, su built-in caching. TTFB atsiduria 50-100ms diapazone.**Edge rendering** – ne tik API. Galite render'inti HTML edge'e, naudodami frameworks kaip Qwik ar Fresh (Deno). Qwik ypač įdomus – jis "resumable" vietoj "hydration", todėl JavaScript vykdymas atidedamas iki pirmo interakcijos.
Kai optimizavimas tampa apsėdimas ir ką su tuo daryti
Dirbau su klientu, kuris norėjo, kad jo svetainė būtų „tobula” – 100 balų PageSpeed Insights. Praleidome savaites optimizuodami kiekvieną milisekundę, o konversijos… liko tos pačios. Problema buvo ne greityje, o naudotojo sąsajoje ir value proposition.
Core Web Vitals yra svarbūs, bet tai ne tikslas savaime. Jie yra priemonė geresnei naudotojo patirčiai. Jei jūsų svetainė kraunasi per 2 sekundes, bet naudotojas nesupranta, ką daryti arba turinys jam neįdomus, greitis nepadės.
**Prioritizuokite pagal poveikį.** Low-hanging fruits pirma: vaizdu optimizavimas, lazy loading, CDN. Tai duoda didžiausią rezultatą su mažiausiomis pastangomis. Paskui eikite giliau – code splitting, caching strategijos, serverio optimizavimas.
**Testuokite su realiais įrenginiais.** Chrome DevTools throttling yra geras, bet nieko nepakeičia realaus Xiaomi už 150 eurų su lėtu 3G ryšiu. Pirkite pigiausius populiarius telefonus savo tikslinėje rinkoje ir testuokite su jais.
**Automatizuokite.** Performance budgets CI/CD pipeline’e, automatiniai alertai kai Core Web Vitals nukrenta, reguliarūs audits. Negalite optimizuoti to, ko nematote.
**Edukuokite komandą.** Dažnai performance problemos atsiranda ne dėl blogio, o dėl nežinojimo. Dizaineris įkelia 5MB PNG, nes nežino apie WebP. Developer’is prideda dar vieną biblioteką, nes nežino, kad funkcionalumas jau egzistuoja. Code review turėtų įtraukti ir performance aspektus.
Mobiliosios svetainės greitis 2024-aisiais nėra techninė smulkmena – tai verslo sprendimas. Google rankinasi greitesnes svetaines, naudotojai pasirenka greitesnes svetaines, konversijos didėja greitesnėse svetainėse. Core Web Vitals suteikia konkrečius, matuojamus tikslus, o įrankiai ir technologijos jų pasiekti egzistuoja ir yra prieinami.
Pradėkite nuo matavimo, optimizuokite didžiausius bottleneck’us, automatizuokite monitoringą ir kartokite procesą. Performance optimizavimas nėra vienkartinis projektas – tai nuolatinis procesas. Bet rezultatai, tiek SEO, tiek verslo metrikos, yra viso to verti.