Webfejlesztés

Miért lassú a weboldalad, és hogyan javítsd ki?

Csipkay Péter · 2026. május 1.

Weboldal sebesség optimalizálás gyakorlati útmutatóval: képek, pluginek, cache, hosting, render-blocking scriptek és Core Web Vitals javítás.

Röviden: A lassú weboldal leggyakoribb okai: túl nagy képek, túl sok plugin, gyenge hosting és render-blocking scriptek. A diagnózis ingyenes Google PageSpeed Insights-szal kezdődik. A Google és a Deloitte közös kutatása szerint ha egy oldal betöltési ideje 1-ről 3 másodpercre nő, a visszafordulás valószínűsége 32%-kal emelkedik — ez közvetlenül kevesebb ajánlatkérést jelent.

Ha egy weboldal lassú, azt a látogató azonnal érzi. Nem kell technikai magyarázat: késik a hero kép, ugrál a layout, lassan reagál a menü, vagy a mobilos oldal másodpercekig üres fehér képernyőt mutat. A probléma nem csak kényelmetlen. A lassú oldal kevesebb ajánlatkérést, gyengébb bizalmat és rosszabb keresőteljesítményt hozhat.

A weboldal sebesség optimalizálás első lépése nem az, hogy vaktában telepítünk egy cache plugint. Előbb meg kell érteni, mi lassítja az oldalt. A leggyakoribb okok: túl nagy képek, túl sok plugin, rossz hosting, hiányzó cache, render-blocking CSS vagy JavaScript, nehéz third-party scriptek és rosszul felépített frontend.

Hol kezdd a diagnózist?

Az első lépés a Google PageSpeed Insights futtatása. Írd be az oldal URL-jét, és nézd meg külön a mobilos és desktop eredményt. Ne csak a nagy pontszámot figyeld, hanem a konkrét jelzéseket: melyik elem az LCP, mi okoz layout shiftet, melyik script blokkolja a renderelést, és mennyi JavaScript fut az oldalon.

A Core Web Vitals három alapvető mutatóra figyel: LCP, INP és CLS. A web.dev ajánlása szerint jó felhasználói élményhez az LCP legyen legfeljebb 2,5 másodperc, az INP 200 ms vagy kevesebb, a CLS pedig 0,1 vagy kevesebb. Ezek a számok nem önmagukért fontosak, hanem azért, mert a betöltés, az interakció és a vizuális stabilitás valós felhasználói élményt mérnek.

1. Túl nagy és rosszul kezelt képek

A lassú oldalak egyik leggyakoribb oka a kép. Egy 4000 pixel széles, tömörítetlen hero fotó mobilon teljesen felesleges, mégis sok weboldal ilyen képeket tölt be. A web.dev teljesítményútmutatója is kiemeli: a képek gyakran a legnehezebb és leggyakoribb erőforrások a weben, ezért az optimalizálásuk látványosan javíthatja a sebességet.

Tipikus hibák:

• túl nagy felbontású képek;
• régi JPG/PNG formátum ott, ahol WebP vagy AVIF jobb lenne;
• nincs responsive image méretezés;
• nincs lazy loading a hajtás alatti képeken;
• a hero kép nincs preloadolva, pedig az adja az LCP-t;
• háttérképként berakott fontos kép, amit nehezebb optimalizálni.

Javítás: méretezd a képeket a megjelenítési mérethez, használj modern formátumot, állíts be srcset-et vagy framework szintű képoptimalizálást, lazy loadold a nem kritikus képeket, és kezeld külön az LCP képet. Egy jól optimalizált hero kép gyakran önmagában másodperceket javít mobilon.

2. Túl sok plugin és builder

WordPress oldalaknál a plugin-túlterhelés klasszikus probléma. Egy plugin az űrlaphoz, egy a sliderhez, egy a SEO-hoz, egy a cache-hez, egy a galériához, egy az animációhoz, egy a cookie bannerhez. Külön-külön mind ártatlannak tűnik, együtt viszont CSS-t, JavaScriptet, adatbázislekérdezést és kompatibilitási kockázatot adnak az oldalhoz.

A vizuális builderek ugyanezt erősíthetik: sok wrapper, sok inline style, sok felesleges DOM elem. Ettől a design könnyen szerkeszthetőnek tűnik, de a böngésző sokkal több munkát kap.

Javítás: plugin audit. Nézd meg, mi fut ténylegesen az oldalon, mire van szükség, és mit lehet kiváltani egyedi fejlesztéssel vagy könnyebb megoldással. A cél nem az, hogy nulla plugin legyen, hanem hogy minden plugin indokolt legyen. Egy custom WordPress téma vagy Astro/Next.js frontend sok esetben tisztább alapot ad, mint egy túlterhelt builder stack.

3. Nincs cache vagy rossz cache-beállítás

Ha a szerver minden látogatásnál újra összerakja az oldalt, az oldalletöltési sebesség feleslegesen romlik. WordPress esetén ez különösen látványos: PHP fut, adatbázis-lekérdezések történnek, pluginek dolgoznak. Cache nélkül a szerver minden alkalommal ugyanazt a munkát végzi el.

Cache több szinten létezik:

• böngésző cache statikus fájlokra;
• szerver oldali page cache;
• objektum cache adatbázis-műveletekhez;
• CDN cache képekhez, CSS-hez, JS-hez;
• build-time generált statikus oldalak Astro vagy Next.js esetén.

Javítás: állíts be megbízható page cache-t, megfelelő cache headereket és CDN-t. Ha tartalomalapú oldalról van szó, érdemes megfontolni statikus vagy hibrid architektúrát, ahol az oldal nagy része előre generált fájlként töltődik be.

4. Gyenge hosting és lassú TTFB

Ha a Time to First Byte magas, a böngésző későn kapja meg az első választ a szervertől. Ilyenkor hiába optimalizálod a képeket, az oldal eleve késve indul. Olcsó, túlterhelt shared hostingon ez gyakori: sok weboldal osztozik ugyanazon az erőforráson, és csúcsidőben minden lassul.

Tipikus jelek:

• a PageSpeed szerint a szerver válaszideje magas;
• admin felület is lassú;
• időnként gyors, időnként nagyon lassú az oldal;
• sok 500-as vagy timeout hiba jelenik meg;
• WooCommerce vagy nagyobb WordPress oldal nehézkesen működik.

Javítás: jobb hosting, megfelelő PHP verzió, objektum cache, CDN, adatbázis optimalizálás, vagy statikus frontend. Nem minden problémát old meg a hostingváltás, de rossz szerveren nincs stabil sebesség.

5. Render-blocking CSS és JavaScript

A böngésző nem tud bármit azonnal kirajzolni. Bizonyos CSS és JavaScript erőforrások blokkolhatják a megjelenítést. A web.dev kritikus renderelési útvonalról szóló útmutatója szerint a CSS alapból render-blocking erőforrás: a böngésző megvárja a feldolgozását, mielőtt kirajzolja az oldalt.

Ezért probléma, ha a <head> tele van nagy CSS fájlokkal, fontbetöltéssel, külső scriptekkel, analytics kódokkal és cookie bannerrel. A látogató még semmit nem lát, de a böngésző már sok erőforrást tölt és dolgoz fel.

Javítás: kritikus CSS külön kezelése, nem kritikus CSS késleltetése, JavaScript defer vagy async használata, felesleges script eltávolítása, fontok optimalizálása, harmadik féltől származó kódok minimalizálása. A cél: minél hamarabb jelenjen meg a hasznos tartalom.

6. Túl sok third-party script

Analytics, hőtérkép, chat widget, remarketing pixel, social embed, cookie banner, A/B teszt eszköz. Mindegyik hasznos lehet, de mindegyik lassíthat. Különösen mobilon, gyengébb eszközön, lassabb hálózaton.

A third-party script azért veszélyes, mert nem teljesen te kontrollálod. Ha a külső szolgáltatás lassú, az oldalad is lassabbnak érződhet. Ha túl sok ilyen script fut, romolhat az INP, mert a böngésző fő szála terhelődik.

Javítás: mérd meg, melyik script mennyit visz el. Tarts csak olyan eszközt, amely valódi üzleti döntést támogat. A chat widgetet, hőtérképet vagy A/B tesztet nem kell minden oldalon betölteni. Kampányidőszakon kívül sok script kikapcsolható.

7. Nincs karbantartási folyamat

Sok oldal nem indul lassúnak, hanem idővel lassul le. Új képek kerülnek fel optimalizálás nélkül. Új plugin települ. Új tracking kód jön. A cache elromlik. Egy frissítés után duplán töltődik be egy script. A tartalom nő, de az architektúra nem követi.

Ezért a weboldal sebesség optimalizálás nem egyszeri takarítás. Rendszeres ellenőrzés kell:

• PageSpeed Insights havi vagy kampány előtti futtatása;
• Search Console Core Web Vitals riport figyelése;
• plugin és dependency audit;
• képméretek ellenőrzése;
• űrlapok és konverziós utak tesztelése;
• hosting és cache monitorozás.

A weboldal karbantartás része nálunk pontosan ez: nem csak hibajavítás, hanem teljesítményfigyelés, frissítés, biztonság, tartalmi gondozás és mérhető javítás.

Gyors diagnosztikai sorrend

Ha most kellene kezdened, ezt a sorrendet követném:

Gyakran ismételt kérdések

Mi a jó Google PageSpeed pontszám?

Általános célként mobilon 80+ már jó irány, 90+ erős eredmény. De ne csak a pontszámot nézd. Fontosabb, hogy a Core Web Vitals mérőszámok zöldek legyenek, és az oldal valós mobilhasználatban is gyorsnak érződjön.

Miért lassú a WordPress oldalam?

Leggyakrabban túl sok plugin, nehéz theme vagy builder, optimalizálatlan képek, rossz hosting, hiányzó cache és túl sok külső script miatt. Ezek javíthatók, de sokszor audit kell, mert a lassulás több okból áll össze.

Elég egy cache plugin a gyorsításhoz?

Nem mindig. A cache sokat segíthet, de nem javítja meg a túl nagy képeket, a rossz hostingot, a felesleges JavaScriptet vagy a gyenge tartalomstruktúrát. A cache gyorsítótár, nem architektúra.

Milyen gyakran kell sebességet mérni?

Üzleti weboldalnál legalább havonta, nagyobb kampány vagy fejlesztés előtt pedig külön. Minden új plugin, tracking script, nagyobb design módosítás vagy tartalmi bővítés után érdemes újra mérni.