Page speed: teljes útmutató

A page speed, vagyis az oldalsebesség azt írja le, milyen gyorsan töltődik be, jelenik meg és válik használhatóvá egy weboldal a látogató eszközén. Nem egyetlen szám, hanem több mutató együttese: a szerver válaszideje, az első tartalom megjelenése, a fő tartalom betöltése és a válaszkészség. Javítása a szerveren, a hálózaton és a böngészőben egyaránt történik.

Alapfogalmak

Az oldalsebesség az egyik leggyakrabban emlegetett, és leggyakrabban félreértett technikai SEO téma. Sokan egyetlen pontszámra gondolnak, amelyet egy mérőeszköz ad, és azt próbálják százra tornászni. A valóságban a sebesség a látogató élménye: mennyit kell várnia, mielőtt lát valamit, mielőtt a lényeget látja, és mielőtt használni tudja az oldalt. A pontszám ennek csak egy egyszerűsített összefoglalója.

A Google az oldalélményt a Core Web Vitals mutatóival méri. Ezek a sebesség és az élmény három kulcsmozzanatát ragadják meg: a fő tartalom betöltését (LCP), a válaszkészséget (INP) és a vizuális stabilitást (CLS). Az oldalsebesség tágabb fogalom: ide tartozik minden, ami ezeket a mutatókat befolyásolja, a szerver beállításától a képek formátumáig.

A legfontosabb mutatók

Mutató	Mit mér	Mi befolyásolja leginkább
TTFB (Time to First Byte)	Mikor érkezik meg a HTML első bájtja	Szerver, gyorsítótár, hálózat, átirányítások
FCP (First Contentful Paint)	Mikor jelenik meg az első szöveg vagy kép	TTFB, renderblokkoló CSS és JavaScript
LCP	Mikor jelenik meg a legnagyobb tartalmi elem	TTFB, a fő kép felfedezhetősége és mérete
INP	Milyen gyorsan reagál az oldal az interakciókra	JavaScript mennyisége, hosszú feladatok, DOM mérete
CLS	Mennyire ugrálnak az elemek	Méret nélküli képek, hirdetések, betűtípus-csere
TBT (Total Blocking Time)	Mennyi ideig blokkolt a fő szál betöltés közben	JavaScript-végrehajtás, harmadik felek

Laboratóriumi és terepi sebesség

A sebességet kétféle adat írja le. A laboratóriumi mérés egy szimulált eszközön és hálózaton tölti be az oldalt, ezért ismételhető és jó hibakeresésre. A terepi adat a valódi látogatók böngészőiből származik, és azt mutatja, amit ők ténylegesen tapasztalnak. A kettő gyakran eltér. A keresőt a terepi adat érdekli, a Core Web Vitals minősítése is abból készül. A laboratóriumi pontszám egy eszköz, nem cél.

Miért számít?

A sebesség elsősorban a látogató miatt fontos. A lassú oldal türelmetlenné teszi az embereket, akik ilyenkor gyakrabban hagyják el az oldalt, mielőtt az egyáltalán megjelenne. A keresőoptimalizálásban az oldalélmény jelzés, de a tartalom relevanciájához képest kisebb súlyú. Egy gyors, de gyenge tartalmú oldal nem fog jól rangsorolni, egy kiváló tartalmú, de nagyon lassú oldal viszont elveszítheti a látogatói egy részét. A sebesség a jó tartalom hatását erősíti vagy gyengíti.

Hogyan működik?

Egy oldal betöltése lépések sorozata. A látogató beírja a címet vagy rákattint egy linkre, a böngésző feloldja a domain nevét, kapcsolatot épít a szerverrel, lekéri a HTML-t, majd elkezdi feldolgozni. A HTML-ben talált stíluslapokat, szkripteket, képeket és betűtípusokat is lekéri, felépíti az oldal szerkezetét, kiszámolja az elrendezést, és kirajzolja a képernyőre. Minden lépésnek van ideje, és a teljes sebesség ezek összegéből és átfedéséből adódik.

A hálózati szakasz

DNS-feloldás. A böngésző megtudja, melyik IP-címen érhető el a domain. Lásd a DNS útmutatót.
Kapcsolat felépítése. TCP vagy QUIC kapcsolat, majd a titkosítás egyeztetése. A HTTPS ma alapkövetelmény, a modern protokollok a kézfogás költségét csökkentik.
Kérés és válasz. A szerver előállítja és elküldi a HTML-t. Itt számít a szerveroldali gyorsítótár és a háttérrendszerek sebessége.
Letöltés. Az adatok átvitele. Itt számít a tömörítés és a fájlméret.

A HTTP/2 egyetlen kapcsolaton párhuzamosan több kérést is kiszolgál, így a sok kis fájl kevésbé lassít, mint a régebbi protokollnál. A HTTP/3 a QUIC protokollra épül, és gyengébb, csomagvesztéses hálózaton lehet előnyös. A CDN a látogatóhoz közelebbi szerverről szolgál ki, ami a hálózati szakasz minden lépését rövidíti.

A böngészős szakasz

A böngésző a HTML-ből felépíti a dokumentum szerkezetét, a CSS-ből a stílusokat, és a kettőből kiszámolja, mi hova kerül. A CSS alapértelmezésben renderblokkoló: amíg a böngésző nem töltötte le és nem dolgozta fel a stíluslapokat, nem rajzol. A fejben elhelyezett szinkron szkriptek pedig az elemzést is megállítják. Ezt a folyamatot kritikus renderelési útnak nevezik, és a sebesség javításának nagy része arról szól, hogy ezt az utat rövidebbé és könnyebbé tegyük.

A fő szál

A JavaScript, a stílusszámítás, az elrendezés és a kirajzolás mind a böngésző fő szálán fut. Ha egy szkript sokáig fut, a böngésző közben nem tud rajzolni és nem tud reagálni a látogatóra. Ezért a JavaScript mennyisége és futási ideje nemcsak a betöltést, hanem a válaszkészséget is meghatározza. A mobil eszközök processzora általában gyengébb, így ugyanaz a kód mobilon lassabban fut.

Kidolgozott példa: egy vállalati weboldal első képernyője

Egy szolgáltató cég honlapja mobilon lassan jelent meg. A laboratóriumi mérés vízesés-diagramja megmutatta, hogy a HTML gyorsan megérkezett, de utána a böngésző három külön stíluslapot és egy nagy JavaScript-csomagot töltött le a fejből, mielőtt bármit kirajzolt volna. A betűtípusok egy külső szolgáltatótól jöttek, új kapcsolattal. A csapat a kritikus stílusokat beágyazta a HTML-be, a többi stíluslapot késleltetve töltötte be, a szkriptet defer attribútummal a feldolgozás végére tette, a betűtípusokat pedig saját szerverről szolgálta ki. Az első tartalom és a fő tartalom megjelenése is korábbra került a laboratóriumi mérésben.

Fő módszerek

A sebességjavítás módszerei a betöltés szakaszaihoz igazodnak. Nem kell mindent egyszerre megcsinálni: a mérés megmutatja, hol a legnagyobb a veszteség, és ott érdemes kezdeni. Az alábbi módszerek a leggyakrabban hatásosak, szakaszonként csoportosítva.

Szerver és hálózat

Gyorsítótár. A cache több szinten dolgozik: a szerveren a kész HTML tárolásával, a CDN-en a látogatóhoz közeli másolatokkal, a böngészőben a Cache-Control fejlécekkel beállított újrafelhasználással.
Tömörítés. A szöveges erőforrásokat, vagyis a HTML-t, a CSS-t és a JavaScriptet gzip vagy Brotli tömörítéssel érdemes kiszolgálni.
Modern protokoll. HTTP/2 vagy HTTP/3, ha a szerver és a CDN támogatja.
Kevesebb átirányítás. Minden átirányítás egy újabb kör a szerverrel. A belső linkek a végleges URL-re mutassanak.
Kevesebb külső domain. Minden új domain új kapcsolatot jelent. Ahol elkerülhetetlen, a preconnect segíthet.

Erőforrások betöltése

A böngészőnek segíteni kell eldönteni, mi fontos. A preload a jelenlegi oldalhoz szükséges, de későn felfedezett erőforrásokat hozza előre, például a fő betűtípust vagy a fő képet. A prefetch a valószínű következő oldal erőforrásait tölti le alacsony prioritással. A lazy loading a hajtás alatti képeket és beágyazásokat halasztja el, amíg a látogató a közelükbe nem görget. A három eszköz együtt rendezi a betöltés sorrendjét.

Képek

Modern formátumok, például WebP vagy AVIF, ahol a böngészők támogatják.
Reszponzív képek srcset és sizes attribútummal, hogy a mobil ne töltse le az asztali méretet.
Méretek megadása width és height attribútummal, az elmozdulások elkerülésére.
A fő kép ne legyen lusta betöltésű, és lehetőleg közvetlenül a HTML-ben legyen.

JavaScript és CSS

A JavaScript a leggyakoribb lassító tényező a modern webhelyeken. Csak az töltődjön be, ami az adott oldalhoz kell: kódfelosztással, a nem használt kód eltávolításával, és a nem kritikus szkriptek defer vagy async betöltésével. A harmadik féltől származó szkripteket, például elemzőket, csevegőablakokat, hirdetéseket, rendszeresen át kell vizsgálni. A CSS-nél a kritikus stílusok beágyazása és a nem használt szabályok eltávolítása csökkenti a renderblokkolást. Ha az oldal tartalma csak JavaScripttel áll elő, a szerveroldali renderelés gyakran jelentős javulást hoz.

Döntési szabály a prioritásokhoz

Ha a mérés ezt mutatja	Első lépés
Hosszú TTFB	Szerveroldali gyorsítótár, CDN, átirányítások, háttérrendszer
Késői első tartalom, rendben lévő TTFB	Renderblokkoló CSS és szkriptek
Késői fő tartalom	A fő kép felfedezhetősége, prioritása és mérete
Magas TBT, gyenge INP	JavaScript csökkentése, harmadik felek, hosszú feladatok
Magas CLS	Méretek, helyfoglalás, betűtípus-csere

Gyakori hibák

A sebességoptimalizálás tele van csábító rövidítésekkel, amelyek egy mérőeszköz pontszámát javítják, a látogató élményét viszont nem, vagy éppen rontják. A legtöbb hiba abból fakad, hogy a csapat a pontszámot kergeti, nem a valós problémát.

Tévhit: a 100-as pontszám a cél

A laboratóriumi pontszám egy szimulált betöltés összefoglalója. A keresőt a valódi látogatók adata érdekli. Egy oldal, amely a laborban kiváló pontszámot kap, a terepen lehet javítandó, például mert a valós látogatók más eszközöket és hálózatokat használnak, vagy mert a problémás interakciók a betöltés után történnek. Fordítva is igaz: egy közepes laboratóriumi pontszámú oldal terepi adata lehet jó. A cél a jó terepi Core Web Vitals, nem a kerek szám.

Túl sok bővítmény és szkript

Tartalomkezelő rendszereknél gyakori, hogy minden új funkció egy újabb bővítménnyel érkezik, és mindegyik saját szkriptet és stíluslapot tölt be minden oldalon. Egy idő után az oldal lassú, és senki sem tudja, melyik bővítmény mit csinál. A rendszeres átvizsgálás, a nem használt bővítmények eltávolítása és a betöltés oldalanként korlátozása gyakran nagyobb javulást hoz, mint bármilyen finomhangolás.

Optimalizáló bővítmény vakon

A gyorsítóbővítmények sok hasznos funkciót adnak, de ha mindent bekapcsolsz, hibákat okozhatnak: összevont és késleltetett szkriptek, amelyek elrontják a funkciókat, vagy lusta betöltés a fő képen, amely rontja az LCP-t. Minden beállítás után mérj, és nézd meg az oldal működését is.

Ellenpélda: a mindent előtöltő oldal

Egy gyakori jó szándékú hiba, hogy a csapat a preload és a prefetch eszközét túl bőkezűen használja. Ha tucatnyi erőforrás kap magas prioritást, a böngésző nem tudja eldönteni, mi a valóban fontos, és a sávszélesség szétforgácsolódik. A fő kép és a fő betűtípus ilyenkor lassabban érkezik, mint előtöltés nélkül. A szabály egyszerű: előtöltést csak az kapjon, ami az első képernyőhöz nélkülözhetetlen, és amit a böngésző magától későn találna meg.

A mobil látogatók elfelejtése

A fejlesztők és a döntéshozók jellemzően erős gépen, gyors hálózaton nézik az oldalt. A látogatók jelentős része viszont mobilon érkezik, változó minőségű kapcsolaton. Amit az irodában gyorsnak érzünk, az egy középkategóriás telefonon lassú lehet. A mérést ezért mindig mobil nézetben, lassított processzorral és hálózattal is el kell végezni.

További visszatérő hibák

Csak asztali gépen tesztelés, gyors irodai hálózaton.
Óriási, tömörítetlen képek feltöltése a tartalomkezelőbe.
Webes betűtípusok sok változata, amelyekből az oldal csak kettőt használ.
Hiányzó böngésző-gyorsítótár a statikus erőforrásokon.
Kampánylinkek átirányítási lánca a céloldal előtt.
A mérés egyszeri projektként kezelése, pedig minden új funkció ronthatja az eredményt.

Mérés

A sebesség mérése folyamatos munka. A terepi adat mutatja meg, hol van probléma, a laboratóriumi adat, hogy miért. Egy új funkció, egy új bővítmény vagy egy új harmadik féltől származó szkript bármikor ronthatja az eredményt, ezért a mérést be kell építeni a fejlesztési folyamatba.

Eszközök

Eszköz	Adattípus	Mire jó
Search Console, Core Web Vitals jelentés	Terepi	Mely URL-csoportokban van gond, mobilon és asztalon
PageSpeed Insights	Terepi és laboratóriumi	Egy URL gyors áttekintése javaslatokkal
Chrome UX Report	Terepi	Összesített és történeti adatok, versenytársak összevetése
Lighthouse	Laboratóriumi	Ismételhető mérés, fejlesztési folyamatba is beépíthető
WebPageTest	Laboratóriumi	Részletes vízesés-diagram, többféle helyszín és hálózat
Chrome fejlesztői eszközök	Laboratóriumi	Hálózati és Performance panel a mély elemzéshez
Saját valós felhasználói mérés	Terepi	Oldaltípusonkénti adatok és a problémás elemek azonosítása

Munkafolyamat

Nézd meg a Search Console Core Web Vitals jelentésében, mely oldalcsoportok gyengék vagy javítandók.
Válassz oldalcsoportonként egy jellemző URL-t, és vizsgáld meg a PageSpeed Insightsban.
A laboratóriumi eszközökben, mobil nézetben és lassított hálózaton, nézd meg a vízesés-diagramot és a fő szál munkáját.
Azonosítsd a legnagyobb veszteséget a döntési szabály szerint.
Javíts sablonszinten, hogy az egész oldalcsoportra hasson.
Ellenőrizd a laborban, majd kövesd a terepi adatot a következő hetekben.

Teljesítménykeret

A teljesítménykeret egy előre rögzített határ, amelyet az oldal nem léphet át: például a JavaScript teljes mérete, a képek összsúlya vagy egy laboratóriumi mutató értéke. A konkrét határokat a saját webhelyed jelenlegi állapotából érdemes levezetni, nem egy általános listából. A keret értéke abban van, hogy minden új funkciónál kötelezővé teszi a kérdést: belefér-e? Ha nem, valamit el kell hagyni vagy optimalizálni.

Kidolgozott példa: blog bővítmény-átvizsgálása

Egy tartalomkezelőre épülő blog terepi adatai mobilon romlottak. A laboratóriumi mérés sok szkriptet és stíluslapot mutatott, amelyeket a cikkoldalak nem használtak: egy kapcsolati űrlap, egy galéria és egy közösségi megosztó bővítmény minden oldalon betöltődött. A csapat eltávolította a nem használt bővítményeket, a többinél pedig korlátozta a betöltést azokra az oldalakra, ahol valóban szükség volt rájuk. A laboratóriumi mérésben a fő szál blokkolása csökkent, a terepi adat pedig fokozatosan javult.

Ellenőrzőlista

Van szerveroldali és böngészős gyorsítótár?
A szöveges erőforrások tömörítve érkeznek?
A fő kép a HTML-ben van, lusta betöltés nélkül, megfelelő méretben?
A nem kritikus szkriptek defer vagy async módon töltődnek?
A harmadik féltől származó szkriptek listája át van nézve?
A képeken van width és height?
A terepi Core Web Vitals minden fő oldalcsoportban a jó sávban van?