Mi az LCP-elem, és miért egyetlen konkrét elemről beszélünk?
Hivatalosan igazolt: az LCP (Largest Contentful Paint) azt méri, mikor rajzolódik ki a nézetablakban a legnagyobb tartalmi elem: egy kép, egy videó plakátképe, egy CSS háttérkép vagy egy szövegblokk. A Google küszöbértékei szerint 2,5 másodperc alatt jó, 4 másodperc fölött gyenge, a kettő között javításra szorul, és a besorolás a 75. percentilisen történik. Nem az átlagos látogató számít tehát, hanem az, hogy a látogatók háromnegyede mit tapasztal.
Tovább a témában: Performance Max · Miért lassú a weboldalam? A négy leggyakoribb ok
Amit sokan félreértenek: az LCP nem az oldal mutatója, hanem egy elemé. Nem attól javul, hogy általánosságban gyorsítod a webhelyet, hanem attól, hogy megkeresed azt az egy elemet, és azt hozod előre az időben. Ha ez a hero kép, akkor a lábléc szkriptjeinek minifikálása vagy a kapcsolat oldal képeinek tömörítése nagyjából nulla hatással lesz rá. Ezért az első lépés soha nem a javítás, hanem az azonosítás.
Hogyan deríted ki, melyik elem az LCP az adott oldalon?
Három forrásból tudod meg, és érdemes mind a hármat használni: a PageSpeed Insights megmondja, melyik az elem, a böngésző Performance panelje megmondja, miért lassú, a valós felhasználói mérés pedig megmondja, hogy egyáltalán érdemes-e vele foglalkozni.
PageSpeed Insights: a leggyorsabb út
Futtasd le az oldalt a PageSpeed Insightsban, és görgess le a Diagnosztika részhez. A Largest Contentful Paint element bejegyzés megnevezi a konkrét elemet, sokszor a HTML-részlettel együtt. Alatta megtalálod az LCP négy szakaszra bontását is: TTFB (mikor érkezik meg a HTML első bájtja), erőforrás-felfedezési késleltetés (mikor kezd el a böngésző egyáltalán tölteni az elemet), betöltési idő és renderelési késleltetés. Saját tapasztalat: a magyar kkv-oldalak zöménél a második szakasz, a felfedezési késleltetés a legnagyobb tétel, és pont ez az, amiről a legkevesebbet beszélnek.
Chrome DevTools Performance panel: amikor a miértre vagy kíváncsi
Nyisd meg a DevToolsban a Performance fület, kapcsold be a hálózati és a CPU lassítást (mobil szimulációhoz 4x CPU lassítás és Slow 4G), majd nyomj Reloadot. A felvétel után a Timings sávban megjelenik egy LCP jelölő. Kattints rá: a Summary panelen ott lesz a konkrét DOM-elem, és a jelölőre vitt egérrel visszakövetheted, melyik hálózati kérés tartozik hozzá. A Network sávban nézd meg, hányadik kérésként indult el az adott kép. Ha a huszadik, akkor nem a fájlméret a probléma.
Mérés a valódi látogatóidon
A laborteszt csak modell. A valós adat a Google Search Console Core Web Vitals riportjából és a CrUX adatbázisból jön, illetve saját méréssel is elkaphatod. Egy minimális megoldás: new PerformanceObserver((l) => { const e = l.getEntries().at(-1); console.log(e.element, e.startTime); }).observe({type: "largest-contentful-paint", buffered: true});. Ezt a snippetet betéve a konzolba azonnal látod, mi volt az LCP-elem az adott betöltésnél.
Miért más az LCP-elem mobilon, mint asztali gépen?
Mert az LCP definíció szerint a nézetablakban látható legnagyobb elemre vonatkozik, a nézetablak pedig teljesen más a két eszközön. Egy 1440 pixel széles asztali képernyőn a hero kép mellett elfér a címsor és a gomb is, a képre esik a legnagyobb terület, tehát a kép lesz az LCP. Ugyanez a szekció mobilon gyakran átrendeződik: a kép leszűkül vagy a törésponton el is rejtőzik, a H1 címsor viszont három sorra tördelődik, és hirtelen a szövegblokk lesz a legnagyobb festett elem.
Ehhez jön, hogy mobilon lassabb a hálózat, gyengébb a processzor, és a reszponzív srcset más képfájlt tölt le. Így nemcsak az elem más, hanem a szűk keresztmetszet is: asztalon a kép bájtmérete, mobilon a JavaScript feldolgozása vagy a betűtípus-betöltés. Gyakorlati következmény: mindig mobilon kezdd a diagnózist, mert a Core Web Vitals értékelésben a mobil adat a meghatározó a legtöbb webhelynél, és mert ott a nagyobb a mozgástér.
Mit tegyél, ha az LCP-elem kép?
Rövid válasz: gondoskodj róla, hogy a böngésző a lehető legkorábban megtalálja, a lehető legkisebb méretben töltse, és semmi ne állítsa sorba mögé. Ebben a sorrendben:
- Vedd le róla a lazy loadingot. A
loading="lazy"a hero képen kifejezetten káros: a böngésző megvárja vele az elrendezés kiszámítását. Sok WordPress-sablon és optimalizáló bővítmény automatikusan minden képre ráteszi. Az első képernyőn látható képreloading="eager"való, vagy semmi. - Adj neki prioritást. A
fetchpriority="high"attribútum megmondja a böngészőnek, hogy ez a kép fontosabb, mint a többi párhuzamos kérés. Ez ma a leghatékonyabb egysoros javítás. Teljes forma:<img src="hero-1200.webp" srcset="hero-800.webp 800w, hero-1200.webp 1200w, hero-1800.webp 1800w" sizes="100vw" width="1800" height="1012" fetchpriority="high" decoding="async" alt="..."> - Ne CSS háttérképként tedd ki. A
background-imagecsak akkor derül ki, amikor a stíluslap már letöltődött és feldolgozódott, tehát egy teljes körrel később indul. Ha muszáj háttérképnek maradnia, tegyél mellé egy<link rel="preload" as="image" href="..." fetchpriority="high">sort a fejlécbe. - Méretezz reálisan. A leggyakoribb hiba, hogy egy 3000 pixel széles fotó megy ki egy 390 pixeles telefonra. Modern formátum (WebP, AVIF) plusz helyes
srcsettipikusan a bájtméret 60-80 százalékát viszi el. - Add meg a width és height attribútumot. Ez közvetlenül nem az LCP-t javítja, hanem a CLS-t, de a helyfoglalás miatt az elrendezés is korábban stabilizálódik.
Szakmai feltételezés: a hero képnél a vizuális minőség és a fájlméret közötti kompromisszum sokkal megengedőbb, mint gondolnánk. Egy 70-75 közötti WebP minőség nagy felületen is ritkán vehető észre, viszont az LCP-n mérhetően látszik.
Mit tegyél, ha az LCP-elem szöveg?
Ilyenkor felejtsd el a képeket, két dolgon múlik minden: a renderelést blokkoló CSS-en és a betűtípuson.
A böngésző addig nem fest ki semmit, amíg a fejlécben hivatkozott stíluslapokat le nem töltötte és fel nem dolgozta. Ha három bővítmény három külön CSS-fájlt tesz be, plusz jön egy ikonkészlet, az négy soros hálózati kör az első pixel előtt. Amit tenni tudsz: az első képernyőhöz szükséges szabályokat kritikus CSS-ként beágyazod a HTML-be, a többit pedig aszinkron töltöd (media="print" onload="this.media='all'" mintával), illetve kigyomlálod a fel nem használt szabályokat. A DevTools Coverage füle megmutatja, hány százalék a holt CSS.
A betűtípusnál a font-display: swap; a legfontosabb: enélkül a szöveg láthatatlan marad, amíg a betűkészlet megérkezik (ez a FOIT jelenség), és az LCP addig nem indul el. Mellé jár a <link rel="preload" as="font" type="font/woff2" crossorigin> az egy-két tényleg használt vágatra. Saját tapasztalat: nagyon sok oldal négy-hat betűvágatot tölt, miközben kettőt használ. A felesleges vágatok eltávolítása szöveges LCP-nél gyakran több tizedmásodpercet hoz, mint bármilyen szerveroldali gyorsítótár.
Mit tegyél, ha csúszka vagy videó az LCP-elem?
Csúszkánál (slider, carousel) a probléma nem az első kép, hanem a rendszer: a JavaScript könyvtár betöltődik, inicializál, kiszámolja a méreteket, majd ezután dönti el, mit mutat. Az LCP így a szkript futásához van kötve, nem a képhez. Ha mindenképp marad a csúszka, a minimum az, hogy az első dia képe statikus HTML-ként szerepeljen a forrásban (nem JS-ből beszúrva), fetchpriority="high" attribútummal, a többi dia képe pedig lusta betöltésű legyen, és a csúszka szkriptje halasztva (defer) töltődjön.
Videónál a <video> elem poster attribútumában megadott kép számít LCP-jelöltnek, ezért ezt a képet kezeld úgy, mint egy hero képet: kicsi, modern formátumú, előre betöltött. Az automatikusan induló háttérvideót mobilon érdemes teljesen kikapcsolni és statikus képpel helyettesíteni, mert a sávszélességet elveszi az összes többi erőforrás elől. Beágyazott YouTube- vagy Vimeo-lejátszónál a facade minta (kattintásra betöltődő álképernyő) egyszerre javítja az LCP-t és a fő szál terhelését.
Tényleg ennyire rossz a hero csúszka?
Saját tapasztalat, nem hivatalos állásfoglalás: igen, a hero csúszka szinte mindig ront az LCP-n, és ritkán hoz cserébe mérhető konverziót. Két külön okról van szó, amit érdemes szétválasztani.
A technikai ok fentebb szerepel: a csúszka JS-függővé teszi az oldal legfontosabb vizuális elemét, és három-öt nagy képet tölt le abból, amiből egyet néznek meg. A használhatósági ok ennél régebbi: a látogatók a mozgó, automatikusan váltó felületet hajlamosak hirdetésnek nézni és átugrani, a második és további diákra jutó kattintás pedig jellemzően a töredéke az elsőnek. Ez a jelenség a szakmai szakirodalomban (például a Nielsen Norman Group anyagaiban) évek óta visszatérő megfigyelés.
A gyakorlati javaslat: ha a csúszkára azért van szükség, mert több osztály vagy több érdekelt fél akarja a saját üzenetét az első képernyőn, akkor ez nem technikai, hanem szervezeti probléma. A megoldás egy statikus hero, egy tiszta ajánlattal és egy elsődleges gombbal, alatta pedig a többi üzenet külön szekcióban. Ez a változtatás önmagában nem garantál jobb konverziót, de az LCP-n jó eséllyel azonnal látszik, és az A/B teszt is egyszerűbbé válik.
Milyen sorrendben javíts? Öt lépés a legnagyobb hatástól a legkisebbig
- Szüntesd meg az LCP-elem függőségét a JavaScripttől. Ha csúszka, felugró elem, animációs könyvtár vagy kliensoldali renderelés dönti el, mi jelenik meg az első képernyőn, ez a legnagyobb tétel. A hero legyen statikus HTML a forrásban.
- Zárd le a felfedezési késleltetést. Lazy loading le a hero képről,
fetchpriority="high"fel, CSS háttérkép helyett<img>vagy preload. Ez tipikusan néhány sor, és a legjobb megtérülésű beavatkozás. - Vidd le a bájtokat. Helyes méretezés, WebP vagy AVIF, működő
srcsetéssizes. Itt már a hálózat sebességétől függ a nyereség, de mobilon jelentős. - Tisztítsd a renderelési útvonalat. Blokkoló CSS csökkentése, kritikus CSS beágyazása,
font-display: swap;, felesleges betűvágatok és külső szkriptek (chat widget, hőtérkép, több analitika) halasztása vagy kidobása. - Nézd meg a szervert. Gyorsítótárazás, oldalgyorsító bővítmény, CDN, PHP-verzió, adatbázis-lekérdezések. Fontos kivétel: ha a PageSpeed Insights TTFB-értéke 800 ezredmásodperc fölött van, akkor ez a pont felugrik az első helyre, mert addig hiába gyorsítod a képet, a HTML sem érkezett meg.
Hogyan ellenőrzöd, hogy tényleg jobb lett?
Egy javítás akkor kész, ha a mérés is visszaigazolja. Rövid ellenőrzőlista:
- Ugyanazon az URL-en, mobil nézetben mérj újra, lehetőleg kétszer, és a rosszabbat vedd figyelembe.
- Nézd meg, hogy az LCP-elem ugyanaz maradt-e. Ha megváltozott, a probléma nem eltűnt, hanem átköltözött.
- A DevTools Network paneljén ellenőrizd, hogy a hero kép a legelső néhány kérés között indul-e el.
- Ellenőrizd, hogy a gyorsítótárazó bővítmény frissítés után nem tette-e vissza a lazy loadingot a hero képre. Saját tapasztalat: ez a leggyakoribb visszaesési ok.
- Négy-nyolc hét múlva nézd meg a Search Console Core Web Vitals riportját. A valós felhasználói adat lassan mozdul, a laborérték azonnal, és ez a különbség a leggyakoribb félreértés forrása.
Az LCP nem varázslat, hanem könyvelés: valaki mindig fizet az időért. Ha tudod, melyik elem az, és ki állítja sorba, a többi már mérnöki munka.
Források és további olvasnivalók
- Google Search Central: Core Web Vitals és oldalélmény dokumentáció
- web.dev: Largest Contentful Paint (LCP) útmutató és LCP-alrészekre bontás
- W3C: Largest Contentful Paint API specifikáció
- Chrome for Developers: DevTools Performance panel dokumentáció
- MDN Web Docs: fetchpriority, loading attribútum, font-display
- Chrome UX Report (CrUX) dokumentáció
- HTTP Archive: Web Almanac, teljesítmény és médiafejezetek
- Nielsen Norman Group: karusszelekkel és automatikusan váltó tartalommal kapcsolatos használhatósági anyagok
- Az LCP egyetlen elem megjelenési ideje, ezért a javítás első lépése mindig az elem azonosítása, nem a tömörítés.
- Mobilon szinte mindig más az LCP-elem, mint asztali gépen, és a Core Web Vitals értékelés a mobil adatot súlyozza a legjobban.
- Hero képnél a felfedezési késleltetés (lazy loading, CSS háttérkép, JS-ből betöltött kép) többet árt, mint maga a fájlméret.
- Szöveges LCP-nél a renderelést blokkoló CSS és a betűtípus-betöltés a két valódi fék, nem a szerver.
- A hero csúszka a tapasztalatunk szerint szinte mindig ront az LCP-n, és ritkán hoz cserébe mérhető konverziót.
Gyakori kérdések
Mennyi idő alatt kell betöltődnie az LCP-elemnek?
A Google hivatalos küszöbe szerint 2,5 másodperc alatt jó az érték, 4 másodperc fölött gyenge, a kettő között javításra szorul. A besorolás a látogatók 75. percentilisén történik, tehát nem az átlagos, hanem a rosszabbul járó felhasználók tapasztalata számít.
Miért mutat mást a PageSpeed Insights, mint a Search Console?
A PageSpeed Insights laborteszt: egy szimulált eszközön, egy adott pillanatban mér. A Search Console és a CrUX valós látogatók 28 napos adatát összesíti. Egy javítás a laborban azonnal látszik, a valós adatban jellemzően négy-nyolc hét alatt jelenik meg.
Elég, ha csak tömörítem a hero képet?
Sokszor nem. Ha a kép későn indul el (lazy loading, CSS háttérkép, JavaScriptből beszúrt elem), akkor a kisebb fájl is későn kezd tölteni. Először a felfedezési késleltetést kell megszüntetni, és csak utána érdemes a bájtokkal foglalkozni.
Rakjak fetchpriority="high" attribútumot minden képre?
Nem. A prioritás relatív: ha mindennek magas, akkor semminek. Egyetlen elemre tedd, arra, amelyik a mérés szerint valóban az LCP-elem az adott sablonon, jellemzően mobilon.
Mi legyen a hero csúszkával, ha az ügyfél ragaszkodik hozzá?
Minimum az, hogy az első dia képe statikus HTML-ként szerepeljen a forrásban, magas prioritással, a többi dia lustán töltődjön, a csúszka szkriptje pedig halasztva. Emellett érdemes felajánlani egy statikus hero változatot A/B tesztre, mert a csúszka konverziós haszna a tapasztalatunk szerint gyakran nem mutatható ki.
Javít az LCP a keresési helyezésen?
A Core Web Vitals a Google által megerősített rangsorolási jelzés, de kis súlyú, és a tartalmi relevancia nem helyettesíthető vele. Jobb LCP segítheti a helyezést és mérhetően csökkentheti a visszafordulást, de önmagában nem garantál pozíciójavulást.
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.