Miért lassú a weboldalad, és mit tehetsz ellene?

Mennyit ér 0,1 másodperc?

Erre van konkrét szám. A Google megbízásából a Deloitte Digital 37 vezető európai és amerikai márka mobil-oldalát vizsgálta négy héten át, több mint 30 millió munkameneten. Azt nézték, mi történik, ha az oldal mindössze egytized másodperccel gyorsul.

Kiskereskedelemben a konverzió 8,4%-kal, az átlagos kosárérték 9,2%-kal nőtt. Utazási oldalakon a konverzió 10,1%-kal emelkedett. A hatás a vásárlási út minden lépésén megjelent: a termék-listaoldalról a termékoldalra lépés 3,2%-kal, a kosárba tétel 9,1%-kal lett gyakoribb.

Egytized másodperc. Annyi idő, amit ember nem érzékel tudatosan, de a viselkedésén mégis meglátszik. Ez a legfontosabb, amit a sebességről tudni érdemes: nem esztétikai kérdés, és nem is elsősorban SEO-kérdés. Bevétel-kérdés.

A három mérőszám, közérthetően

A Google Core Web Vitals néven három dolgot mér, és mindhárom a látogató élményének egy-egy szakaszát írja le. Nem véletlenül három: máshol romlik el a betöltés eleje, a közepe és a használat.

LCP, vagyis mikor jelenik meg a lényeg. Azt méri, mennyi idő alatt rajzolódik ki a legnagyobb tartalmi elem, ami jellemzően a főkép vagy a főcím. Ez a látogató szempontjából az „na végre, betöltött” pillanat. Jó érték: legfeljebb 2,5 másodperc.

INP, vagyis milyen gyorsan reagál. Rákoppintasz a menüre vagy egy gombra, és eltelik valamennyi idő, mire a képernyőn történik bármi. Jó érték: legfeljebb 200 ezredmásodperc. Ez a mérőszám 2024 márciusában váltotta le a korábbi FID-et, és szigorúbb nála: nem csak az első interakciót nézi, hanem az egész látogatás alatt a leglassabbakat.

CLS, vagyis mennyire ugrál az elrendezés. Amikor épp rákattintanál valamire, de közben betölt egy kép vagy egy hirdetés, és odébb tolja. Jó érték: 0,1 alatt. Mobilon ez a legbosszantóbb, és szinte mindig egyetlen okra vezethető vissza: a képnek nincs előre lefoglalt helye.

Egy részlet, ami sokakat félrevezet: a Google nem az átlagot nézi, hanem a 75. percentilist, mobilra és asztalira külön. Vagyis nem az számít, hogy nálad gyors-e, hanem hogy a látogatóid legalább háromnegyedénél teljesül-e a küszöb.

Hol tart a web, és hol tartasz te?

Érdemes tudni, mihez mérd magad. A HTTP Archive Web Almanac 2025-ös felmérése szerint a weboldalak 48%-a mobilon és 56%-a asztali gépen teljesíti mind a három küszöböt. Vagyis mobilon nagyjából minden második oldal megbukik.

A metrikánkénti bontás megmutatja, hol a gyenge pont. Mobilon az INP-t az oldalak 77%-a, a CLS-t 81%-a teljesíti jól, az LCP-t viszont csak 62%. Asztali gépen az INP gyakorlatilag megoldott probléma (97%), az LCP ott is a leggyengébb (74%).

Ez a szám megkímél a felesleges munkától. Ha lassú az oldalad, a valószínűség nagyon nagy, hogy nem a kattintás-válaszidővel van baj, hanem azzal, hogy egyáltalán mikor jelenik meg valami a képernyőn. És mivel az LCP-elem mobilon az esetek 76%-ában egy kép, a sebesség kérdése a legtöbb oldalon valójában kép-kérdés.

Hogyan mérd meg öt perc alatt

Két ingyenes eszköz kell, mindkettő a Google-tól. Az első a PageSpeed Insights: beírsz egy URL-t, és kapsz egy jelentést. Itt van egy fontos csapda, amit érdemes megérteni.

A jelentés felső blokkja a valós felhasználói adat (a Chrome böngészők névtelen mérése az elmúlt 28 napból). Az alsó blokk a laborteszt: egy szimulált eszközön, egyetlen betöltésből. A kettő rendszeresen eltér, és a Google a felsőt, a valósat használja. Ha csak a labor-pontszámot nézed, könnyen dolgozol rossz számokkal.

A második eszköz a Search Console Core Web Vitals jelentése, ami nem egy URL-t, hanem az egész oldalad mutatja, URL-csoportokba rendezve. Ez mondja meg, hogy a probléma egyetlen oldalt érint-e, vagy az egész sablonodat. Ha még nincs bekötve, arról külön írtunk: Search Console útmutató.

Mérj mindig mobil nézetben, és ne az irodai wifid mellől ítélj. A látogatóid nagy része gyengébb telefonon, mobilneten érkezik, és a Google is így méri őket.

Miért lassú valójában?

A leggyakoribb ok nem az, amire először gondolnál. Nem a tárhely, nem a WordPress, és nem is „a sok látogató”. Hanem az, hogy az oldal egyszerűen túl sok adatot küld le.

A medián kezdőlap 2025-ben 2,56 MB mobilon, és ez egyetlen év alatt 8,4%-kal nőtt. Ebből a legtöbb bájtot a képek viszik: asztali oldalakon 1054 KB kép jut 613 KB JavaScriptre. Ráadásul a képek 57%-a még mindig hagyományos JPG formátumban van, pedig a modern WebP ugyanazt a képet jellemzően jóval kisebben adja.

A második nagy tétel a szkriptek. Minden bővítmény, chat-ablak, beágyazott térkép, közösségi gomb és követő-kód saját hálózati kéréseket és saját JavaScriptet hoz. Ez a szám látványosan romlik: a medián Total Blocking Time mobilon egy év alatt 58%-kal nőtt, 1209 ezredmásodpercről 1916-ra. Az oldalak nem lettek gazdagabbak, csak nehezebbek.

A harmadik, és a legkönnyebben javítható: a méret nélküli képek. A mobil oldalak 62%-án van legalább egy kép, aminek nincs megadva a szélessége és a magassága. A böngésző ilyenkor nem tudja előre lefoglalni a helyét, ezért amikor a kép megérkezik, arrébb löki a szöveget. Ez a CLS, és pár sornyi javítással megszűnik.

Végül a betűtípusok: az oldalak 87%-a használ webfontot, de csak alig egynegyedük szól előre a böngészőnek, hogy honnan fogja letölteni. Ez pár száz ezredmásodperc, amit ingyen el lehetne kerülni.

Mit tegyél, fontossági sorrendben

A gyorsítás azért szokott elakadni, mert mindenki mindent egyszerre akar. Pedig a hozam nagyon egyenetlenül oszlik el: az első két lépés hozza a javulás túlnyomó részét.

1. A képek. Ezzel kezdd, itt van a legtöbb megspórolható bájt. Konvertáld modern formátumra, és ami még fontosabb: ne 4000 pixel széles fotót tölts fel egy 800 pixeles helyre. Adj meg minden képnek szélességet és magasságot, a hajtás alattiakat töltsd késleltetve, a főképet viszont soha ne, mert épp az az LCP-elem.

2. Kevesebb szkript. Nézd végig, hány bővítmény fut az oldaladon, és hányat használsz ténylegesen. Egy elhagyott csúszka-bővítmény vagy egy régi közösségi modul akkor is tölt, ha egyetlen látogató sem látja.

3. Gyorsítótár és tömörítés. A statikus gyorsítótár és a tömörítés bekapcsolása jellemzően konfiguráció kérdése, nem fejlesztésé, és azonnal érezhető.

4. Tárhely. Az olcsó, túlterhelt tárhely a szerver válaszidejében látszik, ami az LCP legelső szakasza. Hiába optimalizálsz mindent utána, ha az első bájtra másodperceket kell várni.

5. Betűtípusok. Kevesebb betűvágat, és szólj előre a böngészőnek, honnan tölti őket.

6. Ne ugráljon semmi. Minden képnek, hirdetésnek és beágyazásnak legyen előre lefoglalt helye.

Mikor látod az eredményt?

Ez a rész szokott csalódást okozni, ezért érdemes előre tudni. A laborteszt azonnal mutatja a javulást: átalakítod a képeket, újra lefuttatod, és rögtön jobb a pontszám.

A valós felhasználói adat viszont 28 napos gördülő ablakban mozog. Vagyis a mai javításod a mai méréssel keveredik az elmúlt négy hét régi adataival, és csak fokozatosan tisztul ki. Ha egy héttel a javítás után nézed meg a Search Console-t, jó eséllyel alig látsz változást, pedig már minden rendben van.

Reális várakozás: laborban azonnal, a Search Console-ban 3-4 hét múlva látod a teljes hatást.

És tényleg rangsorol emiatt a Google?

Igen, de nem úgy, ahogy az ígéretek sugallják. A Core Web Vitals része a Google értékelésének, de sokkal gyengébb jel, mint az, hogy a tartalmad mennyire válaszol a keresésre. Egy gyors oldal rossz tartalommal nem fog előrébb kerülni egy lassú oldalnál, ami pontosan azt adja, amit a kereső keresett.

Reális kép: a sebesség inkább döntetlen-bontó. Ha ketten hasonlóan jó választ adtok, a gyorsabb kerül előrébb. Emellett közvetetten is hat, mert a gyors oldalról kevesebben lépnek vissza azonnal.

Ezért nem ígérünk pozíció-ugrást pusztán a gyorsítástól. Amit ígérni lehet, az a Deloitte-számokban van: ugyanannyi látogatóból több érdeklődő. A rangsorolás egyéb tényezőiről a SEO 2026 cikkünkben írtunk, arról pedig, hogy mikor éri meg egyáltalán hozzányúlni az oldalhoz, a weboldal-felújítás útmutatóban.

Gyakori kérdések