PageSpeed 95+ valós feltételek között: gyakorlati ellenőrzőlista

A „95+ PageSpeed” nem trükk, nem mágia. Egy 18 pontos lista, amit minden új oldalon végigfutok — és amit a meglévő oldaladon is használhatsz ellenőrzőlistaként. Előtte érdemes tisztázni, mit mér pontosan a PageSpeed, mert a pontszám és a látogatóid valódi élménye nem ugyanaz.

Mit mér valójában a PageSpeed?

A PageSpeed Insights két különböző dolgot mutat, és a kettőt sokan összekeverik.

Valós felhasználói adatok. A Chrome-ot használó látogatóid valódi mérései az elmúlt 28 napból. Ezek alapján dönti el a Google, hogy az oldalad megfelel-e a Core Web Vitals követelményeinek. Három mutatót néz, mindegyiknél a látogatók 75%-ára vonatkozó értéket:

• LCP (Largest Contentful Paint) — mikor jelenik meg az oldal legnagyobb eleme, jellemzően a hero kép vagy a főcím. Jó, ha legfeljebb 2,5 másodperc.
• INP (Interaction to Next Paint) — milyen gyorsan reagál az oldal egy kattintásra vagy érintésre. Jó, ha legfeljebb 200 ezredmásodperc. 2024 márciusában ez váltotta a korábbi FID-et.
• CLS (Cumulative Layout Shift) — mennyire ugrálnak az elemek betöltés közben. Jó, ha legfeljebb 0,1.

Laborteszt. Egy szimulált mérés: középkategóriás telefon, lassított mobilnet. Ebből jön a 0–100-as pontszám. A legnagyobb súlya a TBT-nek (Total Blocking Time, 30%), az LCP-nek és a CLS-nek (25–25%) van, a maradékon az FCP és a Speed Index osztozik. Az INP a laborból hiányzik, mert valódi kattintás kell hozzá — a TBT a laboros közelítése.

A „95+ valós feltételek között” nálam azt jelenti: a laborpontszám mobilon is 95 fölött van, és a valós felhasználói adatokban mindhárom mutató a jó sávban marad.

Hogyan olvasd a jelentést?

• Mobilt nézz, ne asztalit. A Google a mobil változat alapján indexel, és a mobilos pontszám jellemzően jóval alacsonyabb — ez a valós kép.
• Felül a valós adatok, alul a labor. Ha a valós adatoknál azt látod, hogy nincs elég adat, az oldalnak még kevés a Chrome-os látogatója. Ilyenkor a laborpontszám az irányadó.
• Egy mérés nem mérés. A laborpontszám futtatásról futtatásra néhány pontot ingadozhat. Mérj háromszor, és a középső eredményt nézd.
• A legnagyobb nyereséggel kezdd. A javaslatok listája megmutatja, melyik javítás mennyi időt nyerne. Nem kell mindet megcsinálni — az első kettő-három sokszor hozza a javulás nagyját.

A 18 pontos ellenőrzőlista

Öt csoport, mindegyikben elöl azzal, ami a legtöbbet szokta hozni.

Képek (5 pont)

• Modern formátum. WebP vagy AVIF — ugyanolyan minőség mellett jellemzően jóval kisebb, mint a JPG vagy a PNG. A régi formátum legfeljebb tartaléknak kell.
• Megfelelő méret. Ne tölts be 2000 pixeles képet egy 400 pixeles helyre. A srcset és a sizes attribútummal minden eszköz a neki való méretet kapja.
• Lusta betöltés. loading="lazy" minden képre, ami nem látszik az első képernyőn — de soha nem a hero képre.
• Rögzített méretarány. width és height minden képen, hogy a böngésző előre lefoglalja a helyüket. Enélkül ugrál a tartalom, és romlik a CLS.
• Elsőbbség a legnagyobb képnek. Az LCP-kép kapjon fetchpriority="high" jelzést vagy előtöltést (<link rel="preload">), hogy a böngésző elsőként kérje le.

Betűtípusok (3 pont)

• Ne várakoztasd a szöveget. font-display: swap minden egyedi betűtípusra, hogy a szöveg letöltés közben is olvasható legyen — vagy optional, ha még szigorúbb vagy.
• Saját tárhelyről, előtöltve. A betűfájlok a saját domainedről jöjjenek, WOFF2 formátumban, és a legfontosabb egy-két fájl kapjon előtöltést. Minden külső kapcsolat — például a Google Fonts felé — plusz várakozás.
• Csak ami kell. Csak a ténylegesen használt vastagságok és karakterkészletek. Magyar szöveghez a latin mellé a latin-ext készlet is kell, különben az ő és az ű tartalék betűtípussal jelenik meg.

JavaScript (4 pont)

• Halasztott betöltés. defer vagy async minden szkriptre, ami nem kell az első megjelenéshez.
• Külső szkriptek fékezése. Chat, analitika, közösségi beágyazások, videók: ezek a leggyakoribb TBT- és INP-rontók. Töltsd be őket az első interakcióra, videónál pedig mutass előbb egy könnyű előnézeti képet, és csak kattintásra töltsd be a lejátszót.
• Csak az adott oldal kódja. Minden oldal csak azt a JavaScriptet kapja, amit használ. Az oldalépítők (page builderek) hajlamosak mindent mindenhová betölteni.
• Rövid feladatok, kis csomag. Az 50 ezredmásodpercnél hosszabb feladatok blokkolják a böngészőt, és rontják az INP-t. Irányszám: az első megjelenéshez szükséges JavaScript tömörítve maradjon 200 KB alatt.

CSS és HTML (3 pont)

• Kritikus CSS a fejlécben. Az első képernyőhöz szükséges stílus kerüljön közvetlenül a <head>-be (nagyjából 14 KB-ig), hogy a böngészőnek ne kelljen megvárnia a teljes stíluslapot.
• A többi később — vagy sehogy. A nem kritikus CSS töltődjön aszinkron módon, a használatlant pedig töröld: egy átlagos sablon stílusainak sokszor jelentős része egy adott oldalon nincs is használatban.
• Tömörítés. Minifikált HTML, CSS és JavaScript, a szerveren gzip vagy Brotli tömörítéssel.

Infrastruktúra (3 pont)

• Gyors szerver, modern protokoll. HTTP/2 vagy HTTP/3, és gyors első válasz: a szerver válaszideje (TTFB) jó, ha 0,8 másodperc alatt van. Egy túlterhelt tárhely önmagában lerontja az LCP-t.
• CDN. A statikus fájlok — képek, CSS, JavaScript, betűk — egy tartalomkézbesítő hálózatról érkezzenek (például Cloudflare, Bunny, Fastly), a látogatóhoz legközelebbi szerverről.
• Hosszú gyorsítótár. A változatlan, verziózott fájlok kapjanak egyéves Cache-Control fejlécet (immutable), hogy a visszatérő látogatónak ne kelljen újra letöltenie őket.

A leggyakoribb sebességrontók egy KKV-oldalon

Az auditokon újra meg újra ugyanazok a tettesek bukkannak fel:

• Tömörítetlen hero fotó. Egy több megabájtos kép az első képernyőn egymagában elrontja az LCP-t.
• Csúszka (slider) a hero szakaszban. Több nagy kép, extra JavaScript — és a második-harmadik diát kevesen látják. Részletesen: A hero szakasz fontossága — az első tíz másodperc.
• Chat-widget és beágyazott videó. Betöltéskor mindent megakasztanak, pedig a látogatók nagy része sosem kattint rájuk.
• Túl sok bővítmény, nehéz oldalépítő. Minden bővítmény hozza a saját CSS-ét és JavaScriptjét, akkor is, ha az adott oldalon nincs rá szükség.
• Túlterhelt, olcsó tárhely. Ha a szerver lassan válaszol, a legjobb frontend-optimalizálás sem tudja behozni a lemaradást.

Mikor érdemes leállni?

A 95+ pontszám szép, de nem öncél. A 90 és a 95 közötti különbséget a látogató gyakran nem érzi. Ha a valós felhasználói adatokban az LCP 2,5 másodperc, az INP 200 ezredmásodperc és a CLS 0,1 alatt marad, a látogatóid elégedettek — innentől a további optimalizálás hozadéka egyre kisebb.

Mérni viszont folyamatosan kell: egy nagy képfeltöltés vagy egy új külső szkript bármikor elronthatja, amit felépítettél. A havi rutinhoz: Weboldal karbantartás: mit kapsz a havidíjért, és mikor éri meg?

Ha szeretnéd, hogy a te oldaladat nézzem meg, az Auditálás és optimalizálás oldalon leírtam, hogyan dolgozom — vagy foglalj egy 30 perces beszélgetést.