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

> Lépésenkénti útmutató, ha a legnagyobb tartalmi elem 4 másodperc után jelenik meg: előtöltés, fetchpriority, lusta betöltés tiltása, gyors első bájt.

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](https://hub.hellowp.io/hu/report/teljesitmeny/labor-lcp/) vagy az [LCP, valódi látogatók](https://hub.hellowp.io/hu/report/teljesitmeny/lcp-valodi-latogatok/) é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](https://hub.hellowp.io/hu/knowledge-base/useful-tools/pagespeed-insights/) is megnevezi.
2. **Gyorsítsd az első bájtot.** Ha a [TTFB](https://hub.hellowp.io/hu/report/teljesitmeny/elso-bajt-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](https://hub.hellowp.io/hu/report/teljesitmeny/modern-kepformatum/)).
6. **Ne késleltesd a megjelenítést:** a renderelést blokkoló szkriptek és CSS ([Renderelést blokkoló szkriptek](https://hub.hellowp.io/hu/report/teljesitmeny/renderelest-blokkolo-szkriptek/)), valamint a csak JavaScripttel renderelt tartalom ([Szerveroldali renderelés](https://hub.hellowp.io/hu/report/teljesitmeny/szerveroldali-rendereles/)) sokat ront.

### HTML

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

```html title="HTML (head)"
<link rel="preload" as="image" href="/kepek/hero.webp" fetchpriority="high">
```

```html title="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](https://hub.hellowp.io/hu/report/teljesitmeny/lcp-valodi-latogatok/).
- A Chrome fejlesztői eszközeinek Network füle mutatja, hogy a hero-kép korán, magas prioritással indul-e.