Labor-LCP

Az LCP (Largest Contentful Paint) azt méri, mennyi idő után jelenik meg a lap legnagyobb látható tartalmi eleme: többnyire a fő kép, egy videó előnézeti képe vagy egy nagy szövegblokk. A látogató ezt érzi “betöltöttnek”. A Core Web Vitals egyik mutatója, a keresők is figyelembe veszik.

Labor és valódi látogatók

Ez a teszt laborméréssel dolgozik: a riport egyetlen, szabályozott betöltést futtat (Lighthouse), mobil eszközt és lassabb hálózatot utánozva. Ez jól ismételhető és hibakeresésre kiváló, de nem azt mutatja, amit a valódi látogatók élnek át: az ő eszközük, hálózatuk, gyorsítótáruk és belépési oldaluk más. A valódi látogatók adatát a LCP, valódi látogatók teszt mutatja. A két érték eltérhet; a web.dev szerint a javítandó dolgok kiválasztásához a valódi (field) adat az irányadó, a labor a hibakereséshez és a kiadás előtti ellenőrzéshez való.

Hogyan mérjük

A riport mobilnak emulált Chrome-ban betölti a megadott oldalt, és a Lighthouse largest-contentful-paint értékét veszi. A Lighthouse alapértelmezett, szimulált lassítást használ mobilra (a dokumentáció szerint “Slow 4G” hálózat: 150 ms késleltetés, 1,6 Mbit/s letöltés, és 4-szeres processzor-lassítás). Egyetlen futás értéke, ezért futásról futásra kissé változhat.

• Megfelelő: 2500 ms vagy kevesebb.
• Hiba, közepes súlyosság: 2500 ms felett, 4000 ms-ig.
• Hiba, magas súlyosság: 4000 ms felett. Ilyenkor a riport külön, részletes kártyát is ad: A fő tartalom betöltése előbb (LCP).
• Nem mérhető: a Lighthouse nem adott értéket, vagy a betöltés csonka volt (a riport kérés-keretet ért el, és blokkolt kéréseket, így az érték hízelgő lenne).

A web.dev hivatalos határai: jó 2,5 s vagy kevesebb, gyenge 4 s felett; a riport ugyanezeket használja, nincs eltérés.

Hogyan javítsd

A web.dev az LCP-t négy részre bontja: az első bájtig tartó idő (TTFB), az erőforrás betöltésének késése, a letöltés ideje és az elem megjelenítésének késése. Először mindig a legnagyobb részt keresd meg.

1. Derítsd ki, mi a legnagyobb elem. A Chrome fejlesztői eszközeinek Performance paneljén, illetve a PageSpeed Insights jelentésében látod. Ha kép, az alábbiak segítenek; ha szöveg, a betűtípus és a CSS betöltése a fő gyanú.
2. A kép legyen az HTML-ben felfedezhető, ne csak CSS-ből vagy JavaScriptből induljon. Ha mégis CSS-háttér, tegyél elé rel="preload" sort.
3. Adj neki fetchpriority="high" attribútumot, és soha ne tegyél rá loading="lazy"-t.
4. Legyen kisebb a fájl: megfelelő méret, WebP vagy AVIF, tömörítés (lásd: Modern képformátum).
5. Gyorsítsd az első bájtot, mert minden más csak utána kezdődhet: Első bájt (TTFB).
6. Ne blokkolják a megjelenítést a szkriptek és a CSS: Renderelést blokkoló szkriptek. Ha az oldal tartalmát JavaScript rakja ki, lásd: Szerveroldali renderelés.

HTML

HTML

<img src="/kepek/hero.webp" width="1200" height="600" alt="A kép leírása" fetchpriority="high">

Csak a fő, hajtás fölötti képre tedd (többnyire a hero-kép), és azon ne legyen loading="lazy". Ha a legnagyobb elem CSS-háttérkép vagy szöveg, ez az <img>-minta nem rá vonatkozik. A fetchpriority támogatása: Chrome és Edge 102, Firefox 132, Safari 17.2 óta; régebbi böngészők figyelmen kívül hagyják, és a böngésző saját prioritáslogikája is felülírhatja.

WordPress

A WordPress 6.3 óta a lap tetején lévő tartalmi képre a mag maga is tehet fetchpriority="high" attribútumot (wp_get_loading_optimization_attributes()). A lassú hero-kép ezért többnyire a témából vagy egy oldalépítőből jön: ott kell rátenni, és azon nem lehet loading="lazy".

A részletes lépésekhez (előtöltés, preconnect, srcset-es kép) lásd a kártyát.

Hogyan ellenőrizd

• Futtasd újra a riportot, és nézd meg a Labor-LCP értékét. Egyetlen futás ingadozhat, ezért két-három mérést vess össze.
• A PageSpeed Insights mindkét adatot egy helyen mutatja: fent a valódi látogatókét, lent a laborét.
• A valódi hatás a LCP, valódi látogatók tesztben jelenik meg, de csak a következő 28 nap adatsorából.