A fő tartalom betöltése előbb (LCP)

Ezt a javítási kártyát a riport akkor adja, ha a legnagyobb tartalmi elem (LCP) a Google 4 másodperces “gyenge” határa fölött jelenik meg, akár a laborméréssel, akár a valódi látogatóknál. A kártya mindig a nagyobb értékből indul, és megmondja, melyik mérésből jön. Így néz ki a döntés a riport kódjában: ha a Labor-LCP vagy az LCP, valódi látogatók értéke 4000 ms fölött van, ez a kártya jelenik meg magas súlyossággal.

Labor és valódi látogatók

Ha az érték laborból jön, a hiba egy szabályozott, mobilnak emulált Lighthouse-futásban jelent meg; ha valódi látogatókból (CrUX, 28 nap, 75. percentilis), akkor a valódi Chrome-felhasználók tapasztalata. A kettő eltérhet, mert a valódi látogatók eszköze, hálózata és belépési oldala változatos; a web.dev szerint a javítandók kiválasztásához a valódi adat az irányadó, a labor hibakeresésre való.

Hogyan mérjük

A kártya akkor jelenik meg, ha a Labor-LCP vagy az LCP (valódi látogatók) értéke szigorúan nagyobb 4000 ms-nál. Ha mindkettő az, a nagyobbat használja. Ha az első bájt (TTFB) is lassú, a kártya külön jelzi, és azt javasolja előbb javítani, mert a fő tartalom csak utána kezdhet betöltődni.

Hogyan javítsd

A web.dev az LCP-t négy részre bontja: 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. Az utasítások ennek megfelelően haladnak.

1. Derítsd ki, mi a legnagyobb elem. A Chrome fejlesztői eszközeiben a Performance panel mutatja az LCP-elemet és a részidőket; a PageSpeed Insights is megnevezi.
2. Gyorsítsd az első bájtot. Ha a TTFB lassú, azzal kezdd: kevesebb átirányítás, a gyorsítótárazott oldal kiszolgálása.
3. Tedd az LCP-képet felfedezhetővé az induló HTML-ben. Ha csak CSS-ből vagy JavaScriptből töltődik be, a böngésző későn találja meg; ilyenkor előtöltés kell.
4. Jelöld meg fetchpriority="high" attribútummal, és soha ne tegyél rá loading="lazy"-t. Egy-két képnél többre ne tedd.
5. Csökkentsd a letöltendő méretet: megfelelő felbontás, WebP vagy AVIF (Modern képformátum).
6. Ne késleltesd a megjelenítést: a renderelést blokkoló szkriptek és CSS (Renderelést blokkoló szkriptek), valamint a csak JavaScripttel renderelt tartalom (Szerveroldali renderelés) sokat ront.

HTML

Előtöltés a <head>-ben, és ugyanaz a kép a törzsben:

HTML (head)

<link rel="preload" as="image" href="/kepek/hero.webp" fetchpriority="high">

HTML (törzs)

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

• A href a hero-kép címe, ugyanaz, mint az <img>-ben. Ha a kép másik domainről jön (például CDN-ről), a teljes https:// cím kerüljön ide, és egy <link rel="preconnect" href="https://…"> sor a kép domainjére is segít; saját domainről jövő képnél erre nincs szükség.
• Ha az <img>-nek van srcset-je, a preloadba ugyanaz kerüljön imagesrcset és imagesizes attribútumként, hogy pontosan azt a fájlt töltse elő, amelyiket a kép használ. A web.dev szerint az előtöltést az HTML-ben add meg, ne Link: fejlécben, mert a fejléces változat nem biztos, hogy kezeli a reszponzív képet.
• Csak a fő, hajtás fölötti képre tedd (többnyire a hero-kép). Ha a legnagyobb elem CSS-háttérkép vagy szöveg, ez az <img>-minta nem rá vonatkozik; háttérképnél a preload kapja a fetchpriority="high" attribútumot.
• A fetchpriority támogatása: Chrome és Edge 102, Firefox 132, Safari 17.2 óta; mivel csak javaslat a böngészőnek, mérd meg a hatását.

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()), ezért a lassú hero-kép többnyire a témából vagy egy oldalépítőből jön: ott tedd rá, és azon ne legyen loading="lazy".
• A preload sort csak arra az oldalra tedd, ahol a hero-kép van: a header.php-ban például egy <?php if ( is_front_page() ) : ?> … <?php endif; ?> feltételbe, különben minden oldalon kimegy. A WordPress 6.1 óta a wp_preload_resources szűrő is használható (a fetchpriority kulcs 6.6 óta).

Hogyan ellenőrizd

• Futtasd újra a riportot: a Labor-LCP-nek 4 s alá, majd 2,5 s alá kell kerülnie.
• A valódi látogatók adata (CrUX) 28 napos gördülő időszakot használ, ezért a teljes hatás hetek alatt látszik: LCP, valódi látogatók.
• A Chrome fejlesztői eszközeinek Network füle mutatja, hogy a hero-kép korán, magas prioritással indul-e.