A látogató nem stopperrel a kezében ül a gép előtt, de nagyon pontosan érzi, ha egy oldal döcög. Ha megnyitja a mobilján, és három-négy másodperc múlva még mindig szürke dobozokat lát a képek helyén, a legtöbben visszalépnek. A gond az, hogy a "lassú a weboldalam" mondat önmagában nem diagnózis, hanem tünet. Az esetek túlnyomó részében négy dolog valamelyike (vagy több egyszerre) áll mögötte: a képek, a szkriptek, a tárhely és a sablon.
Az alábbiakban végigmegyünk mind a négyen, megnézzük, hogyan méred meg magad ingyenes eszközökkel, és mi legyen a javítási sorrend. A sorrend fontosabb, mint hinnéd: rossz sorrendben napokat el lehet dolgozni gyakorlatilag nulla eredménnyel.
Mit jelent pontosan az, hogy lassú a weboldal?
Az, hogy egy oldal "lassú", három különböző dolgot jelenthet: sokáig tart, amíg a szerver válaszol, sokáig tart, amíg a fő tartalom megjelenik, vagy az oldal későn reagál a kattintásra. Ezek külön mérőszámok, és külön okuk is van.
Hivatalos információ: a Google Core Web Vitals mérőszámai szerint az LCP (a legnagyobb látható tartalmi elem betöltése) akkor jó, ha 2,5 másodperc alatt marad, az INP (az interakcióra adott válaszidő) akkor, ha 200 ezredmásodperc alatt, a CLS (a látható elmozdulás) pedig akkor, ha 0,1 alatt van. Ehhez jön még a TTFB (az első bájtig eltelt idő), amire a Google jó irányértékként 800 ezredmásodpercet szokott említeni.
Miért számít ez? Mert ha a TTFB 1,5 másodperc, akkor hiába tömöríted a képeket: a látogató másfél másodpercig akkor is a semmit nézi. Ha viszont a TTFB 200 ms, de az LCP 5 másodperc, akkor a szerverrel nincs baj, a betöltendő tartalom a nehéz. Szakmai tapasztalat: a legtöbb elakadt sebesség-optimalizálás azért fut zátonyra, mert valaki a rossz számot javítja.
Miért lassítanak a képek, és mit lehet velük kezdeni?
A képek azért a leggyakoribb ok, mert egy modern fényképezőgépből vagy telefonból jövő kép 3-6 MB, a weboldalnak viszont 100-300 kB is elég lenne ugyanabban a méretben. Ez a különbség egyetlen képen több másodperc mobilneten.
A tipikus hibák, amikkel a gyakorlatban a leggyakrabban találkozni:
- A kép eredeti, 4000 pixel széles felbontásban van feltöltve, és a böngésző zsugorítja 600 pixelre. A letöltés akkor is a teljes fájlt jelenti.
- Régi formátum: JPEG vagy PNG ott, ahol a WebP vagy az AVIF ugyanazt a látványt fele-harmad akkora fájlból hozza.
- Hiányzó
widthésheightattribútum, ezért az oldal ugrál betöltés közben (ez a CLS-t rontja). - Minden kép lusta betöltésű, beleértve a legfelső, azonnal látható képet is. Ez pont az LCP-t lassítja.
Egy jól felépített képelem nagyjából így néz ki:
<img src="nyilaszaro-1200.avif" srcset="nyilaszaro-800.avif 800w, nyilaszaro-1200.avif 1200w" sizes="(max-width: 768px) 100vw, 1200px" width="1200" height="800" alt="Beépített műanyag nyílászáró" fetchpriority="high" decoding="async">
A lap alján lévő, görgetés után látható képeknél viszont a loading="lazy" a helyes választás, a fetchpriority="high" pedig maradjon az egyetlen LCP-képen. WordPress alatt egy jó képoptimalizáló bővítmény ezt nagyrészt automatikusan megcsinálja, de a feltöltött eredeti méretet neked kell kordában tartani.
Mennyit lassítanak a szkriptek és a bővítmények?
A szkriptek nem a méretük miatt drágák, hanem azért, mert a böngészőnek le kell futtatnia őket, és ez az idő a telefon processzorán sokszorosa a laptopon mértnek. Egy 100 kB-os JavaScript sokkal nagyobb kárt okoz, mint egy 100 kB-os kép.
Nézd meg őszintén, mi fut az oldaladon: analitika, hirdetési pixel, hőtérkép, chat-ablak, sütikezelő, betűtípus-betöltő, űrlapkezelő, csúszka, animációs könyvtár. Egy átlagos magyar kkv-honlapon ebből tíz-tizenöt darab is elindul. Saját tapasztalat: gyakran kiderül, hogy két különböző analitika méri ugyanazt, vagy egy hirdetési pixel évek óta ott van egy kampányból, ami rég véget ért.
Amit érdemes végigcsinálni:
- Írd össze, melyik külső szkript milyen üzleti célt szolgál. Amelyik mellé nem tudsz célt írni, az mehet.
- A megmaradókat töltsd be
defervagyasyncattribútummal, hogy ne blokkolják az oldal megjelenítését. - A chat-ablakot és a hasonló, nem kritikus elemeket indítsd később (első görgetésre vagy kattintásra), ne a betöltéssel egyszerre.
- WordPress alatt nézd meg, hány bővítmény tölt be CSS-t és JS-t olyan oldalakon is, ahol nem is használják (tipikusan az űrlap- és a csúszka-bővítmények).
Szakmai feltételezés, nem mérési tény: az esetek jelentős részében a bővítmények felének eltávolítása vagy feltételes betöltése önmagában nagyobb javulást hoz, mint bármilyen gyorsítótár-beállítás.
Mikor a tárhely a hibás, és hogyan derül ez ki?
A tárhelyre akkor gyanakodj, ha a TTFB tartósan magas, vagyis a szerver már azelőtt lassú, hogy egyetlen kép vagy szkript szóba került volna. Ez a legkönnyebben azonosítható, mégis a legritkábban javított ok.
Tipikus jelek: az oldal éjszaka gyors, munkaidőben lassú; az adminfelület is döcög, nemcsak a nyilvános oldal; a szerver néha időtúllépéssel válaszol. Az olcsó, erősen zsúfolt osztott tárhelyeken a szomszédos oldalak terhelése rád is kihat, és ezen semmilyen képoptimalizálás nem segít.
Mit tudsz tenni:
- Kapcsolj be szerveroldali oldal-gyorsítótárat (page cache). Dinamikus oldalnál ez a legnagyobb egyszeri nyereség.
- Ellenőrizd a PHP-verziót. Egy elavult verzió érezhetően lassabb, és biztonsági szempontból is problémás.
- Nézd meg az adatbázist: felduzzadt bejegyzés-változatok, régi átmeneti adatok, indexeletlen táblák mind lassítanak.
- Állíts be értelmes fejléceket a statikus fájlokra, például
Cache-Control: public, max-age=31536000, immutable. - Ha a látogatóid földrajzilag szórtak, egy CDN sokat segíthet, de ha a látogatóid többsége Budapesten és környékén van, egy magyar szerver közelsége már eleve jó kiindulás.
Ha ezek után is 800 ms fölött a TTFB, a tárhely önmagában a szűk keresztmetszet, és a szolgáltatóváltás vagy a csomagváltás reálisabb út, mint a további finomhangolás.
Hogyan lassít a sablon és a szerkesztő?
A sablon azért lassít, mert olyan kódot is betölt, amit az adott oldalon nem használsz, a vizuális szerkesztők pedig sok egymásba ágyazott elemet generálnak ugyanannak a látványnak az eléréséhez.
Egy multifunkciós, "mindent tudó" sablon jellemzően több száz kilobyte CSS-t és JS-t hoz magával, mert fel van készítve étteremre, webshopra és portfólióra is. Ha ehhez hozzáadsz egy page buildert, majd egy második buildert egyetlen szekció kedvéért, a felesleg összeadódik. Saját tapasztalat: sok oldalon egy egyszerű szolgáltatás-aloldal HTML-je háromszor akkora, mint amekkora a tartalom indokolná, és ez a többlet tisztán szerkesztői burkolóelem.
Ez nem azt jelenti, hogy dobd ki a builderedet. Reálisabb lépések: kapcsold ki a nem használt sablonmodulokat, ne ágyazz egymásba feleslegesen szekciókat és oszlopokat, cseréld le a nehéz animációs könyvtárakat sima CSS-átmenetekre, és a betűtípusokból tölts be kevesebb vágást (általában két vastagság bőven elég). Ha újratervezés előtt állsz, a sablonválasztásnál a demó PageSpeed-eredménye legalább annyira számítson, mint a látvány.
Hogyan mérd meg magad, lépésről lépésre?
A méréshez nem kell fizetős eszköz. Négy ingyenes forrásból összeáll a teljes kép, és fél óra alatt megvan.
- PageSpeed Insights. Add meg az oldal címét, és mindig a mobil fület nézd először. A felső blokk a valós felhasználói adat (ha van elég forgalom), az alsó a laborteszt. Jegyezd fel az LCP, INP, CLS és TTFB értékeket.
- Search Console, Core Web Vitals jelentés. Ez mutatja meg, hogy a probléma egyetlen oldalt érint, vagy egy egész oldaltípust (például az összes terméklapot). Ez utóbbi a fontos, mert sablonszintű hibára utal.
- Chrome DevTools, Network fül. Nyisd meg az oldalt, kapcsold be a lassított hálózatot (4G) és a processzor-lassítást, majd töltsd újra. Rendezd méret szerint: rögtön látod a legnagyobb fájlokat. A Performance fülön a hosszú, sárga sávok a JavaScript futásideje.
- WebPageTest. A vízesés-diagramon látszik, mi mire vár. Ha az első nagy kép csak a nyolcadik kérésként indul el, akkor sorrendi probléma van, nem méretbeli.
Egy dolgot tarts be: mérj ugyanabban a helyzetben újra minden változtatás után, egyesével. Ha egyszerre cserélsz képformátumot, kapcsolsz be cache-t és törölsz bővítményeket, sosem tudod meg, melyik hatott, és ha romlik valami, nem tudod visszakeresni.
Mit javíts elsőként?
A sorrend: először a szerveridő, aztán az LCP-kép, aztán a megjelenítést blokkoló szkriptek, végül a sablon. Mindig azt javítsd, ami a legtöbb ezredmásodpercet adja vissza a legkevesebb kockázattal.
- 1. TTFB 800 ms fölött? Oldal-gyorsítótár, PHP-verzió, adatbázis-takarítás. Ezek után mérj újra.
- 2. Melyik elem az LCP? A PageSpeed Insights megmondja. Ha kép, akkor azt az egyet optimalizáld először: méret, formátum, prioritás, semmiképp ne legyen lusta betöltésű.
- 3. Blokkoló szkriptek. Nem használt bővítmények törlése, a maradék
defer-rel, a nem kritikus elemek késleltetve. - 4. Elmozduló elrendezés. Adj méretet a képeknek, videóknak, hirdetési helyeknek, és kerüld a későn beugró bannereket.
- 5. Sablon és betűtípusok. Nem használt modulok kikapcsolása, kevesebb betűvágás, egyszerűbb szerkezet.
Ez a lista nem garantál konkrét eredményt, mert minden oldal más felépítésű, de a tapasztalat szerint ebben a sorrendben halad a leggyorsabban a javulás.
Számít a sebesség az AI-válaszmotoroknál is?
Valószínűleg igen, de más módon, mint a klasszikus keresésnél. A sebesség nem rangsorolási varázsszó, viszont ami nem tölt be időben, azt nehezebb feldolgozni.
Hivatalos információ: a Google dokumentációja szerint az oldalélmény jelzés része a rangsorolásnak, de nem írja felül a tartalom minőségét. Szakmai feltételezés: az AI-asszisztensek és a válaszmotorok, amelyek élőben látogatnak meg oldalakat, jellemzően szűk időkerettel dolgoznak, és sok esetben a JavaScripttel utólag betöltött tartalmat nem várják meg. Ebből az következik, hogy ha a lényegi mondandód csak szkriptfuttatás után jelenik meg, könnyen kimaradhat az idézhető anyagból. Ez inkább a szerveroldali megjelenítés melletti érv, mint a puszta másodpercekre való hajszáé.
Források és további olvasnivalók
- Google Search Central: Core Web Vitals és az oldalélmény dokumentációja
- web.dev: LCP, INP és CLS mérőszámok leírása és optimalizálási útmutatói
- Google PageSpeed Insights és a Chrome User Experience Report (CrUX) dokumentációja
- Google Search Console súgó: Core Web Vitals jelentés
- MDN Web Docs: reszponzív képek, loading, fetchpriority, script defer és async
- W3C: Web Performance munkacsoport specifikációi
- WebPageTest dokumentáció
- A "lassú" önmagában nem diagnózis: előbb bontsd szét szerveridőre (TTFB), fő tartalom betöltésére (LCP) és reagálásra (INP).
- A képek a leggyakoribb bűnösök, mert a méretük nagy, de a javításuk a legolcsóbb: formátum, méretezés, width/height, lazy loading.
- A szkriptek nem letöltési méretben, hanem futásidőben drágák, ezért a mobilon mért INP romlik tőlük a leglátványosabban.
- A tárhely hibáját a magas TTFB árulja el; ha ez 800 ms fölött van, hiába optimalizálod a képeket.
- Egy javításba kezdj, mérd újra, csak utána jöjjön a következő, különben nem tudod, mi hatott.
Gyakori kérdések
Mennyi idő alatt kell betöltenie egy weboldalnak?
Nincs egyetlen hivatalos határérték, de jó viszonyítási pont a Google Core Web Vitals ajánlása: az LCP maradjon 2,5 másodperc alatt, az INP 200 ezredmásodperc alatt, a CLS pedig 0,1 alatt, mindezt mobilon mérve. A szerver válaszidejére (TTFB) 800 ezredmásodperc alatti érték a kívánatos.
Miért gyors az oldalam a saját gépemen, ha a teszt lassúnak mutatja?
Mert te jellemzően gyors vezetékes neten, erős gépről, és már gyorsítótárazott tartalommal nyitod meg. A tesztek mobil hálózatot és gyengébb telefont szimulálnak, ami sokkal közelebb áll a valósághoz. Ezért érdemes a böngésző fejlesztői eszközeiben bekapcsolni a hálózat- és processzor-lassítást, és privát ablakban tesztelni.
A képek tömörítése önmagában elég szokott lenni?
Csak akkor, ha a szerver válaszideje rendben van. Ha a TTFB magas, a képek javítása alig érzékelhető javulást hoz, mert a látogató a szerverre vár. Ezért a mérés sorrendje mindig az, hogy előbb a szerveridőt nézed meg, és csak utána a betöltött tartalmat.
Segít, ha felteszek egy gyorsító bővítményt?
Segíthet, főleg az oldal-gyorsítótárral, de nem old meg strukturális problémát. Ha tíz felesleges külső szkript fut és nyers méretben feltöltött képeid vannak, a gyorsító bővítmény csak elfedi a hibát. Emellett több gyorsító bővítmény egyszerre gyakran ütközik egymással, ezért egyszerre csak egyet használj.
Honnan tudom, hogy a tárhelyet kell váltanom?
Ha bekapcsolt gyorsítótár, friss PHP-verzió és megtisztított adatbázis mellett is tartósan 800 ezredmásodperc fölött marad a TTFB, és az adminfelület is lassú, akkor jó eséllyel a szerver a szűk keresztmetszet. Ilyenkor érdemes a szolgáltatóval egyeztetni a terhelésről, mielőtt költözésbe kezdesz.
Rontja a sebesség a Google-helyezésemet?
A Google hivatalos álláspontja szerint az oldalélmény jelzés része a rangsorolásnak, de nem írja felül a tartalom relevanciáját és minőségét. Vagyis a gyorsítás önmagában nem garantál jobb helyezést, viszont a lassú oldal mérhetően több látogatót veszít el még azelőtt, hogy elolvasnák a tartalmat.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.