A weboldal sebesség optimalizálás nem tippek listája, hanem mérés-javítás-újramérés ciklus. Aki azzal kezdi, hogy telepít egy gyorsítótár bővítményt, az a rendszer felénél kezdi, és általában nem oldja meg azt a problémát, ami miatt tényleg lassú az oldal.
Ez a cikk egy konkrét eseten megy végig: a saját oldalunkon. Beleértve azt a három javítást is, ami logikus volt, mégis rossz irányba vitt. Ezt a részt szokta kihagyni a szakma, pedig szerintem ez a leghasznosabb.
Mit mérj, mielőtt bármihez hozzányúlsz
Négy dolgot érdemes rögzíteni, ebben a sorrendben (a metrikák hivatalos definíciói a Google Core Web Vitals oldalán vannak):
- 1. Melyik oldalt méred. A főoldal és egy hosszú cikk teljesen máshogy viselkedik. Válassz három-négy reprezentatív oldalt, és mindig ugyanazokat mérd.
- 2. Lab vagy field adat. A Lighthouse szimulált körülmények között mér (lab). A Search Console Core Web Vitals riportja valódi látogatóktól jön (field). A kettő eltérhet, és mindkettő igaz. Döntés előtt nézd meg mindkettőt.
- 3. Három futás, medián. Egy futás félrevezet. Nálunk egy oldal ugyanazon a build-en hozott 100-at nulla blokkolási idővel és 98-at 139 ezredmásodperccel. Ez futásszórás, nem regresszió. Ha egy futásra reagálsz, olyat javítasz, ami nem romlott el.
- 4. A négy metrika külön. LCP (mikor jelenik meg a fő tartalom), CLS (mennyit ugrál a layout), TBT vagy INP (mennyire válaszol a lapod), TTFB (mennyit vár a szerverre). Ezek négy különböző probléma, négy különböző megoldással.
A PageSpeed pontszám félrevezet
Két konkrét csapda. Az egyik, hogy a pontszám egyetlen szám, ami négy metrikát présel össze, tehát elrejti, hogy pontosan mi romlott. A másik, hogy a mérés részletei számítanak: ha egy audit futtatásakor leszűkíted a kategóriákat, elveszítheted pont azt a diagnosztikát, ami megmondaná az okot. Velünk pontosan ez történt, mielőtt megtaláltuk a valódi hibát.
Használd a pontszámot arra, hogy észrevedd a bajt. Ne használd arra, hogy eldöntsd, mit javíts.
Egy valódi eset: a CLS, ami háromszor nem oda vezetett
A GEO útmutató cikkem három Lighthouse-futásból kettőn 0,179 CLS-t hozott, miközben az összes többi oldal 0,002 körül volt. Egy közvetlen böngészős mérés ugyanezen az oldalon tízből tízszer 0,0000-t adott. Tehát a hiba létezett, de csak a Lighthouse terhelési körülményei között jelent meg.
Első elmélet: a betűtípus méretezése. A címsorokhoz használt Fredoka tartalék-betűtípusának méretkorrekcióját korábban vegyes szövegmintán mértük, 101,8 százalékra. Kiderült, hogy megjelenítési méretben ez az 1,8 százalék elég ahhoz, hogy egy sortörés átbillenjen: a cikk h1-e Fredokával négy sor, a 101,8 százalékos tartalékkal öt. Ez 44 pixel elmozdulás. Végigmértem 69 valódi címsort 8 oldalon, 3 szélességben, és a helyes érték 100 százalék lett.
Javítottam. A cikk továbbra is 0,179-et hozott.
Második elmélet: valami más a fejlécben. Elkezdtem webfontonként letiltani a betűtípusokat, és minden elem magasságát és pozícióját megmérni.
A valódi ok: a morzsamenü. Bebas Neue betűtípussal készült, ami nem volt előtöltve. Amíg a Bebas meg nem érkezett, a négy elem két sorban fért el. Amikor megérkezett, egy sorba ugrottak, és az egész cikk, a címsor, a nyitókép és a szövegtörzs 29 pixellel feljebb csúszott.
A morzsamenü a fejléc testvéreleme, ezért nevezte a Lighthouse a cikkfejlécet elmozduló elemnek, miközben annak a magassága nem is változott. És ezért volt minden képkocka azonos a 375. ezredmásodperctől: az elmozdulás már véget ért, mielőtt az első képkockát rögzítették volna.
A javítás nem méretkorrekció volt, hanem szerkezeti: a morzsamenü soha nem tördel. Egy egysoros, vízszintesen görgethető sor magassága nem függhet a betűtípustól, tehát nincs mit elmozdítania.
A tanulság általánosítható, és megéri felírni: minden olyan elem a hajtás felett, aminek a magassága változhat betűtípus-cserekor, egy időzített CLS-hiba. A rövid, nagybetűs címkékből álló, tördelő sor a klasszikus alakzat. Jobb nem tördelni és túlcsordulni hagyni, mint kézzel hangolt tartalék-metrikában bízni.
Mit hoz a legtöbbet, sorrendben
| Beavatkozás | Tipikus hatás | Ráfordítás |
|---|---|---|
| Képformátum és méret (AVIF/WebP, kiírt szélesség és magasság) | nagy | kicsi |
| Betűtípus betöltés (előtöltés, tartalék-metrikák, nem tördelő elemek) | közepes, a CLS-re nagy | kicsi |
| Felesleges kliensoldali JavaScript eltávolítása | nagy | közepes |
| Edge cache és CDN | nagy a szerver válaszidőre | kicsi |
| Szerver és PHP hangolás | közepes | közepes |
| Újraépítés más architektúrával | a legnagyobb | nagy |
A sorrend nem véletlen. Az első négy sor együtt általában többet hoz, mint bármilyen szerveroldali hangolás, és sokkal olcsóbb. Ha valaki azzal kezdi, hogy nagyobb szervert ajánl, kérdezd meg, mit mért.
Mikor nem sebesség-probléma a sebesség-probléma
Van, amikor a hangolásra nem érdemes költeni, és ezt jobb kimondani, mint elszámlázni.
Ha az oldal minden látogatáskor tucatnyi adatbázis-lekérdezést futtat egy olyan tartalomért, ami havonta egyszer változik, akkor nem a lekérdezéseket kell gyorsítani, hanem nem kellene futtatni őket. A mi esetünkben ez volt a válasz: az oldal statikus generálásra váltott, és a szöveg egy része ettől egyszerűen visszatért a HTML-be, mert korábban csak JavaScript futtatása után került oda.
Ha a szűk keresztmetszet az architektúra, akkor a gyorsítótár csak elfedi. Ilyenkor az őszinte ajánlat az újraírás, nem egy sebességcsomag, még akkor is, ha az utóbbit könnyebb eladni.
Gyakori kérdések
Mennyibe kerül egy weboldal sebesség optimalizálás?
A magyar piacon a jellemző szolgáltatáscsomagok néhány tízezer forinttól százezres nagyságrendig terjednek, a méret és a rendszer függvényében. Az ár nagyjából annak a függvénye, hogy hány rendszert kell megérteni. Egy audit önmagában, javítás nélkül, mindig olcsóbb, és sokszor az az első helyes lépés.
Lassú a weboldalam, hol kezdjem?
Mérj három futást a fő oldalaidon, és nézd meg külön az LCP-t, a CLS-t és a blokkolási időt. A legtöbb esetben a képek és a felesleges JavaScript adja a hozam nagy részét. Bővítményt telepíteni utolsó lépés, nem első.
Elég egy gyorsítótár bővítmény?
Ideig-óráig javít a mérésen, de az okot nem szünteti meg. Ha az oldal alapból túl sok munkát végez minden látogatáskor, a gyorsítótár csak elrejti ezt, és az első olyan oldalon, amit nem tud cache-elni, visszatér a probléma.
Mi az a CLS, és miért rossz, ha magas?
A CLS azt méri, mennyit ugrál a tartalom betöltés közben. Ha rákattintanál egy gombra és közben elcsúszik, az CLS. Google rangsorolási tényező, de ennél fontosabb, hogy idegesítő. Szinte mindig betűtípus-betöltés vagy méret nélküli kép okozza.
Számít-e a sebesség az AI keresőkben?
Közvetlenül kevésbé, mint a Google-ben. Ami sokkal többet számít, hogy a tartalom benne van-e a kiszolgált HTML-ben JavaScript futtatása nélkül. Az AI-crawlerek egy része nem futtat JavaScriptet, tehát ami csak utána jelenik meg, az nekik nem létezik.
Garantálható a 100 pont?
Nem, és aki garantálja, az vagy egyetlen futást fog mutatni, vagy egy üres oldalt. A pontszám futásonként szór. Ami garantálható, az a metrikák javulása és az, hogy megmutatjuk, mitől.
Ha a te oldalad lassú és nem tudod, miért, írj nekünk, vagy nézd meg a webfejlesztési és üzemeltetési szolgáltatásainkat. Először mérünk, utána mondunk árat.
