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.
Tovább a témában: Weboldal gyorsítás Sopron · Hogyan növeljem a weboldalam forgalmát? Csatornánként
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 ígér 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áé.
Miért lassú a weboldalam, és ki tudja megjavítani?
Azt, hogy ki tudja megjavítani a lassú weboldalt, a lassúság oka dönti el. A túl nagy képeket sokszor te magad is rendbe teszed, a magas szerver-válaszidőt a tárhelyszolgáltató vagy egy rendszergazda javítja, a szkriptek és a sablon gondjait pedig egy weboldal-fejlesztő. Ezért előbb mérj, és csak utána keress embert, mert a mérésből derül ki, kihez érdemes fordulni.
A gyakori hiba az, hogy valaki a lassúság hallatán rögtön tárhelyet vált, vagy fejlesztőt fogad, miközben a gond egyetlen 5 MB-os nyitókép. Fordítva is előfordul: hetekig tömörítik a képeket, miközben a szerver másfél másodperc alatt válaszol. Az előző szakaszok mérési lépései pont azt adják meg, melyik csoportba tartozik a te oldalad.
Mit javíthatsz meg magad?
- A képeket feltöltés előtt méretezd le a valós megjelenési méretre, és tegyél fel egy képoptimalizáló bővítményt, ami WebP vagy AVIF formátumot készít.
- Töröld a rég lejárt kampányok hirdetési pixeleit és a nem használt mérőkódokat. Előtte egyeztesd azzal, aki a hirdetéseidet kezeli.
- Kapcsold ki a nem használt bővítményeket, de csak friss mentés után, és egyesével, minden lépés után újramérve.
- Nézd meg a tárhely adminfelületén, van-e bekapcsolható gyorsítótár és választható újabb PHP-verzió.
Mikor a tárhelyszolgáltató a jó cím?
Ha a TTFB tartósan 800 ms fölött van, és az adminfelület is lassú, a tárhelyszolgáltató ügyfélszolgálata az első lépés. Írd meg nekik a mért értéket, az időpontot, amikor mérted, és kérdezd meg, eléri-e az oldalad a csomag erőforrás-korlátját (processzor, memória, egyidejű folyamatok). Egy jó szolgáltató a naplókból meg tudja mondani, a te oldalad terhel-e túl, vagy a szerver egésze.
Mikor kell weboldal-fejlesztő?
Fejlesztő akkor kell, ha a Search Console egy egész oldaltípust (például minden terméklapot) jelez lassúnak, mert az sablonszintű hiba. Ugyanígy, ha a Performance fülön hosszú JavaScript-futásokat látsz, amelyeket nem egy kikapcsolható bővítmény okoz, vagy ha a PHP-frissítés után valamelyik bővítmény hibát dob. Ezeknél a javítás kódot érint, és egy rossz mozdulat az űrlapot vagy a webshop pénztárát is elronthatja.
Hogyan ismered fel, hogy jó kezekben van a javítás?
Saját tapasztalat, nem szabály: a jó munkát nem a megígért pontszám jelzi, hanem a módszer. Ezekre figyelj.
- Az első lépés mérés, és a szakember megmondja, melyik számot (TTFB, LCP, INP, CLS) akarja javítani.
- Előtte és utána is mobilon mér, és a két eredményt megmutatja.
- Mentést készít, vagy tesztkörnyezetben dolgozik, nem élesben próbálgat.
- Nem áll meg egy gyorsító bővítmény feltelepítésénél, ha a mérés strukturális okot mutat.
- Leírja, mit változtatott, hogy később visszakereshető legyen.
Mit küldj el annak, aki a lassú weboldalt megjavítja?
Egy rövid, mért összefoglalót küldj. Benne legyen, melyik oldal lassú, mobilon milyen LCP, INP, CLS és TTFB értéket mutat, mi változott mostanában az oldalon, és milyen hozzáférést tudsz adni. Ezzel a javítás nem a hiba felkutatásával indul, hanem a lényeggel.
- Az érintett címek. A főoldal mellett az a két-három aloldal, ahová a legtöbb látogató érkezik, például a hirdetések céloldalai.
- A mérés eredménye. A PageSpeed Insights mobil eredményének képernyőképe, és a Search Console Core Web Vitals jelentéséből az érintett oldalcsoport.
- Mi változott? Új bővítmény, sablonfrissítés, új hirdetési pixel, tárhelyköltözés. A lassulás gyakran egy konkrét változtatás után kezdődik.
- Mikor lassú? Mindig, vagy csak munkaidőben, csak mobilon, csak bizonyos oldalakon.
- Hozzáférések. Adminfelület, tárhely, és az, hogy van-e friss mentés.
- Ami nem változhat. Űrlapok, mérőkódok, futó kampányok céloldalai. Ezeket a javítás után külön ellenőrizni kell.
A hozzáférést külön felhasználóként add meg, ne a saját jelszavadat küldd el e-mailben, és a munka végén vond vissza vagy töröld a felhasználót.
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.
- Hogy ki javítja meg, az okon múlik: a képeket sokszor te magad, a magas TTFB-t a tárhelyszolgáltató, a szkript- és sablonhibákat egy fejlesztő, és mindegyiknek egy rövid, mért összefoglalóval érdemes nekiindulni.
- 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 hoz biztosan 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.
Ki tudja megjavítani a lassú weboldalamat?
Az okon múlik. A túl nagy képeket és a felesleges bővítményeket gyakran te magad is rendbe teszed, a tartósan 800 ms fölötti TTFB-vel a tárhelyszolgáltatóhoz érdemes fordulni, a sablonszintű és a JavaScript-futásidőből eredő gondokat pedig egy weboldal-fejlesztő javítja. Előbb mérj PageSpeed Insightsszal és Search Console-lal, mert ebből derül ki, kihez kell menned.
Mit kérdezzek, mielőtt valakire rábízom a weboldal gyorsítását?
Kérdezd meg, melyik mérőszámot akarja javítani és miért, mér-e mobilon előtte és utána, készít-e mentést vagy dolgozik-e tesztkörnyezetben, és leírja-e, mit változtatott. Ha a válasz csak annyi, hogy feltesz egy gyorsító bővítményt, a strukturális okok valószínűleg megmaradnak.
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.