SEO

Weboldal sebesség és konverzió: minden másodperc pénzbe kerül

2026. július 3. Dexuro 6 perces olvasás Read in English →

A weboldal sebessége nem technikai luxus, hanem közvetlen bevételi kérdés. A Google saját kutatása szerint a mobil látogatók jelentős része elhagyja az oldalt, ha a betöltés három másodpercnél tovább tart — és minden további másodperc tovább rontja az arányt. A jó hír, hogy a sebesség nagyrészt néhány jól ismert tényezőn múlik, és a legtöbbjük egy-két nap alatt orvosolható. Ebben a cikkben megnézzük, mennyit veszítesz valójában egy lassú oldalon, mi a négy legnagyobb lassító, milyen sorrendben érdemes javítani, és hogyan tartsd gyorsan az oldalt hosszú távon.

Mennyit veszítesz egy lassú oldalon?

Többet, mint gondolnád — és a veszteség szorzódik a forgalommal. A nagy e-kereskedelmi szereplők régóta publikálják, hogy a betöltési idő és a konverzió szorosan összefügg: néhány száz milliszekundum lassulás mérhető konverzióesést okoz. Nézzünk egy egyszerű, konzervatív példát. Tegyük fel, hogy egy webshop havi 10 000 látogatót kap, a konverziós aránya 2%, az átlagos kosárérték pedig 50 000 Ft. Ez havi 200 rendelés, 10 millió Ft bevétel. Ha a lassú betöltés miatt a látogatók akár 10%-a távozik, mielőtt az oldal használhatóvá válna, az havi 20 elveszett rendelés — egymillió forint, minden hónapban, pusztán a sebesség miatt. Ez az a szám, ami miatt a teljesítmény nem „majd egyszer" feladat.

A négy legnagyobb lassító

A lassú oldalak túlnyomó többségénél ugyanaz a négy dolog a felelős — érdemes ezekkel kezdeni, mielőtt bármi bonyolultabba fognál.

  • Képek. Egy átlagos oldalon a letöltött adat nagyobbik része kép. Egy optimalizálatlan, több ezer pixel széles fotó önmagában több megabájt lehet. Modern formátum (WebP vagy AVIF), a megjelenítési mérethez igazított felbontás és lusta betöltés (lazy loading) együtt drámaian, gyakran 70–80%-kal csökkenti a képek súlyát — minőségromlás nélkül.
  • JavaScript. Minden script, ami fut, a böngésző fő szálát foglalja, és késlelteti, hogy az oldal használhatóvá váljon. Analitika, chat-widget, hőtérkép, közösségi beágyazások: külön-külön ártalmatlanok, együtt viszont több megabájtnyi kódot és másodperceket adnak a betöltéshez. A kérdés mindig az: tényleg használod-e mindet?
  • Betűtípusok. Több egyedi webfont, mindegyik több vastagsággal, gyorsan több száz kilobájt. Ráadásul rossz beállítás mellett a szöveg láthatatlan marad, amíg a font le nem töltődik. Töltsd be csak azt, amit valóban használsz, és állítsd be a `font-display: swap` viselkedést, hogy a szöveg azonnal olvasható legyen.
  • Tárhely. A szerver válaszideje (TTFB, Time to First Byte) az a pillanat, amíg az első bájt megérkezik. 200 ms alatt jó, felette érezhető a késés. Egy modern, él-alapú (edge) tárhely — például Vercel vagy Cloudflare — ezt gyakran azonnal biztosítja, hardveres beruházás nélkül.

Gyors győzelmek — a helyes sorrendben

Nem mindegy, mivel kezdesz. A legjobb hozamú lépések, sorrendben:

  1. Képoptimalizálás. Jellemzően fél-egy napnyi munka, és önmagában a legnagyobb, azonnal érezhető gyorsulást hozza. Ezzel kezdd.
  2. Felesleges JavaScript eltávolítása. Nézd meg, mit használsz valóban. A rég beépített, elfeledett scriptek eltávolítása gyakran több száz kilobájtot és értékes másodperceket szabadít fel.
  3. Szerverválaszidő javítása. Ha nem edge-tárhelyen vagy, a költözés egy modern platformra sokszor a legnagyobb egyszeri TTFB-nyereséget adja.
  4. Betűtípusok karcsúsítása. Öt font helyett egy-kettő, csak a használt vastagságokkal — újabb pár száz milliszekundum.

Hogyan tartsd gyorsan hosszú távon?

A sebesség nem egyszeri javítás, hanem karbantartandó állapot. Egy új plugin, egy nagyobb kép, egy szezonális kampányoldal bármikor visszalassíthatja azt, amit egyszer már rendbe tettél. Ezért érdemes mérni: a Google Lighthouse vagy a Core Web Vitals rendszeres, akár heti ellenőrzése megmutatja a romlást, mielőtt a látogatók észreveszik. Ez automatizálható is — egy egyszerű, ütemezett méréssel, ami riaszt, ha a teljesítmény egy küszöb alá esik. A konkrét mutatókról — LCP, INP, CLS — és arról, melyiket érdemes először javítani, a Core Web Vitals cikkünkben írtunk részletesen. Ha pedig nem szeretnél ezzel bajlódni, minden Dexuro-projektet eleve teljesítmény-kerettel tervezünk, és a szolgáltatásaink között a meglévő oldalak sebesség-auditja is szerepel — írj nekünk, és megnézzük, hol veszítesz most időt és vásárlót.

Gyakran ismételt kérdések

Az LCP (Largest Contentful Paint) alatt 2.5 másodperc alatt jó. A 2.5–4 másodperc között javítandó. 4 másodperc felett már messze leszakadva van a konkurenciához képest.

Igen, de nem az első szűk keresztmetszet. A Vercel vagy a Cloudflare jó választás, mindkettő gyors. A képek optimalizálása és a szükségtelen JavaScript gyakran nagyobb nyereség, mint a tárhely-váltás.

A cache-elés segít, de nem megoldás. Ha az oldal alapvetően lassú (nagy képek, rossz szerverválasz), a cache csak a tüneteket fedi. A gyökerek javítása kell.

Teljesítmény-optimalizálás

Szeretnéd tudni, mennyit lassú az oldal, és miért?

A teljesítmény-audit azonosítja a bottleneck-eket és azt, hogy hogyan lehet gyorsabb. A Core Web Vitals méréseiből kezdünk, majd végigmegyünk az optimalizáláson.

Konzultáció foglalása