Partner Stúdio

Lefuttatod a PageSpeed Insightsot a saját oldaladra, és ott virít egy piros szám. Rossz érzés, tudom. Pedig a rengeteg mért adatból a Google szemében csak három igazán fontos – ezt a hármat hívják Core Web Vitalsnak.

Az egyik a betöltést figyeli, a másik azt, milyen gyorsan reagál az oldal, a harmadik pedig azt, mennyire „ugrál”. Ha érted, melyik mit jelent és honnan jön az adat, rájössz: nem a 100 pontot kell hajszolnod. Elég három, jóval szerényebb határt megugrani.

Három rövidítés, amit megéri megjegyezni

A Google fejlesztői oldala, a web.dev jelenleg ezt a hármat sorolja ide:

• LCP (Largest Contentful Paint) – mennyi idő alatt jelenik meg a képernyő legnagyobb tartalmi eleme. Jó: legfeljebb 2,5 másodperc. Gyenge: 4 másodperc fölött.
• INP (Interaction to Next Paint) – mennyi idő telik el egy kattintás, koppintás vagy billentyűleütés és a következő képkocka megjelenése között. Magyarul: milyen gyorsan „válaszol” az oldal. Jó: legfeljebb 200 ezredmásodperc. Gyenge: 500 fölött.
• CLS (Cumulative Layout Shift) – mennyit mozdulnak el váratlanul az elemek, miközben a látogató már olvasna. Jó: legfeljebb 0,1. Gyenge: 0,25 fölött.

A kettő közötti sáv a „javítandó”. Egy apróság: az INP csak 2024. március 12-e óta hivatalos mutató, akkor lépett a régi FID helyére. Ha egy cikk még FID-et emleget, azt a részt nyugodtan átugorhatod.

A határokat ráadásul nem átlagban kell érteni, és ezen sokan elcsúsznak. Az oldal akkor megy át, ha mindhárom mutató a látogatások legalább 75%-ában a jó sávban marad (szakszóval: 75. percentilis), mobilon és asztali gépen külön számolva. Vagyis hiába repül az oldal a saját gépeden – egy lassú mobilos látogatói réteg így is lehúzhatja az eredményt.

A PageSpeed pontszám nem az, aminek látszik

Kétféle mérés létezik, és nem mindegy, melyiket nézed.

A laborméréskor egy program (a PageSpeed Insightsban ez a Lighthouse) szimulált körülmények között tölti be az oldalt, és ebből gyárt egy 0–100-as pontszámot. A terepadat viszont valódi látogatóktól jön: a Google a Chrome UX Reportban (röviden CrUX) gyűjti azoktól a felhasználóktól, akik ehhez hozzájárultak.

A Search Console Core Web Vitals jelentése a súgó szerint ez utóbbiból dolgozik. A labor pontszáma tehát jó hibakereső, de a jelentésbe nem az kerül.

Miért nem látsz semmit a jelentésben?

Kisvállalkozóknál ez a klasszikus meglepetés: megnyitod a jelentést, és nincs benne semmi. Nem rontottál el semmit, ez a CrUX működéséből következik.

Egy oldal csak akkor kerül be az adatbázisba, ha nyilvános és elég látogatott. Hogy mennyi az „elég”, azt a Google nem árulja el. És nem is minden látogató számít: csak az asztali és androidos Chrome-ot használók, akik szinkronizálják a böngészési előzményeiket, és engedélyezték a használati statisztikák küldését. Az iPhone-os Chrome, a Safari és az Edge közönsége kimarad.

Ha egy URL-csoportnak kevés az adata, a Search Console az egész webhely (a teljes origin, vagyis protokoll és domain) számait veheti alapul. Ha ott sincs elég, marad az üres jelentés.

Ilyenkor jön a labor: a PageSpeed Insights mobilos mérése jó közelítés. Csak a pontszámot engedd el, és a három mutató értékére figyelj.

Feljebb kerülsz tőle a Google-ban?

Rövid válasz: talán egy kicsit, de ne ettől várd a csodát.

A Google Search Central dokumentációja a jó Core Web Vitals-értékeket a keresési sikerhez ajánlja, és azt írja, hogy ezek összhangban vannak azzal, amit a fő rangsoroló rendszerek jutalmazni igyekeznek. Azt viszont sehol nem mondja meg, mekkora a súlyuk a tartalomhoz képest.

Szerintem a józan olvasat ez: egy gyenge tartalmú oldalt a gyors betöltés nem visz fel az első helyre, két hasonlóan jó oldal közül viszont nem hátrány a fürgébbnek lenni. Ha épp azon töröd a fejed, mivel töltsd meg az oldalt, a helyi vállalkozások tartalomgyártásáról szóló cikkünkben találsz hozzá kapaszkodót.

A nagyobb nyereség amúgy is a látogatónál csapódik le. Egy ugráló, lassan reagáló oldalt hamarabb otthagynak. Gondolj bele, te meddig nyomkodsz egy makacs gombot.

LCP: szinte mindig a kép a ludas

A web.dev LCP-optimalizálási útmutatója négy szakaszra bontja a betöltést, és mindegyikhez ad egy irányszámot:

1. a szerver válaszideje (TTFB) – jó esetben a teljes idő nagyjából 40%-a;
2. a várakozás, amíg a böngésző egyáltalán nekiáll letölteni a fő képet – 10% alatt;
3. maga a letöltés – kb. 40%;
4. a megjelenítés csúszása – szintén 10% alatt.

A két várakozós szakaszt az útmutató szerint a nullához minél közelebb kell szorítani.

Egy átlagos vállalkozói oldalon a legnagyobb elem a nyitókép, vagy a fejlécben forgó képsor (slider) első képe. És ott jellemzően ugyanazok a hibák bukkannak fel.

Lustán betöltött nyitókép. Az útmutató itt nem hagy kétséget: az LCP-képre soha ne tegyél lusta betöltést (loading="lazy"), mert azzal épp a legfontosabb kép kerül a sor végére. A gond az, hogy sok WordPress-sablon és optimalizáló bővítmény ezt magától ráteszi minden képre. Egy pillantás a forráskódba megmutatja, nálad is így van-e.

Senki nem szólt a böngészőnek, mi a fontos. A fetchpriority="high" attribútummal jelezheted, melyik kép az első. Egy-két képnél többre ne tedd, különben az LCP-n már nem segít.

Háttérképként behúzott nyitókép. Ha a kép CSS-háttér, a böngésző csak a stíluslap feldolgozása után veszi észre. Ha nem tudod sima <img> elemre cserélni, előtöltéssel (<link rel="preload">) segíthetsz rajta.

Óriási fájl. A modern formátumok (WebP, AVIF) és a helyes méretre vágás sokat dob a dolgon. Egy 4000 pixel széles fotó egy 1200 pixeles helyen semmi mást nem csinál, csak a letöltést nyújtja. Ha már a képeknél tartasz: a képek alt szövegéről szóló cikkünkben azt is leírtuk, hogyan nevezd el és írd le őket.

Még egy figyelmeztetés: ha a TTFB már egymagában másfél másodperc, hiába csiszolod a képeket. Ilyenkor a tárhely, a gyorsítótárazás (cache) és a szerveroldali feldolgozás a gyanúsított.

INP: „rákattintok, és nem történik semmi”

Képzeld el: valaki megnyitja a mobilján az árlistádat, rábök a „Foglalás” gombra, és… semmi. Bök még egyet, aztán még egyet. Na, ezt a pillanatot méri az INP.

Az INP a kattintásokat, koppintásokat és billentyűleütéseket figyeli; a görgetést, az egér mozgatását és a nagyítást nem. A végső érték lényegében a látogatás leglassabb interakciója – azzal a csavarral, hogy minden 50 interakcióból a legrosszabbat elengedi. A legtöbb oldalon ennyit úgysem kattintanak, vagyis a gyakorlatban a leglassabb kattintás dönt.

A tettes többnyire egy „hosszú feladat”, ami lefoglalja a böngésző fő szálát. A web.dev szerint minden 50 ezredmásodpercnél hosszabb feladat ilyen. Ha a látogató épp ekkor kattint, a kattintásnak ki kell várnia a sorát.

Kisvállalkozói oldalakon a gyanúsítottak listája elég kiszámítható: chatablak, hirdetési és követőkódok, sütisáv, oldalépítő bővítmények animációi. Mind egyszerre indul, amikor betölt az oldal.

Fejlesztői oldalról a megoldás a munka feldarabolása és a fő szál időnkénti „elengedése” (yielding), erre újabban a scheduler.yield() való. Vállalkozóként viszont kezdd egyszerűbben: írd össze, milyen külső kódok futnak nálad, és mindegyiknél kérdezd meg, használja-e még valaki. Egy két éve elfelejtett követőkód kikapcsolása gyakran többet hoz, mint bármilyen finomhangolás.

CLS: amikor a szöveg elszalad a szemed elől

Ismerős jelenet: olvasol valamit a telefonon, és hirtelen az egész szöveg lejjebb csúszik, mert fölötte betöltött egy hirdetés. Vagy rossz gombra böksz, mert az épp arrébb ugrott. Ezt a bosszúságot számszerűsíti a CLS.

A számítás a legnagyobb „elmozdulás-sorozatot” veszi alapul: összecsoportosítja azokat a mozgásokat, amelyek egy másodpercen belül követik egymást, legfeljebb öt másodperces ablakban. Ami egy kattintás, koppintás vagy billentyűleütés utáni fél másodpercen (500 ezredmásodpercen) belül mozdul, az nem számít bele – ha egy gombra nyomva lenyílik a menü, azzal semmi baj. A görgetés viszont nem ilyen kivétel.

A CLS-javítási útmutató szerint ezek a fő bűnösök:

• Méret nélküli képek és videók. Ha hiányzik a width és a height, a böngésző nem tud helyet foglalni, és a betöltődő kép lejjebb löki a szöveget. Megadod a kettőt (vagy a CSS aspect-ratio tulajdonságot), és kész.
• Később érkező beágyazások. Hirdetés, térkép, Instagram-poszt, foglalási widget: foglalj nekik előre helyet min-height értékkel, és akkor se hagyd összeesni a helyet, ha végül nem töltődik be semmi.
• Felülre beúszó sávok. A betöltés után megjelenő akciós csík vagy sütiértesítés az egész oldalt lejjebb tolja. Vagy legyen előre helye, vagy lebegjen a tartalom fölött (például alul rögzítve).
• Webes betűtípusok. Ha a végleges betű szélesebb vagy keskenyebb a tartaléknál, a sorok betöltéskor újratördelődnek. Ez ellen a font-display: optional, a fontos betűtípus előtöltése és a tartalék betű méretének igazítása (size-adjust) segít.

Egy délutános terv a jövő hétre

Nyisd meg a Search Console Core Web Vitals jelentését. Ha van benne adat, URL-csoportokat látsz. Egy csoport állapotát mindig a leggyengébb mutatója adja: hiába szép az LCP és az INP, egyetlen gyenge CLS miatt az egész csoport „gyenge” címkét kap.

Ha nincs adat, futtass mobilos PageSpeed-mérést a főoldalra és a két-három legfontosabb aloldalra, és írd fel a három mutató értékét. (A pontszámot nem kell.)

Aztán mutatónként egy-egy kérdés:

• Melyik a legnagyobb elem, és van-e rajta lusta betöltés?
• Melyik külső szkriptre nincs már szükség?
• Mi ugrik meg betöltéskor?

Ezek sokszor egy délután alatt rendbe tehetők. Ha viszont a sablon vagy a bővítmények nem engednek hozzányúlni ezekhez a beállításokhoz, ott már fejlesztő kell. Egy külső szakember – például egy kisvállalkozásokkal dolgozó webes és marketingstúdió – azt is meg tudja ítélni, hogy a sablon foltozgatása vagy egy könnyebb alapra költözés éri-e meg jobban.

Végül egy tipp, hogy ne idegeskedj feleslegesen: javítás után a Search Console-ban elindíthatod a javítás ellenőrzését, a jelentés pedig ezután 28 napig figyeli az érintett URL-eket. Másnap tehát ne frissítgesd a jelentést. A javulás nagyjából egy hónap múlva látszik, a valódi látogatók adataiban – addig nyugodtan foglalkozz mással.

Kép: Firmbee / Pixabay