Miért lassú a weboldalad, és hogyan gyorsítsd fel?

A számok nem hazudnak. A mobilon látogatók fele elhagyja az oldalt, ha 3 másodpercnél tovább tart a betöltés. Minden egyes plusz másodperc átlagosan 7%-kal csökkenti az esélyét, hogy egy látogatóból ügyfél lesz. A Google pedig 2021 júniusa óta hivatalosan is rangsorolási tényezőként kezeli a sebességet, a Core Web Vitals nevű mutatókon keresztül.

A lassú weboldal tehát nem esztétikai kérdés. Pénzbe kerül.

Ebben a cikkben megnézzük, mi lassítja valójában a weboldalakat, hogyan mérd helyesen a sebességet, mit tudsz te magad megjavítani, és mikor érdemes fejlesztőhöz fordulni.

Hogyan mérjük a sebességet?

A legelterjedtebb és ingyenesen elérhető eszköz a Google PageSpeed Insights. Csak beírod az oldalad URL-jét, és néhány másodpercen belül kapsz egy pontszámot, nullától százig. Két mérést is végez egyszerre: egyet mobilra, egyet asztali számítógépre. A két eredmény között általában komoly különbség van.

Az asztali mérés egy gyors gépet és gyors internetet feltételez. A mobilos mérés ezzel szemben szándékosan megnehezített körülmények között zajlik: a szimulált hálózat egy lassabb 4G kapcsolatot utánoz, ráadásul a processzor teljesítményét is visszafogja, hogy egy átlagos, pár éves telefont modellezzen. Ezért szinte mindig alacsonyabb pontszámot kapsz mobilon, mint desktopon, még ha az oldalad egyébként rendben is van.

A mobilos mérés az összetettebb, és ez az, amire érdemes figyelni. Ma már a legtöbb weboldal forgalmának nagyobb fele mobilról érkezik, a Google is mobilon indexeli az oldalakat.

A PageSpeed eredményoldalán néhány mérőszám is megjelenik, ezek közül a legfontosabbak:

FCP (First Contentful Paint)

Azt méri, mikor jelent meg az oldalon az első bármilyen tartalom, akár csak egy szöveg vagy egy ikon. Az LCP-től abban különbözik, hogy nem a legnagyobb elemet keresi, hanem az első jelet arról, hogy az oldal egyáltalán elindult.

LCP (Largest Contentful Paint)

Azt méri, mikor jelent meg az oldal legnagyobb látható eleme a képernyőn. Ez általában egy nagy kép, egy szalagcím vagy egy cím. Az LCP az az érzés, amikor azt mondod: „rendben, betöltött az oldal." Ha ez lassan történik, a látogató azt érzi, hogy vár.

CLS (Cumulative Layout Shift)

Az ugráló tartalmak mutatója. Ismered azt az érzést, amikor olvasol valamit, és hirtelen az egész szöveg lejjebb ugrik, mert betöltött egy kép felette? Vagy megnyomtál egy gombot, de az elmozdult, és valami mást tapogattál meg? A CLS ezt méri.

Ha nálad ez a mutató piros, itt találod a konkrét okokat és megoldásokat: CLS javítás: hogyan szüntesd meg az ugráló tartalmat

TTFB (Time to First Byte)

A szerver válaszideje. Azt mutatja meg, mennyi ideig tartott, mire a szerver egyáltalán elkezdett adatot küldeni a böngészőnek. Ha ez magas, általában a tárhellyel vagy a szerver konfigurációjával van valami gond.

TBT (Total Blocking Time)

Azt méri, mennyi ideig volt „lefoglalva" a böngésző azzal, hogy JavaScriptet futtat, és ezalatt mennyi ideig nem tudott volna reagálni rád, ha kattintasz. Ez tehát nem a letöltésről szól, hanem arról, mennyit dolgozik a készülék processzora a betöltés alatt.

Ne keverd össze a TTFB-t és a TBT-t. A két rövidítés hasonlít, a jelentésük viszont ellentétes oldalon van: a TTFB a szerveré, a TBT a látogató készülékéé. Ha a TTFB magas, a tárhelyet nézd. Ha a TBT magas, a JavaScriptet. Ezért is zavaró, hogy a PageSpeed mérőszám-paneljén a TBT szerepel, a TTFB pedig nem: azt lejjebb, a diagnosztikai listában találod „Szerver válaszideje" néven.

INP (Interaction to Next Paint)

Az oldal reagálóképességét méri. Ha rákattintasz valamire, mennyire gyorsan reagál? Ha lassú, az oldal „elakad" érzést kelt.

CrUX (Chrome User Experience Report)

A PageSpeed mellett a Google egy másik adatforrást is használ, amit CrUX-nak hívnak (Chrome User Experience Report). Ez nem szimulált mérés, hanem valódi látogatók tapasztalataiból gyűjtött adat: a Chrome böngésző névtelenül rögzíti, hogy a valódi felhasználók számára mennyire gyorsan töltött be az oldal. Ha az oldaladnak elég nagy a forgalma, ezek az adatok is megjelenhetnek a PageSpeed eredményoldalán, és általában kedvezőbbek a laboradatnál, mert a legtöbb látogató gyorsabb hálózaton és modernebb eszközön érkezik, mint amit a szimulált mérés feltételez.

Ugyanez az adat jelenik meg a Google Search Console Webes alapmutatók menüpontjában is. Itt viszont van egy fontos feltétel: a jelentés csak akkor mutat bármit, ha az oldalad elér egy bizonyos látogatószámot. A Google nem közli a pontos küszöböt, de egy friss vagy kis forgalmú oldalnál ez a menüpont jellemzően üres marad, vagy azt írja, hogy nincs elegendő adat.

Ez nem hiba, és nem is jelent rosszat az oldaladról. Egyszerűen még nincs mögötte elég valódi látogató ahhoz, hogy a Google statisztikát tudjon csinálni belőle. Amíg ide nem jutsz el, marad a PageSpeed laborszáma, csak tudd róla, hogy az mennyire ingadozik.

Mit jelent a pontszám? A zöld, sárga és piros határok

A PageSpeed nem csak egy végső pontszámot mutat, hanem az egyes mérőszámokat külön is értékeli: zöldre, sárgára vagy pirosra színezi őket. Ez segít megérteni, hogy pontosan mi az, ami rendben van, és mi az, amin érdemes javítani. A határértékek a Google Web Vitals kezdeményezésével összhangban vannak meghatározva.

Forrás: Google PageSpeed Insights dokumentáció

Mi a leggyakoribb ok, ami lassíthatja a weboldalad?

Képek: a legtöbb oldalon itt a legnagyobb tartalék

Ha egyetlen dolgot tehetsz a weboldalad gyorsításáért, az a képek rendbe tétele. A tipikus hibák: rossz formátum (PNG/JPEG helyett ma már WebP vagy AVIF kellene), feleslegesen nagy méret, és az, hogy minden kép egyszerre töltődik be, még azok is, amiket a látogató esetleg soha nem görget el. A PageSpeed-en az LCP mutató jelzi leginkább, ha képpel van a gond, mivel az oldal legnagyobb látható eleme legtöbbször egy kép.

A részletes magyarázatot és a konkrét megoldásokat a kapcsolódó cikkben találod: Oldalsebesség LCP javítás

Lassú szerver: mikor a TTFB a hibás

A TTFB (Time to First Byte) azt méri, mennyi ideig tart, mire a szerver az első adatot elküldi. Ha ez magas, minden más is késik, a legjobb képoptimalizálás sem segít, ha a szerver egyáltalán nem válaszol gyorsan. Az okozó lehet a tárhely minősége, a szerver fizikai helye, a PHP-konfiguráció, vagy az, hogy az oldal minden egyes betöltésnél újra legenerálja magát, ahelyett hogy gyorsítótárból szolgálná ki.

Render-blokkoló CSS és JavaScript

Ha az oldal fejlécében nagy CSS vagy JavaScript fájlok vannak, a böngésző nem tud semmit sem megjeleníteni, amíg ezeket teljesen le nem töltötte és fel nem dolgozta. A látogató addig üres képernyőt lát. A PageSpeed „Eliminate render-blocking resources" figyelmeztetése pontosan ezt jelzi, és mind az FCP, mind az LCP értékét rontja.

Felesleges JavaScript: amit letöltesz, de nem használsz

A render-blokkolás csak az egyik fele a JavaScript-problémának. A másik az, hogy a böngészőnek le kell töltenie, értelmeznie és lefuttatnia minden kódot, amit az oldal betesz, akkor is, ha a látogató soha nem használja. Egy animációs könyvtár, ami csak a főoldal egyetlen effektjéhez kell, ugyanúgy megérkezik az aloldalakra is, ha nincs szétbontva.

Itt egy gyakori félreértést érdemes tisztázni. Sokan azt hiszik, hogy a JavaScript azért lassít, mert „megterheli a telefont". A saját oldalam auditjánál megnéztem a processzor-profilt betöltés közben: a gép az idő 92 százalékában tétlen volt, a leghosszabb összefüggő feladat 123 ezredmásodpercig tartott. Vagyis nem a számolás vitte az időt, hanem a várakozás arra, hogy a fájlok megérkezzenek a hálózaton.

Ez a különbség azért fontos, mert más a megoldás. Ha a probléma a letöltés, akkor nem gyorsabb kódot kell írni, hanem kevesebbet kell küldeni: a ritkán használt részeket külön darabba kell tenni, és csak akkor betölteni, amikor tényleg kellenek.

CSS háttérkép: a rejtett LCP-gyilkos

Ez az a hiba, amit a legnehezebb észrevenni, mert ránézésre minden rendben van. Ha az oldal főképe nem <img> elemként van beillesztve, hanem CSS háttérképként, a böngésző sokkal később tud róla.

A böngésző ugyanis a HTML-t olvasva azonnal látja a képeket, és el is kezdi tölteni őket. A CSS háttérképet viszont csak akkor fedezi fel, amikor már letöltötte és feldolgozta a teljes stíluslapot, kiszámolta, hogy az adott elem egyáltalán megjelenik-e, és csak ezután indítja a letöltést, ráadásul alacsony prioritással. Ha pont ez a kép a legnagyobb látható elem, akkor az LCP mutatód romlik anélkül, hogy a képpel bármi baj lenne.

Két dolgot érdemes tenni. Az egyik, hogy a fő látványelemet valódi <img> elemként tedd be, és jelöld meg fontosként. A másik, hogy a képet modern formátumra konvertáld. A saját oldalamon a háttérképek AVIF-re váltása után az egyik 81 kilobájtról 46-ra fogyott, ami 43 százalékos csökkenés, a másik 58,5-ről 41-re. Ugyanaz a kép, ugyanaz a látvány, feleannyi adat.

Webfontok: amikor a betűtípus lassít

Ha az oldal egyedi betűtípust tölt be és az nincs megfelelően konfigurálva, a böngésző megvárja a font betöltését, mielőtt a szöveget megjelenítené. A látogató ideig-óráig üres szövegmezőket lát. A font-display: swap és a font preload segít ezen, de a betűvastagságok számát is érdemes minimalizálni.

Mobil és asztali: ugyanaz az oldal, két teljesen más szám

Mielőtt bármit kezdenél a pontszámoddal, tudnod kell, hogy a PageSpeed nem egyetlen mérést végez, hanem kettőt. A két eredmény között óriási a különbség, és ezt a legjobban két képpel tudom megmutatni. Mindkettő a saját oldalamról készült, ugyanabban a percben. Először a mobil:

Ezt a mérést a Google egy emulált Moto G Power telefonon futtatta, lassított 4G kapcsolattal. Ez egy szándékosan rossz forgatókönyv: gyenge készülék, gyenge hálózat. Most nézd meg ugyanezt az oldalt asztali beállítással:

Csaknem hétszeres különbség ugyanarra az oldalra, azonos időpontban. Egyetlen dolog változott a két mérés között: a tesztprofil. Az asztali futásnál a PageSpeed nem gyenge telefont és lassú mobilnetet szimulál, hanem asztali gépet és normál kapcsolatot. Itt sincs teljesen kikapcsolva a korlátozás, csak sokkal enyhébb, és a processzort nem fogja vissza.

Ezért ha valaki azt mondja neked, hogy „az oldalam 100 pontos", az önmagában még nem mond semmit. Az első kérdés mindig az, hogy melyik méréssel. És mivel a Google a rangsorolásnál a mobil élményt nézi, a mobil szám az, ami tényleg számít, akkor is, ha az fáj jobban.

A mobil szám viszont nem ítélet. Egy tudatosan rossz esetet modellez, tehát azt mutatja meg, mit tapasztal a legrosszabbul járó látogatód, és hol van a legnagyobb tartalékod. Nem azt, amit a látogatóid többsége lát: a magyar mobilhálózatok átlagos sebessége a többszöröse annak, amit a teszt szimulál.

És akkor még ugrál is

Van egy második csapda is. Ha ugyanazt az oldalt ugyanazzal a beállítással méred le kétszer egymás után, jó eséllyel két különböző számot kapsz. A laborérték egyetlen futás eredménye, egy megosztott szerverparkban, változó terhelés mellett, mesterségesen lassított hálózaton. Ennyi mozgó alkatrész mellett a szórás nem hiba, hanem a módszer beépített tulajdonsága.

Egy korábbi mérési sorozatnál ugyanezt az oldalt tizenegy perc alatt háromszor futtattam le, úgy, hogy nem módosítottam a kódon. Ezt kaptam:

Hat pont különbség, egy teljes másodperc az LCP-ben, és a Total Blocking Time nullától ötven ezredmásodpercig szórt. Ugyanaz az oldal, ugyanaz a beállítás, tizenegy perc. Egyedül a CLS maradt mozdulatlan, mert az nem a hálózaton és nem a processzor pillanatnyi terhelésén múlik, hanem azon, hogy be vannak-e méretezve az elemeid.

Ugyanezen idő alatt az asztali mérés minden futáson pontosan 100 pontot adott, tizedmásodpercen belüli LCP-eltéréssel. Vagyis a szórás szinte teljes egészében a fojtott mobil profilban keletkezik: ott, ahol a Google mesterségesen visszafogja a processzort, sokkal jobban számít, hogy a mérés pillanatában mennyire volt terhelt a gép, ami futtatta.

A helyes hozzáállás tehát ez: a PageSpeed egy iránytű, nem egy bizonyítvány. Arra való, hogy megmutassa, hol keresd a hibát, és hogy a javítás után lássad, jó irányba mentél-e. Arra viszont nem, hogy egyetlen szám alapján eldöntsd, jó vagy rossz az oldalad.

A böngésződben is tudsz mérni

Ha a PageSpeednél mélyebbre akarsz nézni, nem kell hozzá semmit telepítened. A Chrome beépített fejlesztői eszközeiben (F12) van egy Lighthouse fül, ami ugyanazt a mérést futtatja le, csak a saját gépeden, és egy Teljesítmény (Performance) fül, ami ennél jóval többet mutat: ezredmásodperc pontossággal látod, mikor mi töltődött be, mivel foglalkozott a processzor, és pontosan melyik elem lett az LCP.

Egy dolgot viszont fontos tudni róla. A böngészőben futtatott Lighthouse ugyanarra az oldalra más számot ad, mint a PageSpeed, és jellemzően szebbet. Ennek az az oka, hogy a helyi mérés a lassítást a te géped teljesítményéhez képest alkalmazza. Ha erős gépen dolgozol, szebb számot kapsz, mint amit egy valódi telefon produkálna. Ezért a böngészős mérés arra jó, hogy megtaláld a szűk keresztmetszetet, nem arra, hogy a pontszámát komolyan vedd.

Ez már fejlesztői terep, és megérdemel egy külön cikket, úgyhogy most csak annyit jegyezz meg, hogy létezik, és hogy ingyen ott van a böngésződben. Két dolgot érdemes tudni róla: mérj privát ablakban, mert a bővítményeid meghamisítják az eredményt, és kapcsold be a lassítást (hálózat és processzor), különben a saját gépeden minden gyorsnak fog látszani.

Így mérj helyesen

Összefoglalva, három lépés, néhány perc:

Futtasd le a PageSpeedet három-ötször, és a középső értéket nézd, ne a legjobbat és ne a legrosszabbat.

Nézd meg a valódi adatot is. A Google Search Console Webes alapmutatók menüpontja nem szimulált mérést mutat, hanem azt, hogy a te tényleges látogatóid mit tapasztaltak, valódi telefonokon, valódi hálózaton. Ez a mérvadó adat. Ha itt zöld vagy, de a PageSpeed pirosat mutat, akkor a látogatóid szempontjából rendben van az oldalad.

Harmadszor a mutatókat nézd, ne az összesített pontszámot. A nulla és száz közötti szám egy súlyozott átlag, ami keveri az összes mérőszámot, és pont azt rejti el, amit tudnod kell. Ha az LCP a rossz, a képekkel vagy a szerverrel van dolgod. Ha a CLS, akkor az elrendezés ugrál. Ha az INP, akkor a JavaScript nem enged reagálni. Három különböző probléma, három különböző megoldás, egyetlen közös pontszám mögé rejtve.

Mit tudsz megjavítani magad, és mihez kell fejlesztő?

Nem mindenhez kell szakember, és ezt őszintén megmondom, még ha a saját üzletem ellen szól is. Van néhány dolog, amit egy délután alatt magad is elintézel, és ezek adják a javulás nagyobbik felét.

Amit magad is meg tudsz csinálni

Rakd rendbe a képeket. Ez a legnagyobb tartalék a legtöbb oldalon. Töltsd le a legnagyobb képeidet, konvertáld őket WebP vagy AVIF formátumra, és töltsd vissza őket. Erre a Squoosh-t ajánlom: a Google saját fejlesztése, tehát megbízható forrás, teljesen ingyenes, és nem kell hozzá semmit telepítened, közvetlenül a böngészőben fut. Ráadásul a képeid fel sem töltődnek sehova, a konvertálás a saját gépeden történik. Ha egy 3 megabájtos fényképet cserélsz le egy 200 kilobájtosra, azt a látogatóid azonnal érezni fogják.

Nézd meg, mennyi bővítményed van. WordPressnél gyűlnek a pluginek, és sok közülük minden oldalon betölti a saját CSS és JavaScript fájljait, akkor is, ha csak egyetlen aloldalon használod. Ami fél éve nem kellett, azt kapcsold ki, majd mérj újra.

Kapcsolj be egy cache bővítményt. Ez a leggyorsabb egyetlen javítás, amit WordPressen tehetsz. Erről mindjárt részletesen is írok.

Amihez fejlesztő kell

A kritikus CSS kiemelése, a JavaScript darabolása, az automatikus AVIF képfeldolgozás, a szerver konfigurációja és a CDN beállítása már olyan beavatkozások, ahol egy elrontott lépés eltörheti az oldal megjelenését. Ezekhez hozzáférés kell a kódhoz és a szerverhez, és kell valaki, aki vissza tudja csinálni, ha valami félremegy.

WordPress és a csodapluginok: segít a WP Rocket?

Ez a leggyakoribb kérdés, amit kapok, úgyhogy tisztességesen válaszolok rá. Igen, segítenek, és nem, nem oldják meg a valódi problémát.

Nézzük meg, mit csinálnak valójában. Egy optimalizáló bővítmény, legyen az WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache vagy Autoptimize, nagyjából ugyanazt a néhány dolgot végzi: eltárolja az elkészült oldalt, hogy ne kelljen minden látogatónál újragenerálni, összevonja és tömöríti a CSS meg JavaScript fájlokat, késlelteti a képek betöltését, beállítja a böngésző gyorsítótár fejléceit, és rendet rak az adatbázisban.

Ezek mind valódi és hasznos dolgok. Az oldal-cache önmagában látványosan javítja a szerver válaszidejét, és ez a legtöbb WordPress oldalon érezhető gyorsulás. Ha nincs ilyened, kapcsolj be egyet, megéri.

A határ ott van, ahol a bővítmény már nem tud mit kezdeni a helyzettel. Egy cache plugin nem teszi kisebbé a 3 megabájtos képedet. Nem távolítja el azt a tizenöt bővítményt, amiből tizenkettőt nem használsz. Nem gyorsítja fel a túlterhelt, olcsó tárhelyet. És nem tudja meg nem történtté tenni, hogy az oldalépítő tizenkét egymásba ágyazott dobozból rakta össze azt, ami három is lehetne.

Ezekben az esetekben a bővítmény elfedi a tünetet. A pontszám javul valamennyit, a látogató pedig továbbra is vár. Nem a plugin a hibás, egyszerűen nem erre való.

A helyes sorrend tehát: előbb az alap, utána a bővítmény. Rakd rendbe a képeket, dobd ki, amit nem használsz, nézd meg a tárhelyet, és csak ezután tegyél rá optimalizálót. Fordított sorrendben egy lassú oldalra teszel egy réteg festéket.

Összefoglalva

A lassú weboldalak túlnyomó többségénél ugyanaz a néhány ok tér vissza: túl nagy képek, felesleges kód, lassú szerver, és rosszul betöltött betűtípusok. A jó hír, hogy ezek közül a legnagyobb tétel, a képek rendbetétele, szakember nélkül is megoldható.

Mérj helyesen, több futásból, és nézd meg a Search Console valódi adatait is. Az összesített pontszám helyett a mutatókat figyeld, mert azok mondják meg, hol keresd a hibát. És ne várd egyetlen bővítménytől, hogy megoldja azt, ami szerkezeti probléma.

Nem tudod, mi lassítja az oldaladat?

Küldd el az oldalad címét, megnézem, és őszintén megmondom, mit találtam. Nem egy automatikus PageSpeed jelentést fogsz visszakapni, azt magad is le tudod futtatni. Azt írom meg, hogy a te oldaladon konkrétan mi viszi az időt, mit érdemes elsőként javítani, és hogy szükséged van-e egyáltalán fejlesztőre hozzá.

Ha kiderül, hogy magad is meg tudod oldani, azt is meg fogom mondani.