A látogató ritkán mondja azt, hogy „ugrált az oldal". Azt mondja, hogy „valami nem stimmel a telefonon", vagy szó nélkül visszalép. A Cumulative Layout Shift (CLS) az a mérőszám, amelyik ezt az élményt számmá alakítja, és a Google Core Web Vitals hármasának egyik tagja. Az alábbiakban végigmegyünk azon, mit mér pontosan, mi okozza a legtöbb ugrálást a magyar kkv-oldalakon, hogyan találod meg a felelős elemet, és milyen konkrét javítás tartozik hozzá elemtípusonként.
Mit mér pontosan a Cumulative Layout Shift?
Rövid válasz: a CLS azt méri, hogy a képernyőn már látható tartalom mekkora része mozdul el váratlanul, és milyen messzire, a lap teljes élettartama alatt.
Hivatalosan igazolt: a Google fejlesztői dokumentációja szerint egyetlen elmozdulás pontszáma két tényező szorzata. Az egyik az érintett terület aránya (mekkora részét foglalja el a képernyőnek az elmozdulás előtti és utáni állapot együtt), a másik az elmozdulás távolsága, a nézetablak nagyobbik oldalához viszonyítva. Ha egy elem a képernyő felét kitölti, és a magasság negyedével csúszik lejjebb, az önmagában érzékelhető pontszámot ad.
A rendszer nem egyszerűen összeadja az összes elmozdulást. Úgynevezett munkamenet-ablakokba (session window) csoportosítja őket: egy ablak legfeljebb 5 másodpercig tart, és lezárul, ha egy másodpercnél hosszabb szünet következik. A lap CLS-értéke a legrosszabb ilyen ablak összege lesz. A hivatalos küszöbök: 0,1 alatt jó, 0,25 fölött gyenge, a köztes sáv javításra szorul. Fontos, hogy az értékelés a valós felhasználói mérések 75. percentilisén történik, tehát nem az átlagos, hanem a rosszabbul járó negyedhez közeli látogató élménye a mérce.
Két pontosítás, ami sok félreértést old fel. Az első: nem minden mozgás büntetendő. Ha a változás a felhasználó beavatkozása után fél másodpercen belül történik (lenyitsz egy menüt, megnyitsz egy harmonikát), azt a böngésző várt elmozdulásnak tekinti, és nem számolja bele. A második: a CLS nem csak az első másodpercekre vonatkozik. A görgetés közben belapoló, lusta betöltésű kép ugyanúgy ronthat rajta, mint a fejlécben megjelenő sáv.
Miért érzi meg a látogató a CLS-t, nem csak a mérőeszköz?
Rövid válasz: mert a CLS az egyetlen Core Web Vital, ami nem sebességet mér, hanem megbízhatóságot: azt, hogy oda kattint-e a látogató, ahová akart.
Saját tapasztalat: a leggyakoribb, valóban idegesítő eset a mobil sütibanner. A látogató a képernyő alján az „Elfogadom" gombra készül, a banner viszont éppen újrarendeződik, mert megérkezik hozzá egy betűtípus vagy egy logó, és a gomb helyére a „Beállítások" kerül. A látogató nem elemzi, mi történt: azt tapasztalja, hogy az oldal átvágta. Ugyanez a webshopok kosárgombjánál és a kapcsolatfelvételi űrlapok küldés gombjánál a legfájóbb, mert pont ott, ahol a bevétel keletkezik.
Ezért is érdemes a CLS-t nem pusztán technikai adósságként kezelni. A betöltési idő javítása gyakran csak néhány tized másodpercet hoz, amit a látogató nem feltétlenül tud megnevezni. Az ugráló elrendezés viszont konkrét, emlékezetes bosszúság. A javítása általában olcsóbb is: nem szerverre, CDN-re vagy képtömörítésre van szükség, hanem néhány attribútumra és CSS-szabályra.
Szakmai feltételezés: ahogy egyre több látogatás érkezik AI-ügynököktől és böngésző-automatizmusoktól, amelyek nem csak olvassák, hanem használják is az oldalt (gombot keresnek, űrlapot töltenek), a stabil elrendezés valószínűleg még többet fog számítani. Egy csúszkáló felületen a gépi kattintás ugyanúgy mellémehet, mint az emberi. Ez ma még nem dokumentált rangsorolási tényező, csak ésszerű következtetés, ezért így is kezeld.
Mik a leggyakoribb okok, amiktől ugrál az oldal?
Rövid válasz: szinte mindig ugyanaz a négy-öt forrás okozza a hibák túlnyomó részét, és mindegyik közös nevezője, hogy a böngésző nem tudta előre, mekkora hely kell.
Méret nélküli képek, videók és beágyazások
Ha az img elemen nincs width és height attribútum, a böngésző nulla magasságot feltételez, amíg a kép meg nem érkezik. Amint befut, a kép „kinyílik", és mindent lelök alatta. Ugyanez a helyzet a YouTube-beágyazásokkal, a térképekkel és a külső foglalási vagy időpontfoglaló widgetekkel: ezek jellemzően iframe-ben érkeznek, és a magasságukat futásidőben állítják be.
Későn betöltő betűtípus
A saját betűtípus letöltése időbe telik. Amíg nincs kész, a böngésző vagy tartalék betűvel rajzol (ezt cseréli le később), vagy láthatatlan szöveget mutat. A gond nem maga a csere, hanem hogy a tartalék és a végleges betű más szélességű: emiatt a bekezdés hossza megváltozik, néha egy sorral kevesebb vagy több lesz, és a teljes alatta lévő tartalom elcsúszik.
Dinamikusan beszúrt sütibanner és hirdetés
A sütikezelő szkript és a hirdetéskiszolgáló általában külső forrásból jön, tehát később, mint az oldal váza. Ha a banner a dokumentum folyamába kerül (nem lebegő rétegként), a beszúrás pillanatában mindent arrébb tol. A hirdetéshelyeknél még csúnyább a helyzet: ha nem érkezik hirdetés, a hely összeomlik, ha érkezik, kinyílik, és a méret kreatívonként változhat.
Felül megjelenő értesítősáv és promóciós csík
Az „Ingyenes szállítás" vagy „Nyári nyitvatartás" típusú sávok gyakran JavaScriptből kerülnek a body tetejére, néhány száz ezredmásodperccel a betöltés után. Ez a legdurvább fajta elmozdulás, mert a teljes oldalt lejjebb tolja, tehát az érintett terület aránya közel 100 százalék.
Utólag beszúrt tartalom: A/B teszt, személyre szabás, lusta betöltés
Az A/B tesztelő eszközök gyakran elrejtik, majd újrarajzolják a tartalmat. A lusta betöltés pedig akkor okoz gondot, ha a helykitöltő nem akkora, mint a végleges elem. Ilyenkor a látogató görgetés közben találkozik az ugrással, ami különösen zavaró, mert éppen olvas.
Hogyan azonosítod a konkrét elemet, ami ugrik?
Rövid válasz: a pontszám önmagában nem elég, keresd meg a felelős DOM-elemet a böngésző eszközeivel, majd ellenőrizd a valós felhasználói adaton, hogy tényleg ez a fő ok.
1. Layout Shift Regions: a leggyorsabb szemrevételezés
A Chrome fejlesztői eszközeiben nyisd meg a parancssort (Ctrl vagy Cmd + Shift + P), írd be, hogy Rendering, majd a megjelenő panelen kapcsold be a Layout Shift Regions opciót. Ezután töltsd újra az oldalt. Minden elmozduló terület villanó kék kiemelést kap. Ez másodpercek alatt megmutatja, hogy a fejléc, a bannerterület vagy a képgaléria a bűnös. Görgess is végig lassan az oldalon, mert a lusta betöltésű elemek csak ott mutatkoznak meg.
2. Performance felvétel: az időrend és a pontos elem
A Performance fülön indíts felvételt az újratöltéssel együtt (a körkörös nyíl ikonnal), mobil hálózat- és CPU-lassítás mellett. A felvételben az Experience sávban jelennek meg a Layout Shift bejegyzések. Ha rákattintasz egyre, az alsó Summary panel kiírja a pontszámot, valamint a mozgásért felelős elemet (Moved from, Moved to). Ez az a lépés, ami után már nem tippelsz, hanem tudod, melyik sorra kell ránézni a sablonban.
3. PerformanceObserver: kilistázod magadnak a konzolba
Ha sok apró elmozdulás van, hasznos egy lista. Illeszd be a konzolba a következőt, majd töltsd újra az oldalt:
new PerformanceObserver((list) => { for (const e of list.getEntries()) { if (!e.hadRecentInput) console.log(e.value, e.sources.map(s => s.node)); } }).observe({ type: 'layout-shift', buffered: true });
A kimenetben minden sor egy elmozdulás értéke, mellette a ténylegesen mozgó elem hivatkozása, amire ráállva a böngésző kiemeli az oldalon.
4. Mezei mérési adat: Search Console és PageSpeed Insights
A laborban mért CLS a te géped, a te hálózatod és a te sütibeállításaid mellett készül. A valóság ettől eltérhet, például mert nálad már el van fogadva a sütibanner, a látogatónál nem. A Search Console Core Web Vitals jelentése (a Chrome felhasználói élmény adatbázisából, CrUX) URL-csoportokra bontva mutatja a gyenge és a javításra szoruló oldalakat, külön mobilra és asztalira. A PageSpeed Insights ugyanennek az adatnak az URL-szintű változatát mutatja a lap tetején. Praktikus sorrend: a mezei adatból derül ki, hol van baj, a laborvizsgálatból az, hogy mitől. Számíts arra, hogy a mezei adat 28 napos gördülő ablakot használ, tehát a javítás hatása nem másnap látszik.
Milyen javítási recept tartozik az egyes elemtípusokhoz?
Rövid válasz: minden recept ugyanarra a mondatra vezethető vissza: foglald le a helyet azelőtt, hogy a tartalom megérkezne.
Képek, videók, iframe-ek
Add meg a natív méretarányt attribútumként, és hagyd, hogy a CSS reszponzívvá tegye:
<img src="/kepek/termek.jpg" width="1200" height="800" alt="Termékfotó" loading="lazy">
Mellé a stíluslapba: img { max-width: 100%; height: auto; }. A modern böngészők az attribútumokból kiszámolják a képarányt, és már a letöltés előtt fenntartják a helyet. Beágyazásoknál használj arányt tartó konténert: .video-doboz { aspect-ratio: 16 / 9; width: 100%; }, és az iframe legyen width: 100%; height: 100%;. Ha az elem magassága eszközfüggő (például egy térkép), adj neki legalább min-height értéket mobilra és asztalira külön.
Betűtípusok
A font-display: swap beállítás megakadályozza a láthatatlan szöveget, de önmagában nem szünteti meg az elcsúszást, csak láthatóvá teszi a cserét. Három lépés együtt működik jól. Egy: töltsd be előre a kritikus betűváltozatot (<link rel="preload" as="font" type="font/woff2" crossorigin>). Kettő: használj woff2 formátumot és csak a ténylegesen szükséges vastagságokat. Három: hangold össze a tartalék betűt a véglegessel a size-adjust, ascent-override és descent-override tulajdonságokkal egy @font-face blokkban, hogy a csere ne változtassa meg a sortöréseket. Ha a mérés azt mutatja, hogy a szövegtörzs sokat mozog, sokszor az is védhető döntés, hogy a törzsszöveg rendszerbetűvel fut, és a saját betűtípus csak a címsorokra vonatkozik.
Sütibanner és értesítősáv
A legbiztosabb megoldás, ha a banner kikerül a dokumentum folyamából: position: fixed a képernyő aljára vagy tetejére, saját rétegen. Így megjelenéskor nem tol el semmit. Ha üzletileg mégis a folyamban kell maradnia (például mert a fejléc alatt jelenik meg), akkor a sáv helyét foglald le szerveroldali kimenetben vagy fix min-height értékkel, és csak a tartalmát töltsd be később. Ügyelj arra, hogy a lebegő sáv ne takarja el a fontos gombokat: ilyenkor adj a body aljára ugyanakkora padding-et, amekkora a sáv magassága.
Hirdetéshelyek és külső widgetek
Minden hirdetéshelynek adj rögzített méretű konténert a leggyakoribb kreatívméret alapján, például .hirdetes-hely { min-height: 280px; } mobilon és a megfelelő asztali érték desktopon. Ha a hely üresen maradhat, akkor is tartsd meg a magasságot, vagy tudatosan omlaszd össze még az első festés előtt. A külső widgetek (chat, vélemények, foglalás) esetében a legjobb, ha a látható területen kívülre kerülnek, vagy lebegő rétegen jelennek meg.
Hogyan teszteld a javítást mobilon és asztali gépen?
Rövid válasz: tesztelj lassított hálózaton, üres sütiállapotból, és nézd meg a görgetést is, ne csak a betöltést.
- Nyiss inkognitó ablakot, hogy a sütibanner és a hozzájárulási állapot úgy viselkedjen, mint egy új látogatónál.
- A fejlesztői eszközökben kapcsolj mobilnézetet (jellemzően 360 vagy 390 pixel széles), és állíts be lassítást: 4x CPU és lassú 4G hálózat.
- Kapcsold be a Layout Shift Regions kiemelést, majd tölts újra kemény frissítéssel (gyorsítótár kikapcsolva).
- Figyeld az első 5 másodpercet, majd görgess végig lassan a lap aljáig, és külön nézd meg, mi történik a lusta betöltésű elemeknél.
- Ismételd meg asztali nézetben, 1366 és 1920 pixel szélességnél is: a fejléc és a hirdetéshelyek gyakran csak az egyik töréspontnál ugranak.
- Teszteld a legfontosabb sablonokat külön: főoldal, kategória, termék vagy szolgáltatás, blogcikk, kapcsolat. A CLS sablononként viselkedik, nem oldalanként.
- Ellenőrizd a kritikus interakciókat: kosárba tétel, űrlapküldés, menü lenyitás, szűrő használata. Az interakció utáni fél másodpercen túli mozgás beleszámít.
- Futtasd le a PageSpeed Insights vizsgálatot mobilra és asztalira, és jegyezd fel a laborértéket a javítás előtt és után.
- Nézd meg a Search Console Core Web Vitals jelentését két-négy héttel a kiadás után, mert a mezei adat lassabban mozdul.
- Vedd fel a listát a kiadási ellenőrzésbe: minden új sablon, plugin vagy külső szkript után ismételd meg a kört.
Saját tapasztalat: a visszaesések többsége nem a fejlesztésből jön, hanem egy utólag beillesztett külső szkriptből (új sütikezelő, új chat, új kampánysáv). Érdemes ezért a mérést nem egyszeri projektnek, hanem visszatérő ellenőrzésnek tekinteni.
Mit érdemes elkerülni a javítás közben?
Ne próbáld a problémát azzal elfedni, hogy a teljes tartalmat elrejted, amíg minden be nem töltött. Ez a CLS-t javíthatja, viszont a látogató hosszabb ideig néz üres képernyőt, és a többi mutató romlik. Hasonlóképp kerüld az animált magasságváltozást a beszúrt elemeknél: a lassított mozgás is elmozdulás. Ha egy elem méretét tényleg nem tudod előre, akkor transform alapú animációt használj, mert az nem indít újrarendezést. Végül: a stabil elrendezés önmagában nem hoz jobb pozíciót a találati listán. A Core Web Vitals a Google saját közlése szerint az oldalélmény része, ami sok tényező egyike, tehát a javítás segítheti a teljesítményt, jó eséllyel a konverziót is, de önmagában nem eredményez helyezésváltozást.
Források és további olvasnivalók
- Google Search Central: Understanding Core Web Vitals and Google search results
- web.dev (Google): Cumulative Layout Shift (CLS) mérőszám leírása és optimalizálási útmutatója
- Chrome DevTools dokumentáció: Performance panel és Rendering (Layout Shift Regions)
- Chrome User Experience Report (CrUX) dokumentáció
- Google Search Console súgó: Core Web Vitals jelentés
- W3C Layout Instability API specifikáció
- MDN Web Docs: aspect-ratio, font-display, size-adjust, loading attribútum
- A CLS a stabilitást méri, nem a sebességet: a látogató ugyanazt érzi belőle, amit a mérőeszköz kimutat.
- A leggyakoribb okok: méret nélküli kép és beágyazás, későn váltó betűtípus, dinamikusan beszúrt sütibanner, hirdetés és értesítősáv.
- A konkrét bűnös elem Layout Shift Regions kapcsolóval, Performance felvétellel és a konzolba írt PerformanceObserverrel azonosítható.
- A javítás lényege mindig ugyanaz: foglald le előre a helyet width/height attribútummal, aspect-ratio-val vagy min-height-tal.
- A labor-mérés önmagában kevés: a Search Console mezei adata mutatja meg, mit tapasztalnak a valódi látogatók.
Gyakori kérdések
Mennyi a jó CLS-érték?
A hivatalos küszöb szerint 0,1 alatt jó, 0,1 és 0,25 között javításra szorul, 0,25 fölött gyenge. Az értékelés a valós látogatói mérések 75. percentilisén történik, tehát nem az átlagot, hanem a rosszabbul járó látogatók élményét veszi alapul.
Miért más a PageSpeed Insights és a Search Console CLS-értéke?
Mert nem ugyanazt mérik. A PageSpeed labor-része egy szimulált betöltés a mérés pillanatában, a Search Console és a PageSpeed felső blokkja pedig valós felhasználói adat 28 napos gördülő ablakban. A javítás hatása a laborértéken azonnal, a mezei adaton jellemzően hetek alatt látszik.
Elég, ha csak width és height attribútumot teszek a képekre?
Sok oldalon ez adja a javulás nagy részét, de önmagában ritkán elegendő. A betűtípus-csere, a beszúrt sütibanner, az értesítősáv és a hirdetéshelyek külön kezelést igényelnek. Érdemes a Layout Shift Regions kiemeléssel ellenőrizni, mi maradt.
Beleszámít a CLS-be, ha a felhasználó kattintására változik az elrendezés?
Nem, ha a változás az interakció után fél másodpercen belül történik. A menü lenyitása vagy egy harmonika kinyitása várt elmozdulásnak számít. Ha viszont a mozgás késve, például egy másodperccel a kattintás után következik be, akkor már beleszámít.
WordPressen mi okozza leggyakrabban a CLS-hibát?
Tapasztalat szerint a külső szkriptek: sütikezelő bővítmény, kampánysáv, chat-widget, vélemény-modul. Ezek jellemzően a betöltés után szúrnak be tartalmat a dokumentum folyamába. Ezenkívül gyakori ok a sablon saját betűtípusa és a méret nélküli, csúszkába (slider) tett képek.
Javít-e a keresési helyezésen, ha rendbe teszem a CLS-t?
Önmagában nem eredményez pozíciójavulást. A Core Web Vitals az oldalélmény jelzéseinek része, ami sok tényező egyike a rangsorolásban. A stabil elrendezés viszont közvetlenül javíthatja a használhatóságot, és jó eséllyel a konverziót is, ami üzletileg gyakran többet ér.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.