LCP: teljes útmutató

Az LCP (Largest Contentful Paint) azt méri, mennyi idő telik el az oldal betöltésének kezdetétől addig, amíg a nézetben látható legnagyobb kép vagy szövegblokk megjelenik. A Core Web Vitals egyik mutatója, a betöltési élményt írja le. Jó értéknek a 2,5 másodperc vagy kevesebb számít, a látogatások 75. percentilisén mérve, mobilon és asztalon külön.

Alapfogalmak

Az LCP a felhasználó szemszögéből nézi a betöltést. A régebbi mutatók, például a teljes betöltés ideje vagy a DOMContentLoaded esemény, technikai pillanatokat jelöltek, amelyek gyakran semmit nem mondtak arról, mikor látja a látogató a lényeget. Az LCP ehelyett azt a pillanatot rögzíti, amikor a nézet legnagyobb tartalmi eleme kirajzolódik. A gondolat egyszerű: ha a legnagyobb elem már látszik, a látogató jó eséllyel úgy érzi, hogy az oldal betöltött, és elkezdheti használni.

A mutató a Core Web Vitals három eleme közül az egyik. A másik kettő az interakciós válaszkészséget mérő INP és a vizuális stabilitást mérő CLS. A három együtt a Google oldalélmény-jelzéseinek része. Az LCP tehát nem önálló rangsorolási csodaszer, hanem egy mérhető minőségi jelzés, amely mellett a tartalom relevanciája továbbra is sokkal nagyobb súlyú.

Mely elemek lehetnek LCP-elemek?

A böngésző nem minden elemet vesz figyelembe. A specifikáció szerint az LCP-jelöltek köre szűk, és ez sok félreértést tisztáz:

Képek, vagyis az img elemek.
SVG-n belüli image elemek.
Videók poszterképe, illetve a videó első megjelenített képkockája.
CSS háttérképek, ha url() függvénnyel töltődnek be.
Szöveget tartalmazó blokkszintű elemek, például egy nagy címsor vagy bekezdés.

Az elem méretét a nézetben látható része alapján számolja a böngésző. Ha egy kép nagyobb, mint a képernyő, csak a látható terület számít. Ha egy képet a CSS kisebbre méretez, mint a természetes mérete, a kisebb érték számít. A margó, a kitöltés és a szegély nem része a méretnek.

A küszöbértékek

Minősítés	LCP érték	Mit jelent a gyakorlatban
Jó	2,5 másodperc vagy kevesebb	A fő tartalom gyorsan megjelenik, nincs teendő
Javítandó	2,5 és 4 másodperc között	Érdemes megkeresni a legnagyobb késleltetési részt
Gyenge	4 másodperc felett	A látogató érezhetően vár, a javítás prioritás

A minősítés nem egyetlen mérésre vonatkozik. A Google a valós látogatásokból gyűjtött adatok 75. percentilisét nézi, vagyis akkor jó egy oldal, ha a látogatások legalább háromnegyedében teljesül a küszöb. Ez szándékos: a lassú eszközök és gyenge hálózatok is beleszámítanak, ezért egy gyors fejlesztői gépen mért szép érték még nem garancia.

Laboratóriumi és terepi LCP

Az LCP-t kétféleképpen lehet mérni. A laboratóriumi mérés egy szimulált környezetben tölti be az oldalt, rögzített eszközzel és hálózattal. Ez jól ismételhető, ezért hibakeresésre kiváló. A terepi mérés a valódi látogatók böngészőiből származik, és azt mutatja, amit a felhasználók ténylegesen tapasztalnak. A kettő gyakran eltér, és ez nem hiba: a laborban nincs gyorsítótár, nincs bejelentkezett állapot, nincs sütisáv, a terepen viszont mindez előfordul. A keresőt a terepi adat érdekli, a fejlesztőt a labor segíti.

Hogyan működik?

A böngésző a betöltés során folyamatosan figyeli, melyik a legnagyobb tartalmi elem a nézetben. Amikor egy új elem kirajzolódik, a böngésző egy bejegyzést készít róla. Ha később megjelenik egy még nagyobb elem, új bejegyzés születik, és az lesz az aktuális jelölt. Egy tipikus oldalon először a címsor lehet a legnagyobb elem, majd amikor a fő kép betöltődik, az veszi át a helyét. Az LCP értéke az utolsó jelölt megjelenésének ideje.

A figyelés nem tart örökké. Amint a felhasználó interakcióba lép az oldallal, például kattint, koppint vagy billentyűt nyom, a böngésző leállítja az új jelöltek rögzítését. A görgetés is ilyen interakciónak számít. Ennek oka, hogy a felhasználói művelet után megjelenő új tartalom már nem a betöltésről szól, hanem az interakció következménye.

Az LCP négy része

A javítás kulcsa, hogy az LCP időt részekre bontjuk. A Google fejlesztői dokumentációja négy részt különít el, és mindegyiknek más a gyógymódja:

Az első bájtig eltelt idő (TTFB). A navigáció kezdetétől addig, amíg a HTML első bájtja megérkezik. Ide tartozik a DNS-feloldás, a kapcsolat felépítése, az átirányítások és a szerveroldali feldolgozás.
Az erőforrás betöltésének késése. A TTFB végétől addig, amíg a böngésző elkezdi letölteni az LCP-elem erőforrását, például a képet. Ha a kép csak egy későn futó szkriptből derül ki, ez a rész hosszú lesz.
Az erőforrás letöltésének ideje. Maga a letöltés. Ezt a fájlméret és a hálózat határozza meg.
Az elem kirajzolásának késése. A letöltés végétől a megjelenésig. Ha a fő szál más munkával van elfoglalva, vagy renderblokkoló CSS és JavaScript tartja vissza a rajzolást, ez a rész nő.

Szöveges LCP-elemnél nincs letöltendő erőforrás, ha a betűtípus már rendelkezésre áll, így a második és harmadik rész elmarad vagy nagyon rövid. Ilyenkor a TTFB és a kirajzolási késés dominál. Képes LCP-nél viszont mind a négy rész szerepet kap, és a tapasztalat szerint a gyenge értékek gyakran a TTFB-ből és a betöltési késésből jönnek, nem magából a letöltésből.

Miért számít a felfedezhetőség?

A böngésző előtöltő szkennere a HTML-t már az elemzés közben átfutja, és korán elkezdi letölteni az ott talált képeket. Ha az LCP-kép közvetlenül a HTML-ben van egy img elemben, src vagy srcset attribútummal, a szkenner hamar megtalálja. Ha a kép CSS háttérképként egy külső stíluslapban van, vagy JavaScript szúrja be, a böngésző csak később tud róla, és a betöltési késés megnő. Ezért a felfedezhetőség gyakran fontosabb, mint a fájlméret.

Kidolgozott példa: egy webáruház kategóriaoldala

Egy webáruház kategóriaoldalán a mobilos terepi LCP a javítandó sávban volt. A laboratóriumi mérés megmutatta, hogy az LCP-elem a fejléc alatti szalagkép. A részekre bontás szerint a TTFB rendben volt, a letöltés is gyors, de a betöltési késés hosszú: a szalagképet egy csúszka szkriptje szúrta be, miután betöltődött. Ráadásul a képen lazy loading attribútum volt. A javítás három lépésből állt. A csúszka első képe bekerült a HTML-be sima img elemként, lekerült róla a lusta betöltés, és magas letöltési prioritást kapott. A következő laboratóriumi mérésben a betöltési késés gyakorlatilag eltűnt, a terepi adat pedig a következő hetekben fokozatosan javult, ahogy az új látogatások felváltották a régieket.

Fő módszerek

Az LCP javításának nincs egyetlen receptje, mert a négy rész közül mindig az a legfontosabb, amelyik a legtöbb időt viszi. A helyes sorrend ezért: először mérni, melyik rész a leghosszabb, utána arra a részre célzott módszert alkalmazni. Az alábbi módszerek részenként csoportosítva mutatják a lehetőségeket.

A TTFB csökkentése

Szerveroldali gyorsítótár. Ha a HTML-t nem kell minden kérésre újragenerálni, a szerver sokkal gyorsabban válaszol. A cache beállítása gyakran a leggyorsabb nyereség.
CDN. A CDN a látogatóhoz közelebbi pontról szolgálja ki a tartalmat, és rövidíti a kapcsolat felépítését.
Átirányítások kerülése. Minden átirányítás egy újabb oda-vissza kör a szerverrel. A belső linkek mutassanak közvetlenül a végleges URL-re.
Lassú háttérlekérdezések javítása. Adatbázis-lekérdezések, külső API-hívások a HTML előállítása közben.

A betöltési késés megszüntetése

Az LCP-kép legyen a HTML-ben felfedezhető. Ha ez nem oldható meg, például mert a kép háttérképként kell, hogy megjelenjen, egy preload hivatkozás a dokumentum fejében korán jelezheti a böngészőnek. A fetchpriority="high" attribútum az img elemen azt kéri a böngészőtől, hogy a képet a többi kép előtt töltse le. Ez különösen akkor hasznos, ha az oldalon sok kép van, és a böngésző alapból nem tudná, melyik a fontos.

A leggyakoribb és legkönnyebben javítható hiba a lusta betöltés rossz használata. A lazy loading a hajtás alatti képeknél hasznos, de az LCP-képnél késlelteti a letöltést, mert a böngésző csak akkor kezdi el, amikor megállapította, hogy a kép a nézetben van. Az első képernyőn látható fő képről ezért le kell venni a loading="lazy" attribútumot.

A letöltési idő rövidítése

Modern képformátumok. A WebP és az AVIF általában kisebb fájlt ad hasonló minőségben.
Reszponzív képek. A srcset és a sizes attribútum segítségével a mobil ne töltse le az asztali méretű képet.
Tömörítés. A kép minőségi beállítása gyakran csökkenthető látható romlás nélkül.
Ugyanarról a kiszolgálóról. Ha a kép külön domainről jön, új kapcsolatot kell felépíteni. Ilyenkor a preconnect segíthet.

A kirajzolási késés csökkentése

Ha a kép már megérkezett, de még nem látszik, a fő szál vagy a renderblokkoló erőforrások a hibásak. A kritikus CSS beágyazása a HTML-be, a többi stílus késleltetett betöltése, és a nem szükséges JavaScript defer vagy async betöltése mind ezt a részt rövidíti. Kliensoldali renderelésnél a teljes tartalom csak a szkriptek lefutása után jelenik meg, ezért ilyen oldalaknál a szerveroldali renderelés vagy az előre generált HTML gyakran látványos javulást hoz. A részletekért lásd a kliensoldali renderelés útmutatót is.

Döntési szabály

Ha a leghosszabb rész	Akkor először ezt nézd
TTFB	Szerveroldali gyorsítótár, CDN, átirányítások, háttérlekérdezések
Betöltési késés	Felfedezhetőség a HTML-ben, lazy loading eltávolítása, fetchpriority, preload
Letöltési idő	Formátum, méretezés, tömörítés, külső domain
Kirajzolási késés	Renderblokkoló CSS és JavaScript, kliensoldali renderelés, hosszú feladatok

Gyakori hibák

Az LCP-vel kapcsolatos hibák nagy része nem technikai tudáshiányból fakad, hanem abból, hogy a csapat nem azt méri, amit a látogató tapasztal, vagy nem azt az elemet optimalizálja, amelyik ténylegesen az LCP-elem. Az alábbi hibák visszatérően előfordulnak.

Lusta betöltés a fő képen

Sok tartalomkezelő és sablon minden képre automatikusan ráteszi a loading="lazy" attribútumot. Ez a hajtás alatti képeknél jó, a fő képnél viszont az LCP egyik legismertebb rontója. A javítás egyszerű, de gyakran sablonszinten kell elvégezni, mert kézzel minden oldalon nem kivitelezhető.

Rossz elem optimalizálása

Gyakori, hogy a csapat a fejléc logóját vagy egy dekoratív képet tömörít, miközben az LCP-elem valójában egy nagy címsor vagy egy szalagkép. Mielőtt bármit javítanál, nézd meg a mérőeszközben, melyik elem az LCP-elem az adott oldaltípuson, mobilon és asztalon külön, mert a kettő eltérhet.

Csak laboratóriumi mérésre hagyatkozás

Egy szép laboratóriumi érték nem jelenti, hogy a terepi adat is jó. Ha a látogatók jelentős része lassú mobilhálózaton érkezik, vagy a sütisáv, a bejelentkezési állapot és a személyre szabott tartalom más LCP-elemet ad, a terepi érték rosszabb lehet. Fordítva is igaz: a laborban lassú oldal a valóságban gyorsabb lehet a gyorsítótár miatt.

Tévhit: a fájlméret a legfontosabb

Sokan azt hiszik, hogy az LCP javítása egyenlő a képek tömörítésével. A részekre bontás gyakran mást mutat: a letöltési idő rövid, a TTFB és a betöltési késés viszont hosszú. Ilyenkor a tömörítés alig hoz eredményt. Az ellenpélda a fenti webáruház: a kép kicsi volt, mégis későn jelent meg, mert a böngésző későn tudott róla.

További visszatérő hibák

Szkript által beszúrt szalagkép vagy csúszka, amely csak a JavaScript lefutása után jelenik meg.
Az A/B tesztelő eszköz elrejtő szkriptje, amely a teszt betöltéséig láthatatlanná teszi az oldalt.
Webes betűtípus, amely blokkolja a szöveg megjelenítését, ha a font-display beállítás nem engedi a tartalék betűtípust.
Átirányítási lánc a céloldal előtt, például kampánylinkeknél, amely minden lépéssel növeli a TTFB-t.
Túl sok magas prioritású erőforrás, amely miatt a prioritás elveszti az értelmét.

Mérés

Az LCP mérése két rétegű. A terepi adat megmondja, van-e probléma és hol, a laboratóriumi adat megmondja, miért. A jó munkafolyamat a terepi adatból indul, a laborban diagnosztizál, majd a terepi adatban ellenőrzi az eredményt. A terepi adatok halmozottak, ezért egy javítás hatása csak fokozatosan látszik bennük.

Eszközök és szerepük

Eszköz	Adattípus	Mire jó
Search Console, Core Web Vitals jelentés	Terepi	Oldalcsoportok szerint mutatja, hol van gyenge vagy javítandó LCP
PageSpeed Insights	Terepi és laboratóriumi	Egy URL terepi adata, ha van elég, és egy Lighthouse-futtatás diagnosztikával
Chrome UX Report	Terepi	A Chrome-felhasználók összesített adatai, történeti elemzésre
Chrome fejlesztői eszközök, Performance panel	Laboratóriumi	Megmutatja az LCP-elemet és a részek idejét
Lighthouse	Laboratóriumi	Ismételhető mérés, javaslatokkal
Saját valós felhasználói mérés	Terepi	A web-vitals könyvtárral gyűjtött adat, oldaltípusra és elemre bontva

Munkafolyamat lépésről lépésre

A Search Console jelentésében keresd meg azokat az URL-csoportokat, ahol az LCP gyenge vagy javítandó.
Válassz egy jellemző URL-t a csoportból, és nézd meg a PageSpeed Insightsban a terepi és a laboratóriumi adatot.
Azonosítsd az LCP-elemet mobilon és asztalon.
Bontsd részekre az LCP-t a fejlesztői eszközökben, és keresd meg a leghosszabb részt.
Alkalmazd a részhez tartozó módszert, lehetőleg sablonszinten, hogy az egész oldalcsoportra hasson.
Ellenőrizd a laborban, hogy a rész rövidült.
Kövesd a terepi adatot a következő hetekben. A Search Console-ban az érvényesítés indítható.

Kidolgozott példa: blog szöveges LCP-vel

Egy szakmai blog cikkoldalain mobilon a nagy címsor volt az LCP-elem. A terepi adat javítandó értéket mutatott, pedig a cikkekben kevés kép volt. A laboratóriumi mérés szerint a TTFB hosszú volt, mert a szerver minden kérésre újragenerálta az oldalt, a kirajzolást pedig egy külső betűtípus visszatartotta. A csapat bekapcsolta az oldalgyorsítótárat, és a betűtípusnál a font-display: swap beállítást használta, hogy a szöveg tartalék betűtípussal azonnal megjelenhessen. A labor mindkét rész rövidülését mutatta. Ez a példa azt is mutatja, hogy szöveges LCP-elemnél a képoptimalizálás semmit nem ért volna.

Mire figyelj a terepi adatnál?

Ha egy URL-nek nincs elég forgalma, a terepi adat az URL helyett a teljes forrásra vonatkozhat, vagy teljesen hiányozhat. Ilyenkor a saját valós felhasználói mérés adhat pontosabb képet. Az LCP értéke az oldal típusától is függ: egy termékoldal és egy blogcikk más elemet jelenít meg elsőként, ezért az adatokat oldaltípusonként érdemes elemezni. A változtatás hatását mindig a saját korábbi értékekhez mérd, ne egy másik webhelyhez.

Ellenőrzőlista

Tudod, melyik elem az LCP-elem a fő oldaltípusokon, mobilon és asztalon?
Az LCP-kép közvetlenül a HTML-ben van, lusta betöltés nélkül?
Van rajta fetchpriority="high", ha az oldalon sok kép van?
A TTFB rendben van, és nincs átirányítás a céloldal előtt?
A kép megfelelő formátumú és méretű a mobil nézethez?
Nincs renderblokkoló szkript, amely visszatartja a kirajzolást?
A terepi adat a 75. percentilisen a jó sávban van?