--- title: "Weboldal sebesség optimalizálás: így gyorsítottuk fel a saját oldalunkat, számokkal" description: "Hogyan mérj, mit javíts először, és mit nem old meg a gyorsítás. Valós before-after a saját oldalunkról, a tévutakkal együtt. Nézd meg a számokat." url: https://milcomp.hu/news/weboldal-sebesseg-optimalizalas/ locale: hu published: 2026-08-10 modified: 2026-08-10 author: Molnár Márton --- Webshop és webfejlesztés # Weboldal sebesség optimalizálás: így gyorsítottuk fel a saját oldalunkat, számokkal A legtöbb sebesség-cikk tippeket sorol. Ez egy konkrét eset: mit mértem, mit javítottam, és az a három javítás, ami tévút volt, mielőtt megtaláltam az igazi okot. 2026. augusztus 10. 5 perc olvasás Írta Molnár Márton A Milcomp alapító tulajdonosa és fejlesztője. A weboldal sebesség optimalizálás nem tippek listája, hanem mérés-javítás-újramérés ciklus. Aki azzal kezdi, hogy telepít egy gyorsítótár bővítményt, az a rendszer felénél kezdi, és általában nem oldja meg azt a problémát, ami miatt tényleg lassú az oldal. Ez a cikk egy konkrét eseten megy végig: a saját oldalunkon. Beleértve azt a három javítást is, ami logikus volt, mégis rossz irányba vitt. Ezt a részt szokta kihagyni a szakma, pedig szerintem ez a leghasznosabb. ## Mit mérj, mielőtt bármihez hozzányúlsz Négy dolgot érdemes rögzíteni, ebben a sorrendben (a metrikák hivatalos definíciói a Google [Core Web Vitals oldalán](https://web.dev/articles/vitals) vannak): 1. 1. **Melyik oldalt méred.** A főoldal és egy hosszú cikk teljesen máshogy viselkedik. Válassz három-négy reprezentatív oldalt, és mindig ugyanazokat mérd. 2. 2. **Lab vagy field adat.** A Lighthouse szimulált körülmények között mér (lab). A Search Console Core Web Vitals riportja valódi látogatóktól jön (field). A kettő eltérhet, és mindkettő igaz. Döntés előtt nézd meg mindkettőt. 3. 3. **Három futás, medián.** Egy futás félrevezet. Nálunk egy oldal ugyanazon a build-en hozott 100-at nulla blokkolási idővel és 98-at 139 ezredmásodperccel. Ez futásszórás, nem regresszió. Ha egy futásra reagálsz, olyat javítasz, ami nem romlott el. 4. 4. **A négy metrika külön.** LCP (mikor jelenik meg a fő tartalom), CLS (mennyit ugrál a layout), TBT vagy INP (mennyire válaszol a lapod), TTFB (mennyit vár a szerverre). Ezek négy különböző probléma, négy különböző megoldással. A lényeg röviden - A weboldal sebesség optimalizálás mérésen kezdődik, nem javításon. Ha nem mérted, csak tippelsz. - Egy Lighthouse-futás önmagában nem bizonyíték. Mindig három futás, és a mediánt nézd. - A legnagyobb hozam általában a képeknél és a felesleges JavaScriptnél van, nem a szerveren. - A CLS-t szinte mindig egy betűtípus okozza, és nem ott, ahol keresed. - Ha az architektúra a szűk keresztmetszet, a hangolás nem segít. Ilyenkor őszintébb újraírni. ## A PageSpeed pontszám félrevezet Két konkrét csapda. Az egyik, hogy a pontszám egyetlen szám, ami négy metrikát présel össze, tehát elrejti, hogy pontosan mi romlott. A másik, hogy a mérés részletei számítanak: ha egy audit futtatásakor leszűkíted a kategóriákat, elveszítheted pont azt a diagnosztikát, ami megmondaná az okot. Velünk pontosan ez történt, mielőtt megtaláltuk a valódi hibát. Használd a pontszámot arra, hogy észrevedd a bajt. Ne használd arra, hogy eldöntsd, mit javíts. Mielőtt a pontszámot kergetnéd A 100 pont nem cél, hanem következmény. Az a kérdés, hogy a látogatód mikor látja a tartalmat, nem az, hogy hány pontot ad egy szimuláció. ## Egy valódi eset: a CLS, ami háromszor nem oda vezetett A [GEO útmutató cikkem](https://milcomp.hu/news/geo-utmutato/) három Lighthouse-futásból kettőn 0,179 CLS-t hozott, miközben az összes többi oldal 0,002 körül volt. Egy közvetlen böngészős mérés ugyanezen az oldalon tízből tízszer 0,0000-t adott. Tehát a hiba létezett, de csak a Lighthouse terhelési körülményei között jelent meg. **Első elmélet: a betűtípus méretezése.** A címsorokhoz használt Fredoka tartalék-betűtípusának méretkorrekcióját korábban vegyes szövegmintán mértük, 101,8 százalékra. Kiderült, hogy megjelenítési méretben ez az 1,8 százalék elég ahhoz, hogy egy sortörés átbillenjen: a cikk h1-e Fredokával négy sor, a 101,8 százalékos tartalékkal öt. Ez 44 pixel elmozdulás. Végigmértem 69 valódi címsort 8 oldalon, 3 szélességben, és a helyes érték 100 százalék lett. Javítottam. A cikk **továbbra is** 0,179-et hozott. **Második elmélet: valami más a fejlécben.** Elkezdtem webfontonként letiltani a betűtípusokat, és minden elem magasságát és pozícióját megmérni. **A valódi ok: a morzsamenü.** Bebas Neue betűtípussal készült, ami nem volt előtöltve. Amíg a Bebas meg nem érkezett, a négy elem két sorban fért el. Amikor megérkezett, egy sorba ugrottak, és az egész cikk, a címsor, a nyitókép és a szövegtörzs 29 pixellel feljebb csúszott. A morzsamenü a fejléc **testvéreleme**, ezért nevezte a Lighthouse a cikkfejlécet elmozduló elemnek, miközben annak a magassága nem is változott. És ezért volt minden képkocka azonos a 375. ezredmásodperctől: az elmozdulás már véget ért, mielőtt az első képkockát rögzítették volna. A javítás nem méretkorrekció volt, hanem szerkezeti: **a morzsamenü soha nem tördel**. Egy egysoros, vízszintesen görgethető sor magassága nem függhet a betűtípustól, tehát nincs mit elmozdítania. A tanulság általánosítható, és megéri felírni: **minden olyan elem a hajtás felett, aminek a magassága változhat betűtípus-cserekor, egy időzített CLS-hiba.** A rövid, nagybetűs címkékből álló, tördelő sor a klasszikus alakzat. Jobb nem tördelni és túlcsordulni hagyni, mint kézzel hangolt tartalék-metrikában bízni. ## Mit hoz a legtöbbet, sorrendben | Beavatkozás | Tipikus hatás | Ráfordítás | | --- | --- | --- | | Képformátum és méret (AVIF/WebP, kiírt szélesség és magasság) | nagy | kicsi | | Betűtípus betöltés (előtöltés, tartalék-metrikák, nem tördelő elemek) | közepes, a CLS-re nagy | kicsi | | Felesleges kliensoldali JavaScript eltávolítása | nagy | közepes | | Edge cache és CDN | nagy a szerver válaszidőre | kicsi | | Szerver és PHP hangolás | közepes | közepes | | Újraépítés más architektúrával | a legnagyobb | nagy | A sorrend nem véletlen. Az első négy sor együtt általában többet hoz, mint bármilyen szerveroldali hangolás, és sokkal olcsóbb. Ha valaki azzal kezdi, hogy nagyobb szervert ajánl, kérdezd meg, mit mért. ## Mikor nem sebesség-probléma a sebesség-probléma Van, amikor a hangolásra nem érdemes költeni, és ezt jobb kimondani, mint elszámlázni. Ha az oldal minden látogatáskor tucatnyi adatbázis-lekérdezést futtat egy olyan tartalomért, ami havonta egyszer változik, akkor nem a lekérdezéseket kell gyorsítani, hanem nem kellene futtatni őket. A mi esetünkben ez volt a válasz: az oldal statikus generálásra váltott, és a szöveg egy része ettől egyszerűen visszatért a HTML-be, mert korábban csak JavaScript futtatása után került oda. Ha a szűk keresztmetszet az architektúra, akkor a gyorsítótár csak elfedi. Ilyenkor az őszinte ajánlat az újraírás, nem egy sebességcsomag, még akkor is, ha az utóbbit könnyebb eladni. ## Gyakori kérdések ### Mennyibe kerül egy weboldal sebesség optimalizálás? A magyar piacon a jellemző szolgáltatáscsomagok néhány tízezer forinttól százezres nagyságrendig terjednek, a méret és a rendszer függvényében. Az ár nagyjából annak a függvénye, hogy hány rendszert kell megérteni. Egy audit önmagában, javítás nélkül, mindig olcsóbb, és sokszor az az első helyes lépés. ### Lassú a weboldalam, hol kezdjem? Mérj három futást a fő oldalaidon, és nézd meg külön az LCP-t, a CLS-t és a blokkolási időt. A legtöbb esetben a képek és a felesleges JavaScript adja a hozam nagy részét. Bővítményt telepíteni utolsó lépés, nem első. ### Elég egy gyorsítótár bővítmény? Ideig-óráig javít a mérésen, de az okot nem szünteti meg. Ha az oldal alapból túl sok munkát végez minden látogatáskor, a gyorsítótár csak elrejti ezt, és az első olyan oldalon, amit nem tud cache-elni, visszatér a probléma. ### Mi az a CLS, és miért rossz, ha magas? A CLS azt méri, mennyit ugrál a tartalom betöltés közben. Ha rákattintanál egy gombra és közben elcsúszik, az CLS. Google rangsorolási tényező, de ennél fontosabb, hogy idegesítő. Szinte mindig betűtípus-betöltés vagy méret nélküli kép okozza. ### Számít-e a sebesség az AI keresőkben? Közvetlenül kevésbé, mint a Google-ben. Ami sokkal többet számít, hogy a tartalom benne van-e a kiszolgált HTML-ben JavaScript futtatása nélkül. Az AI-crawlerek egy része nem futtat JavaScriptet, tehát ami csak utána jelenik meg, az nekik nem létezik. ### Garantálható a 100 pont? Nem, és aki garantálja, az vagy egyetlen futást fog mutatni, vagy egy üres oldalt. A pontszám futásonként szór. Ami garantálható, az a metrikák javulása és az, hogy megmutatjuk, mitől. **Ha a te oldalad lassú és nem tudod, miért, [írj nekünk](https://milcomp.hu/kapcsolat/), vagy nézd meg a [webfejlesztési és üzemeltetési szolgáltatásainkat](https://milcomp.hu/szolgaltatasok/). Először mérünk, utána mondunk árat.** Megosztás - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fmilcomp.hu%2Fnews%2Fweboldal-sebesseg-optimalizalas%2F) - [Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmilcomp.hu%2Fnews%2Fweboldal-sebesseg-optimalizalas%2F) ## Kapcsolódó cikkek - [Statikus weboldal: a leggyorsabb és legbiztonságosabb céges oldal](https://milcomp.hu/news/statikus-weboldal-cegeknek/) 2026. augusztus 10. A statikus weboldal nem visszalépés a kilencvenes évekbe. A saját oldalunkat írtuk át rá, és megmutatom, mit mértem előtte és utána. - [GEO: így kerül be a céged a ChatGPT és a Google AI válaszaiba](https://milcomp.hu/news/geo-utmutato/) 2026. augusztus 3. A vevőid már az AI-tól kérdeznek, mielőtt szolgáltatót választanak. A GEO (generative engine optimization) arról szól, hogy a válaszban a te céged legyen a forrás. Gyakorlati útmutató, hype nélkül. - [E-számla 2026: mi kötelező valójában egy KKV-nak?](https://milcomp.hu/news/e-szamla-2026-kkv-utmutato/) 2026. augusztus 3. Sok cikk állítja, hogy 2026-tól kötelező a B2B e-számla. Nem az. Utánajártam elsődleges forrásokból, mi kötelező tényleg, mikortól, és mire érdemes már most készülnöd. Beszéljünk a te folyamataidról Megnézzük, hol termel valódi megtakarítást az automatizálás nálatok, és hol nem. Kérj AI-felmérést