Oldalsebesség: hogyan tesztelje 5 perc alatt, és mit kezdjen a pontszámmal

A weboldal sebességét ingyenes eszközökkel kevesebb mint 5 perc alatt ellenőrizheti. Nyissa meg a Google PageSpeed Insights eszközét, illessze be az oldala URL-jét, és kattintson az Analyze gombra. Az eredmény 0-tól 100-ig terjedő pontszámot mutat: az 50 alatti pontszám komoly teljesítményproblémát jelez, a cél 90 vagy afölött van. Minden weboldalnál külön tesztelje a mobil és az asztali változatot, mert a Google elsősorban az oldal mobilváltozatát indexeli. Ebben a cikkben végigvesszük a pontos menetet az első teszttől a leggyakoribb problémák javításának konkrét lépéseiig.

Ha még nem olvasta, mik azok a Core Web Vitals, és miért számítanak, azt javaslom, kezdje ott: ott megtalálja az LCP, az INP és a CLS pontos meghatározását szakzsargon nélkül. Ez a cikk feltételezi, hogy tudja, mit mér, és arra összpontosít, hogyan mérje meg, és mit kezdjen az eredményekkel.

Miért számít az oldalsebesség a SEO-ban is, nem csak az ügyfélnek

A Google 2021 óta a Core Web Vitals révén közvetlen rangsorolási jelként értékeli a weboldal sebességét, ezért a lassú weboldal nemcsak elriasztja a látogatókat, hanem közvetlenül hátrébb is kerül az organikus keresésben.

2024-ben a Google a FID (First Input Delay) mutatót az INP (Interaction to Next Paint) mutatóval váltotta fel, ezzel még nagyobb hangsúlyt helyezve az oldal interaktivitására. Ez azt jelenti, hogy egy 2022-es vagy 2023-as régebbi audit nem feltétlenül tükrözi a weboldala mai állapotát: az INP-t másként mérik, és egy jó FID-értékű régi weboldal ma elbukhat az INP-n.

A SEO-n túl a sebesség közvetlenül hat a konverzióra is. A mobilhálózatok Szlovákiában viszonylag gyorsak, de a mobileszközök processzorai gyengébbek, mint az asztali gépeké: a weboldalnak egy közepes teljesítményű Android telefonon is jól kell működnie, nem csak egy Wi-Fi-re csatlakozó MacBookon. Az a weboldal, amely mobilon 6 másodperc alatt töltődik be, a gyakorlatban a látogatók többsége számára használhatatlan.

1. lépés: PageSpeed Insights - az első és leggyorsabb oldalsebesség-teszt

A PageSpeed Insights a Google ingyenes eszköze, és minden sebességelemzés helyes kiindulópontja: lab adatokat és a weboldala látogatóitól származó valós field adatokat is ad.

Elérhető a pagespeed.web.dev címen. Két adatréteget kombinál:

• Lab data (Lighthouse) - ellenőrzött környezetben futtatott szintetikus teszt; mindig elérhető, ideális az optimalizálás előtti és utáni összehasonlításhoz
• Field data (CrUX) - a weboldala valódi látogatóinak valós mérőszámai a Chrome böngészőből, az elmúlt 28 napra; csak akkor érhető el, ha a weboldal elegendő forgalmat kap

Ha a weboldala kevés forgalmat kap, a CrUX adatok nem lesznek elérhetők: ebben az esetben kizárólag a lab adatokra támaszkodjon.

A menet:

1. Nyissa meg a pagespeed.web.dev oldalt
2. Illessze be a fő landing page URL-jét (nem feltétlenül a kezdőlapét: azt az oldalt tesztelje, amelyik elad)
3. Kattintson az Analyze gombra
4. Nézze meg az eredményeket külön a Mobile és külön a Desktop nézetben, mindig mindkettőt

Pontszám	Állapot	Gyakorlati hatás
90-től 100-ig	Zöld - jó teljesítmény	A weboldal gyors, a CWV valószínűleg rendben van
50-től 89-ig	Narancs - javításra szorul	Látható lassú pontok, de nem katasztrófa
0-tól 49-ig	Piros - gyenge teljesítmény	Kritikus állapot, közvetlen negatív hatás a SEO-ra és a konverzióra is

A legtöbb szlovák bemutatkozó weboldal, amely kereskedelmi sablonra és több page builder bővítményre épül, mobilteszten a narancs vagy a piros sávba esik.

2. lépés: A PageSpeed Insights eredményeinek olvasása - mit nézzen először

A PageSpeed Insights eredményei közül elsősorban a Core Web Vitals értékeit és a Diagnostics szekciót figyelje: ott találja a konkrét problémákat a teljesítményre gyakorolt hatásuk szerint rendezve.

A Core Web Vitals küszöbértékei a web.dev/vitals szerint (a Google hivatalos dokumentációja):

• LCP (Largest Contentful Paint) - mikor töltődik be az oldal fő vizuális eleme. Jó: kevesebb mint 2,5 másodperc. Rossz: több mint 4 másodperc.
• INP (Interaction to Next Paint) - milyen gyorsan reagál az oldal egy kattintásra vagy billentyűleütésre. Jó: kevesebb mint 200 milliszekundum. Rossz: több mint 500 milliszekundum.
• CLS (Cumulative Layout Shift) - az elemek nem kívánt elmozdulásának mértéke betöltés közben. Jó: kevesebb mint 0,1. Rossz: több mint 0,25.

A Diagnostics szekcióban elsősorban ezeket keresse:

• Render-blocking resources - JavaScript vagy CSS fájlok, amelyek a betöltés befejezése előtt blokkolják az oldal megjelenítését
• Unused JavaScript / Unused CSS - kód, amely letöltődik, de nincs használatban; jellemző a page builderes weboldalakra
• Images not properly sized - a képek nagyobbak, mint ahogyan a weboldal valójában megjeleníti őket; feleslegesen foglalják a sávszélességet
• Large network payloads - az oldal teljes mérete; tájékoztató jelleggel 2 MB alatt egészséges

Az első két probléma, a render-blocking és a unused JavaScript, jellemzően a legnagyobb gond az Elementorra, Divire vagy WPBakeryre épülő weboldalaknál. Arról, hogy miért és hogyan lehet kilépni egy ilyen megoldásból, a Költöztetés Elementorról: hogyan váltson tiszta WordPress témára című cikkben írtunk.

3. lépés: GTmetrix a mélyebb diagnosztikához - hol vész el az idő

A GTmetrix részletesebb képet ad, mint a PageSpeed Insights, beleértve a waterfall grafikont és az európai szerverekről futtatott tesztet, ami valósághűbb képet ad a szlovákiai látogatókra vonatkozóan.

A gtmetrix.com ingyenes fiókjával különböző földrajzi helyszínekről tesztelhet. Ez fontos: a PageSpeed Insights amerikai szerverekről tesztel. Egy szlovák vagy cseh szerveren hostolt weboldal más eredményt ad, ha Európából teszteli, mint ha Amerikából. Az európai szerverrel futtatott GTmetrix (London vagy Vancouver - a szlovákiai relevancia miatt Londont válassza) valósághűbb képet ad.

A kulcsfontosságú nézet a Waterfall tab: vizuálisan mutatja, milyen sorrendben és mennyi ideig töltődik be az egyes fájl. Ha egy hosszú sávot lát (JS bundle, hatalmas CSS vagy nagy kép), ott a szűk keresztmetszet.

A GTmetrix ezeket is megmutatja:

• Az oldal teljes betöltési ideje (Fully Loaded Time)
• Az átvitt adatok teljes mennyisége MB-ban
• A HTTP requestek teljes száma

Tájékoztató jellegű benchmarkok egy jól optimalizált, szlovák vagy cseh hostingon futó weboldalhoz: 2 másodperc alatti betöltési idő európai tesztszerverről, 2 MB alatti teljes oldalméret, 80 alatti requestszám. Ezek csak keretértékek: az oldal és a tartalom összetettségétől függenek.

4. lépés: Google Search Console - adatok a weboldala valódi látogatóitól

A Google Search Console-ban van egy Core Web Vitals szekció a látogatóitól származó valós adatokkal: ez hitelesebb forrás, mint a szintetikus tesztek, mert a Google éppen a field adatokat értékeli.

Ha a Google Search Console be van állítva (és be kellene lennie), keresse meg a bal oldali menüben a Core Web Vitals szekciót. A jelentés három csoportba sorolja az URL-eket:

• Jó URL-ek - mindhárom mutató zöldben
• Javításra szoruló URL-ek - valamelyik mutató narancsban
• Rossz URL-ek - valamelyik mutató pirosban

A Search Console CWV jelentése fontosabb, mint a Lighthouse pontszám, mert a Google a rangsoroláskor éppen a field adatokat értékeli, nem a lab adatokat. Ha a weboldala havonta legalább néhány száz látogatást kap, a Search Console a teljesítmény értékelésének leghitelesebb forrása.

A Search Console a teljesítményproblémákat konkrét URL-ekhez is köti: láthatja, hogy az egész domain lassú, vagy csak bizonyos oldalak (pl. egy blogkategória a kezdőlaphoz képest). Ez jelentősen megkönnyíti a javítások rangsorolását.

Az oldalsebesség-tesztelő eszközök összehasonlítása

Minden eszköz más nézőpontot kínál: az átfogó képhez ideális legalább a PageSpeed Insightst a Search Console-lal kombinálni.

Eszköz	Ár	Adattípus	Mire a legjobb
PageSpeed Insights	Ingyenes	Lab + Field (CrUX)	Első teszt, CWV mutatók, azonnali eredmény
GTmetrix	Ingyenes / fizetős	Lab (szintetikus)	Waterfall, teszt európai szerverről, időbeli összehasonlítás
Google Search Console	Ingyenes (ellenőrzést igényel)	Field (valódi felhasználók)	Éles adatok, SEO-kontextus, a problémás URL-ek azonosítása
Chrome Lighthouse (DevTools)	Ingyenes	Lab	Fejlesztői diagnosztika, a változtatások tesztelése deploy előtt
WebPageTest	Ingyenes	Lab (haladó)	Haladó elemzés, film strip, videofelvételes tesztelés

A szlovák weboldalak tipikus problémái és javításuk

A szlovák bemutatkozó weboldalak elemzésekor újra és újra ugyanabba az öt problémába ütközünk, és legtöbbjük a weboldal teljes átépítése nélkül is megoldható.

1. Optimalizálatlan képek
Eredeti méretű fényképek, tömörítés nélküli JPEG, PNG ott, ahol a WebP is elég lenne. Egy négy-öt MB-os kép a kezdőlapon mobilkapcsolaton kritikus probléma.
Megoldás: WebP vagy AVIF formátumra konvertálás, lazy loading beállítása a „fold” alatti képekre, width/height attribútumok megadása a CLS megelőzésére.

2. Függés a page buildertől
Az Elementorra, Divire vagy WPBakeryre épülő weboldalak minden oldalon több tucat JS és CSS fájlt töltenek be. Ezek közül sok render-blocking, és az architektúra megváltoztatása nélkül nehezen távolítható el.
Megoldás: A költöztetés page builder nélküli, tiszta WordPress témára radikális, de hatékony. Ha Önnél 5 vagy több jel is mutatja, hogy a weboldal lemaradásban van, olvassa el az 5 jel, hogy ideje újratervezni a weboldalt című cikket.

3. Lassú hosting (magas TTFB)
A 600 ms feletti Time to First Byte (TTFB) a hosting vagy a szerverkonfiguráció problémája, nem a front-endé. Semmilyen front-end optimalizálás nem fedi el a lassú szervert.
Megoldás: Váltás olyan hostingra, amely SSD lemezeket, PHP 8.2+ verziót és LiteSpeed vagy Nginx szervert kínál. WordPresshez: a LiteSpeed Cache vagy a WP Rocket CDN-nel kombinálva jelentősen segít.

4. Beállítatlan cache
Minden látogatás újra letölti ugyanazokat a CSS, JS fájlokat és képeket. A cache helyes beállítása a visszatérő látogatóknál az adatforgalom jelentős százalékát megtakarítja.
Megoldás: Szerveroldali gyorsítótárazás bekapcsolása (LiteSpeed, Nginx FastCGI), browser cache fejlécek beállítása, és érdemes megfontolni CDN-t a statikus assetekhez.

5. Ellenőrizetlen harmadik féltől származó szkriptek
Google Analytics, Hotjar, Facebook Pixel, chat widget, hírlevél-űrlap: minden szkript késleltetést ad hozzá, és lehet render-blocking. Egyes weboldalakon nyolc-tizenkét harmadik féltől származó szkriptet látunk anélkül, hogy a tulajdonos tudná, miért vannak ott.
Megoldás: Az összes szkript auditálása, csak a nélkülözhetetlenek megtartása, a feleslegesek eltávolítása. A maradékot aszinkron módon vagy defer attribútummal töltse be.

A gyakorlatban: hogyan folytassa a teszt eredményei alapján

A teszt önmagában nem elég: az eredményeket konkrét lépéslistává kell alakítani, a Core Web Vitalsra gyakorolt hatás szerint rendezve.

A gyakorlatban a szlovák weboldalak elemzésekor ugyanazzal a mintával találkozunk: a tulajdonos négy-öt éve készíttette a weboldalt, és akkor jól működött. Ma a Google az INP-t értékeli (2024 óta új mutató), a mobil indexelés a prioritás, és az oldal egy átlagos Android telefonon hat-nyolc másodperc alatt töltődik be. Az eredmény: magasabb visszafordulási arány, nulla organikus lead.

A jó hír: a legtöbb probléma a weboldal teljes átépítése nélkül is megoldható. Rangsorolja a javításokat aszerint, melyiknek van a legnagyobb hatása a CWV-re:

1. LCP probléma = általában egy kép vagy a szerver válaszideje - ezt oldja meg elsőként
2. CLS probléma = hiányzó képméretek vagy size-adjust nélküli webfontok - gyorsan javítható
3. INP probléma = túl sok JS a fő szálon - összetettebb, JS auditot igényel

Ha az eredmények piros vagy narancs mutatókat mutatnak, és nem tudja, hol kezdje, egy átfogó SEO- és teljesítményaudit segít, amely azonosítja a problémákat, és prioritást rendel hozzájuk. Az általunk az alapoktól, kattintgatós sablonok nélkül épített weboldalak jelentősen jobb teljesítménnyel indulnak: a felesleges kód egyszerűen nem kerül beléjük.

A Google AI Mode és az LLM-hivatkozások kontextusában (erről a Google AI Mode és SEO 2026 című cikkben írtunk) az oldal teljesítménye még fontosabb: a lassú oldalaknak kisebb az esélyük arra, hogy forrásként hivatkozzanak rájuk az AI válaszokban, mert a Google a Page Experience jelek alapján is alacsonyabbra értékeli őket.

Összegzés

A weboldal sebességének tesztelése 5 percet vesz igénybe, és az eszközök ingyenesek. A PageSpeed Insights és a GTmetrix tiszta képet ad az állapotról, a Google Search Console pedig megmutatja, hogyan látják ezt a valódi látogatók. Ha az eredmények piros számokat mutatnak, és nem tudja, mit kezdjen velük, nézze meg, mit fed le a SEO- és teljesítményoptimalizálás szolgáltatásunk, vagy ha a probléma mélyebben, a weboldal architektúrájában van, a weboldal újratervezés.

Weboldala teljesítményauditján gondolkodik? Kötelezettség nélküli konzultáció - 24 órán belül válaszolunk.

GYIK

Gyakori kérdések.

Mi számít jó pontszámnak a PageSpeed Insightsban?

A 90 vagy afölötti pontszám zöld: a weboldal gyors, és a Core Web Vitals valószínűleg rendben van. Az 50 és 89 közötti pontszám narancs, és látható teljesítményproblémákat jelez. Az 50 alatti piros: a weboldalnak komoly problémája van, amely közvetlenül hat a SEO-ra és a konverzióra is.

Miért más a weboldalam pontszáma mobilon és asztali gépen?

A Google külön értékeli a mobil és az asztali változatot, mert a mobileszközöknek gyengébb a processzoruk és lassabbak a hálózataik. A mobil pontszám általában alacsonyabb, és fontosabb is: a Google elsősorban az oldal mobilváltozatát indexeli (mobile-first indexing).

Számít, honnan tesztelem a weboldalt?

Igen. A PageSpeed Insights amerikai szerverekről tesztel; egy európai hostingon futó szlovák weboldalnál az európai szerverrel (pl. London) futtatott GTmetrix valósághűbb képet ad. Azt javasoljuk, hogy mindkét eszközzel teszteljen.

A weboldal gyorsítása a SEO-nak is segít?

Igen: a Google 2021 óta közvetlen rangsorolási jelként használja a Core Web Vitals értékeket. A lassú weboldal hátrébb kerül, mint egy tartalmilag hasonló, gyors weboldal. A mutatókról bővebben a Core Web Vitalsról szóló cikkben olvashat.

Mi a TTFB, és miért fontos?

A Time to First Byte (TTFB) az első requesttől a szerver válaszának első bájtjáig eltelt idő. A 600 ms feletti TTFB hosting- vagy szerverproblémára utal. Ezt semmilyen front-end optimalizálás nem javítja meg: a hostingot, a szerverkonfigurációt vagy a CDN-t kell rendbe tenni.