Miért lassú a szép weboldal, és mit lehet vele kezdeni
Szvetlik Csongor
·
a szöveget a Claude Opus 5 írta
A weboldalad a laptopodon gyönyörű. Telefonon, gyenge mobilneten viszont másodpercekig csak egy fehér képernyő. A lassú weboldal ritkán a rossz kódtól lassú, hanem attól, hogy minden szép ötlet rajta maradt. Animált háttér, nagy fotók, négy betűkészlet, egy videó a fejlécben. Külön-külön mind ártalmatlan. Együtt viszont ezek adják ki a betöltési időt.
Miért lassú egy szép weboldal?
Egy szép weboldal attól lassú, hogy a látvány nagy fájlokból és folyamatos rajzolásból áll. A nagy fotó letöltése időbe kerül, a betűkészleté is, az animált háttér pedig a telefon grafikus vezérlőjét dolgoztatja, amíg a lap nyitva van. A böngésző mindezt a szöveg elé sorolja be, ezért a látogató üres felületet néz.
A böngésző sorban dolgozik. Előbb letölti a HTML-t, abból derül ki, milyen stíluslap, betű, kép és szkript kell még, és amíg a fontos darabok meg nem érkeznek, nincs mit kirajzolnia. Minden hozzáadott réteg egy újabb sor ebben a várólistában, és a sor lassabb hálózaton hosszabb.
A másik költség nem a letöltés, hanem a rajzolás. Egy animált háttér vagy egy folyamatosan mozgó fényeffekt képkockánként újraszámolja magát. Erős gépen ez nem látszik. Egy néhány éves középkategóriás telefonon viszont akadozik a görgetés, melegszik a készülék, és fogy az akkumulátor.
Négy tétel viszi el a weboldal sebességének nagy részét:
- A képek: egy szerkesztőből kimentett fotó gyakran több megabájt, és pontosan ugyanúgy néz ki, mint a webre kimentett, sokkal kisebb változata.
- A betűkészletek: minden vastagság és dőlt változat külön fájl, és amíg megérkezik, a szöveg vagy láthatatlan, vagy menet közben átugrik egy másik betűre.
- A szkriptek: egy csúszka, egy süti-sáv, egy chat-ablak és három mérőkód külön-külön kicsi, együtt viszont ezek foglalják le a telefon processzorát, pont amikor a látogató kattintana.
- A mozgás: ami folyamatosan fut a háttérben, annak folyamatos ára is van, akkor is, amikor senki nem nézi.
Egyik tétel sem hiba önmagában. A baj az, hogy egy új réteg felkerülésekor el sem hangzik a kérdés, mennyibe kerül. A látvány mindig látszik, az ára soha.
Mennyi az az idő, ami már sok?
Nincs egyetlen szám, de van egy közös mérce: a Core Web Vitals. A legfontosabb az LCP, vagyis az idő, amíg a lap fő tartalma megjelenik. Jónak akkor számít, ha 2,5 másodperc alatt marad. A másik kettő a válaszkészséget és a lap ugrálását méri: ott már a tizedmásodpercek és a néhány képpontnyi elmozdulás is számít.
A Core Web Vitals három számot jelent, és mind a három mást mér. Az LCP azt, hogy mikor jelenik meg a lap fő tartalma, jellemzően a nagy kép vagy a főcím. Az INP azt, hogy mennyit vár a látogató azután, hogy megérintett valamit. A CLS pedig azt, mennyit ugrál a tartalom betöltés közben: a jó érték itt 0,1 alatt van, és ezt a legkönnyebb elrontani egy utólag beeső sávval vagy egy helyet nem foglaló képpel.
A számoknál viszont fontosabb, hogy hol méred. A saját laptopod gyors hálózaton, teli gyorsítótárral mindig szép eredményt ad, mert nálad már minden fájl megvan. A látogató először jár ott, mobilneten, egy villamoson, egy hároméves telefonnal. A weboldal sebességéről ez az utóbbi helyzet mond igazat.
Van egy negyedik kérdés is, amit egyik mutató sem tesz fel: mi látszik abban a pár másodpercben? Ha a lap gyorsan megjelenik, de az első képernyőn csak egy jelmondat áll, a látogató ugyanúgy továbbmegy. A sebesség attól lesz értékes, hogy hamarabb ér oda a mondat, amiért jött.
Mit mérj, ha nem vagy fejlesztő?
Fogj egy átlagos telefont, kapcsold ki a wifit, és nyisd meg a saját lapodat úgy, ahogy egy idegen tenné. Amit ott látsz az első pillanatokban, az a valóság. Utána futtass egy nyilvános sebességmérőt a legfontosabb három oldaladon, és kérd el a fejlesztődtől ugyanezt a három számot havonta.
Kezdd a saját telefonoddal, mert azt a mérést nem lehet kimagyarázni. Nyisd meg a lapot mobilneten, és nézd meg, mikor jelenik meg az első olvasható mondat, ugrál-e utána a tartalom, és mennyi idő telik el az első koppintás és a válasz között. Ez a három megfigyelés nagyjából a három mutatót fedi le, csak szám nélkül.
Utána jön a gépi mérés. Egy nyilvános sebességmérő bármelyik nyilvános oldaladról ad egy jelentést, benne a mutatókkal és azzal a listával, hogy melyik fájl mennyi ideig tartott. Két dolgot érdemes tudni róla: a mobil eredmény a mérvadó, nem az asztali, és az egyszeri mérés nem ugyanaz, mint amit a valódi látogatóid tapasztalnak a saját készülékükön.
Ha van fejlesztőd, ne javítási listát kérj tőle, hanem ezt a hármat:
- Számokat: a három mutató a három legfontosabb oldalra, mobilon, ugyanabban a formában minden hónapban.
- Okot: melyik elem viszi el az időt, névvel, ne csak annyit, hogy nehéz a lap.
- Árat: mit veszítünk, ha kikerül, és mit nyerünk, ha marad. Ez a mondat dönti el a többit.
Nálunk ez nem külön kör a munka végén: a weboldal-készítésről szóló oldalunkon is ez a sorrend áll, mert a sebességet utólag nehezebb visszaszerezni, mint eleve el sem költeni.
Mit dobtunk ki a saját lapunkról?
Három dolgot. Az úszó felhőrétegeket a kezdőlapról, mert mindegyik egy teljes képernyős, végtelenítve animált textúra volt, amit egy keverési mód miatt képkockánként újra kellett laposítani. Egy WebGL-fényeffektet ugyanezért. És a belső lapok háttérmintázatát, ami telefonon 70 kilobájt letöltés volt, a szöveg mögött pedig nem kompozíció, hanem tapéta.
A kezdőlapunkon három felhőréteg úszott egymáson, és szép volt. Aztán megmértük: a rétegek akkor is dolgoztatták a telefont, amikor semmi nem történt a lapon, mert a keverési mód miatt minden képkockán újra kellett laposítani őket. A WebGL-fényeffekt ugyanezt a terhet tette a telefonra, ezért az is kikerült. A jelenet egyikkel sem lett szegényebb.
A képekkel nem az történt, hogy megszabadultunk tőlük, hanem hogy generáljuk őket. Minden fotó AVIF és WebP párban, három szélességben készül, és a böngésző azt tölti le, amire a kijelzőn tényleg szükség van. A nagy mesterpéldány a gépünkön marad, a kiszállított csomagba be sem kerül. A minőségi határt pedig nem a fájlméret adja, hanem a képpontonkénti eltérés az eredetitől: az a szám dönti el, hogy egy kép elég jó-e.
A betűk a saját kiszolgálónkról jönnek, nem egy külső betűszolgáltatás hivatkozásáról, és kettő van belőlük, nem négy. Ennek nemcsak sebesség-oka van: a külső hivatkozás minden látogató IP-címét továbbítja egy amerikai szolgáltatónak, ami egy magyar cég adatkezelési tájékoztatójában külön sor.
Az eredmény a lap nyitóképén látszik a legjobban: a hero háttérrétegei álló állapotban ma egyetlen képkockát sem rajzolnak újra. A látvány megmaradt, csak nem fut mögötte folyamatos rajzolás. Ezeket a döntéseket egyébként ember hozta, akkor is, amikor a szöveget gép írta: erről szól az a bejegyzésünk, amit egyetlen prompt írt.
Mi az, amit nem szabad kidobni?
A hozzáférhetőséget és a szöveget. A fókuszgyűrű, az ugrólink és a csökkentett mozgáshoz készült változatok mind a lapon maradtak: ezek nem díszek, ezeken múlik, hogy valaki egyáltalán tudja-e használni az oldalt. És nem dobjuk ki a tartalmat sem, mert egy üres, villámgyors lap semmire nem válaszol.
Gyorsítás közben könnyű elvenni is valamit. A fókuszgyűrű, vagyis az a jelölés, ami megmutatja, hol jár éppen a billentyűzet, sok lapról azért tűnik el, mert csúnyának tartják. Aki egérrel használja a lapot, sosem látja. Aki nem tud egeret használni, annak enélkül nincs támpontja arról, mire kattint éppen.
Ugyanez az ugrólink, ami a menü átugrásával rögtön a tartalomhoz visz, és ugyanez a csökkentett mozgáshoz készült változat: aki a saját készülékén kikapcsolta az animációkat, annál a mi lapunk sem animál. Ezek együtt néhány sornyi kód, tehát a törlésük a sebességen semmit nem javítana. Hozzáférhetőséget nem cserélünk sebességre.
A másik dolog, amihez nem érdemes nyúlni, a szöveg. A gyorsaság önmagában nem válasz semmire: egy üres lap tökéletes számokat mutat, és nem mond semmit. A keresők és az AI-válaszok is a szövegből dolgoznak, ezért az a bekezdés, ami tényleg megválaszol egy kérdést, a lap legértékesebb és egyben legolcsóbb része. Erről szól a GEO-optimalizálásról szóló írásunk.
A jó sorrend tehát nem az, hogy dobjunk ki mindent, ami szép. Hanem az, hogy minden elemtől megkérdezzük, mit ad hozzá, és mibe kerül. Ami mindkét kérdésre jól válaszol, marad. A többi mehet.
Mérés dönt, nem ízlés.