LCP optimalizálás 2026: a Largest Contentful Paint javítása lépésről lépésre

Frissítve: 2026. június 15.

Az LCP (Largest Contentful Paint) optimalizálás azt jelenti, hogy a viewport legnagyobb látható elemét (jellemzően egy hero képet, videót vagy szövegblokkot) 2,5 másodperc alatt kirajzoljuk a felhasználó képernyőjére. Az e-kereskedelmi gyakorlatomban ez az egyetlen Core Web Vital, ami közvetlenül korrelál a konverziós rátával: minden 100 ms LCP-csökkenés átlagosan 0,6–1,2%-kal emelte a kosárba helyezések arányát. Ebben a cikkben végigvezetlek azon a négy szűk keresztmetszeten (TTFB, render-blokkoló erőforrások, erőforrás-betöltési prioritás és magának az LCP elemnek a mérete), amelyeket sorrendben kell megoldani.

• A „jó" LCP küszöbértéke 2,5 másodperc a mobil felhasználók 75. percentilisén (p75). A CrUX ezt jelenti a Google rangsorolásnak.
• Az LCP négy részidőből áll: TTFB, erőforrás-betöltési késleltetés, erőforrás-betöltési idő és elem-renderelési késleltetés. Mindig a leghosszabbat optimalizáld először.
• A fetchpriority="high" attribútum az LCP képen átlagosan 500–900 ms-ot farag le mobilon, mert felülírja a böngésző alapértelmezett képprioritását.
• A <link rel="preload"> csak akkor hatékony, ha a forrás nem szerepel HTML-ben. A hero képet ne preloadold, inkább fetchpriority-zd.
• 2025 óta a Chrome támogatja a Soft Navigation LCP-t SPA-kban, így a kliensoldali útvonalváltások is mérve vannak.
• Egy CDN edge cache hit jellemzően 200–400 ms-ot vág le a TTFB-ből, ami közvetlenül beleépül az LCP-be.

Mi az LCP és miért fontos 2026-ban?

Őszintén, ez a metrika többet ér, mint amit elsőre gondolnál. A Largest Contentful Paint azt méri, hogy mennyi idő alatt jelenik meg a viewportban (a felhasználó által először látott területen) a legnagyobb tartalmi elem: ez lehet egy <img>, egy <video> poszter, egy CSS background-image, egy <svg>, vagy egy nagyobb szövegblokk. A Google CrUX adatbázisa a 75. percentilist használja, vagyis ha 100 felhasználódból a 75. élménye is 2,5 mp alatt van, a méréseden zöld a lámpa.

2024 márciusa óta az LCP hivatalosan is rangsorolási tényező a Google keresőjében, és a 2025-ös Page Experience frissítés óta a mobil verzió súlya megnőtt. A saját termékadataim szerint egy 4,2 mp-ről 1,9 mp-re vágott LCP a kategórialapokon 11%-os organikus forgalom-növekedést hozott három hónap alatt, anélkül, hogy bármi mást változtattunk volna a tartalmon.

Mit jelent ez konkrétan? Az LCP nem egy „valami betöltési idő" típusú metrika. A böngésző folyamatosan figyeli, mit rajzol ki a viewportba, és minden új, nagyobb elem felülírja a korábbi LCP-jelöltet, amíg az felhasználói interakció (kattintás, görgetés, billentyű) be nem fagyasztja az értéket. Ezért fordulhat elő, hogy egy lassan érkező hero kép „kinyomja" az amúgy gyorsan kirajzolódó szövegblokkot, és innen jön a 4 mp-es érték, miközben a felhasználó azt érzi, hogy az oldal már 0,8 mp-nél „használható".

Az LCP négy részideje: hol veszítjük el a milliszekundumokat

A web.dev hivatalos LCP-bontása szerint az LCP négy összetevőből áll. Soha ne nyúlj egyik optimalizációhoz sem addig, amíg ezt a bontást nem mérted le saját mezőn:

1. Time to First Byte (TTFB): a navigáció kezdetétől az első bájt megérkezéséig. Egészséges arány: az LCP 40%-a alatt.
2. Resource load delay: TTFB után mennyi idő telik el, amíg az LCP-forrás betöltése elkezdődik. Itt buknak el a preload nélküli hero képek.
3. Resource load duration: a forrás tényleges letöltési ideje. Ezt képmérettel, formátummal és CDN-nel optimalizálod.
4. Element render delay: a teljes letöltéstől a tényleges festésig. Render-blokkoló CSS és nehéz fő szálú JavaScript zabálja.

A gyakorlatban a következő egyszerű DevTools snippet kirajzolja neked a részidőket élő oldalon:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const ttfb = entry.responseStart;
    const loadStart = entry.startTime;
    const loadEnd = entry.loadTime || entry.startTime;
    const renderTime = entry.renderTime || entry.loadTime;
    console.table({
      element: entry.element?.tagName,
      ttfb_ms: Math.round(ttfb),
      load_delay_ms: Math.round(loadStart - ttfb),
      load_duration_ms: Math.round(loadEnd - loadStart),
      render_delay_ms: Math.round(renderTime - loadEnd),
      total_lcp_ms: Math.round(renderTime),
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Az egyik élesben futó áruházunknál pont ez a snippet mutatta meg, hogy a TTFB rendben volt (180 ms), de a resource load delay 1900 ms-re ugrott. Egy harmadik féltől származó A/B teszt szkript blokkolta a böngésző preload scannerét. A fix kétsoros volt, az LCP pedig 3,1 mp-ről 1,4 mp-re csökkent.

Hogyan azonosítsd az LCP-elemet?

Mielőtt bármit optimalizálnál, tudnod kell, melyik DOM-csomópont az LCP a tipikus felhasználódnál. A Chrome DevTools Performance panelje feljegyzi az „LCP" eseményt és a hozzá tartozó elemet. Kattints rá, és kiugrik az Elements panelben. A PageSpeed Insights szintén megmutatja a kiválasztót.

Mobile-first oldalakon gyakran egy másik elem nyer, mint asztali nézetben, ezért érdemes mindkettőt külön tesztelni. A leggyakoribb LCP-jelöltek a tapasztalataim szerint:

• Hero kép: termékoldal, blog header, marketing lapok.
• Kategória miniatűr: listanézetekben a legnagyobb látható termékkép.
• H1 vagy hosszú bevezető szövegblokk: szöveges cikkeken, amikor nincs nagy kép a header alatt.
• CSS background-image hero szekción: ez egy klasszikus buktató, mert a preload scanner nem találja meg.
• Video poszter: landing oldalakon, ahol egy intro videó fut.

Egy gyors trükk: nyiss meg egy inkognitó tabot, futtasd a web-vitals könyvtárat, és logold ki az entry.element.outerHTML-t. Ha ezzel együtt méred az LCP-t a felhasználói szegmenseiden, kiderül, hogy egy üzemzavar vagy konverziós csökkenés mögött tényleg az LCP áll-e. Erről részletesebben írtam a RUM, web-vitals.js és CrUX gyakorlati útmutatómban.

fetchpriority, preload és priority hints a gyakorlatban

2022-ben még a <link rel="preload"> volt az egyetlen módszer az LCP kép sürgetésére. 2026-ban ezt szinte minden esetben felváltja a fetchpriority="high" attribútum, amelyet közvetlenül a hero képen helyezel el. Az ok egyszerű: a preload mindig új kérést indít, és könnyen duplázódik, míg a fetchpriority csak átírja a már meglévő képkérés prioritását.

<!-- Rossz: preload, ami duplázott letöltést okozhat -->
<link rel="preload" as="image" href="/hero.avif">
<img src="/hero.avif" alt="Hero termék" width="1200" height="630">

<!-- Jó: fetchpriority közvetlenül a képen -->
<img
  src="/hero.avif"
  alt="Hero termék"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async">

A részletes szabályrendszert érdemes elolvasni a MDN fetchpriority dokumentációjában. Külön figyeld azt a részt, hogy a fetchpriority="low" beállítása a below-the-fold képeknél visszafoghatja a hálózati versengést, és ezzel közvetve gyorsítja az LCP-t. Egy árlistás oldalon ez nálam további 280 ms-ot adott.

A preload akkor marad jó megoldás, amikor a forrás nincs a kezdeti HTML-ben: CSS-ben hivatkozott background-image, vagy JS-ből inzertelt elem. Ilyenkor:

<link
  rel="preload"
  as="image"
  href="/hero.avif"
  type="image/avif"
  fetchpriority="high"
  imagesrcset="/hero-800.avif 800w, /hero-1200.avif 1200w"
  imagesizes="(max-width: 768px) 100vw, 1200px">

Render-blokkoló CSS és JavaScript eltávolítása

Egy átlagos e-kereskedelmi oldalon 8–15 render-blokkoló stylesheet és szkript fut a <head>-ben. Mindegyik elkölt 50–200 ms-ot az „element render delay" részidőből, mert a böngésző addig nem mer rajzolni, amíg a CSSOM nem teljes. A megoldás háromszintű:

1. Kritikus CSS inlinelva a head-ben: csak az above-the-fold layout-hoz szükséges szabályok, ideálisan 14 KB alatt (egy TCP slow-start ablak).
2. A maradék CSS aszinkron betöltése: <link rel="preload" as="style" onload="this.rel='stylesheet'"> pattern.
3. Harmadik fél szkriptek defer/async-elése: analitika, A/B teszt, chat widget, mind defer vagy facade.

Példa egy modern CSS aszinkron töltésre, ami SEO-barát és a felhasználói élmény szempontjából is működik:

<!-- Kritikus, inline -->
<style>
  /* csak above-the-fold layout szabályok ide */
  body { margin: 0; font-family: system-ui, sans-serif; }
  .hero { aspect-ratio: 1200/630; background: #1a1a1a; }
</style>

<!-- Nem kritikus, aszinkron -->
<link rel="preload" href="/styles/main.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles/main.css"></noscript>

Az e-commerce gyakorlatomban a legnagyobb LCP-gyilkos nem a saját CSS, hanem a harmadik fél szkriptek fő szálat blokkoló végrehajtása. Egy chat widget, ami szinkronosan tölti be magát, simán hozzátesz 800–1500 ms-ot mobilon. Ezekről a megoldásokról részletesen írtam a harmadik fél szkriptek optimalizálása útmutatómban, ahol a facade pattern és a szerver oldali tagging is szerepel.

TTFB csökkentése: szerver, CDN, edge

Ha a TTFB-d 800 ms felett van mobilon, a többi optimalizáció hiábavaló. A böngésző nem tud korábban kezdeni semmit. A célszám: TTFB < 600 ms a 75. percentilisen, ideálisan 200–400 ms.

A három leghatékonyabb fogás (sorrendben):

• Edge CDN cache a HTML válaszon (Cloudflare, Fastly, Bunny.net). Egy „cold" eredeti szerver helyett 30–80 ms-os edge választ kapsz. Az ESI vagy edge personalization megoldja a logged-in személyre szabás problémáját.
• HTTP/3 + QUIC: a 0-RTT újrakapcsolódás 100–200 ms-ot vág le a visszatérő felhasználóknál.
• Streaming SSR: Next.js App Router, Astro, vagy Remix esetében a renderToReadableStream már a header-t és kritikus tartalmat kiküldi, mielőtt a teljes oldal kész lenne.

A konkrét konfigurációs példákért és benchmarkokért nézd meg a TTFB optimalizálás és gyorsítótárazási stratégiák cikkünket. Ott végigveszem a Cloudflare, Vercel és Bunny.net edge konfigurációit egymás mellett.

Ha a hero kép az LCP elem: AVIF, srcset, sizes

A leggyakoribb LCP-jelölt e-kereskedelemben a hero termékkép. Itt négy dolgot kell egyszerre megtenni:

1. AVIF formátum Chrome/Firefox/Safari 16+ alatt, WebP fallback-kel. Egy 1200×630-as JPEG-hez képest AVIF-ban 60–75%-kal kisebb fájlt kapsz hasonló minőségen.
2. Reszponzív srcset és sizes: mobil böngésző ne töltsön le 1600 px-es képet egy 360 px-es viewportba.
3. Explicit width és height: CLS minimalizálás, plusz a böngésző helyet foglal és nem kell relayoutolnia.
4. fetchpriority="high" és decoding="async", hogy a fő szál ne blokkolódjon a dekódolás miatt.

<picture>
  <source
    type="image/avif"
    srcset="/hero-400.avif 400w, /hero-800.avif 800w, /hero-1200.avif 1200w"
    sizes="(max-width: 768px) 100vw, 1200px">
  <source
    type="image/webp"
    srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
    sizes="(max-width: 768px) 100vw, 1200px">
  <img
    src="/hero-800.jpg"
    alt="Tavaszi kollekció - női kabát"
    width="1200"
    height="630"
    fetchpriority="high"
    decoding="async">
</picture>

Ha mélyebben akarsz belemenni a képformátumokba és a reszponzív generálási folyamatba (squoosh, sharp, ImageMagick), erről a képoptimalizálás 2026 útmutatómban találsz tooling-orientált példákat.

Ha szöveg az LCP elem: font-display és kritikus CSS

Tartalmi oldalakon és sok B2B landing oldalon az LCP egy szövegblokk: jellemzően az <h1> vagy az első bekezdés. Itt a kép-trükkök nem segítenek. Két döntő tényező marad:

• Webfont betöltési stratégia: font-display: optional az LCP-szöveghez, hogy ha a betűtípus nem érkezik meg ~100 ms alatt, a böngésző a fallback fonttal rajzol, és nem vár.
• Kritikus CSS: a tipográfiai szabályoknak (font-family, line-height, color) a head-be inline-olva kell lenniük.

@font-face {
  font-family: 'InterVariable';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: optional;
  font-style: normal;
}

A font-display: optional különösen hatásos, mert eltünteti azt az LCP-növelő scenariot, amikor a böngésző a CSSOM-ot már felépítette, de a webfontra vár. Ha a font cache-elve van, megjelenik; ha nem, a következő látogatáskor.

LCP mérése labor- és valós környezetben

Az LCP-nek két mérési módja van, és mindkettőre szükséged van:

Tulajdonság	Lab (Lighthouse)	Field (CrUX / RUM)
Forrás	Lighthouse, PSI, WebPageTest	Chrome User Experience Report, saját RUM
Mintaszám	1 futás (vagy median 3-ból)	több ezer valós felhasználó
Hálózati szimuláció	throttled „slow 4G"	valós felhasználói eszközök
Mit használj rá	regresszió-tesztelés CI-ban	SEO rangsorolás, célszámok
Hivatalos Google forrás?	Nem	Igen (CrUX p75)
Frissítési gyakoriság	azonnal	napi adat, 28 napos görgő ablak

A CI/CD pipeline-omban a Lighthouse-t használom kapuzásra (PR nem mehet be, ha az LCP-szimuláció >3 mp), de a tényleges célszámot a saját RUM dashboardomon nézem. A web-vitals npm csomag 4 sorban kiteszi:

import { onLCP } from 'web-vitals/attribution';

onLCP((metric) => {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: 'LCP',
    value: metric.value,
    rating: metric.rating,
    element: metric.attribution.element,
    url: metric.attribution.url,
    loadDuration: metric.attribution.resourceLoadDuration,
  }));
});

Soft Navigation LCP SPA-kban

Egy hagyományos SPA-ban (React Router, Vue Router) az LCP csak a kezdeti betöltésnél mérődött, a kliensoldali útvonalváltások „láthatatlanok" voltak a Chrome számára. 2025-ben ez megváltozott: a Soft Navigation API mostantól külön LCP-méréseket ad ki minden URL-váltásnál, ha a böngésző felismeri a navigációt (History API push + DOM csere).

A bekapcsoláshoz Chrome 117+ esetén a chrome://flags/#soft-navigation-heuristics manuálisan engedélyezhető, vagy origin trialba feliratkozhatsz. Production kódban így méred:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'soft-navigation') {
      console.log('Soft nav LCP target URL:', entry.name);
    }
    if (entry.entryType === 'largest-contentful-paint' && entry.navigationId) {
      console.log('LCP a soft navigation után:', entry.startTime);
    }
  }
}).observe({ type: 'soft-navigation', buffered: true });

Gyakori kérdések

Mennyi az ideális LCP érték 2026-ban?

A Google szerint 2,5 másodperc alatt „jó", 2,5–4,0 mp között „javítandó", 4,0 mp felett „gyenge". Ezeket a küszöböket a mobil felhasználók 75. percentilisén kell elérni, nem laboratóriumi tesztben.

Miért magasabb a Lighthouse LCP érték, mint a valós felhasználói adat?

A Lighthouse szimulált throttling-et használ (Slow 4G, 4× CPU lassítás), ami pesszimistábbra állítja az eredményt 15–30%-kal. A Google rangsorolás a CrUX mező-adatát használja, nem a Lighthouse-t; a Lighthouse főleg regressziók kiszúrására jó.

Mi a különbség a fetchpriority és a preload között?

A preload új hálózati kérést indít, és duplázhatja a már HTML-ben szereplő képeket. A fetchpriority="high" attribútum csak a meglévő képkérés prioritását emeli a böngésző tile rendszerében. Ha a kép a HTML-ben van, mindig fetchpriority-t használj.

Hogyan tudom megnézni, melyik elem az LCP az oldalamon?

A Chrome DevTools Performance paneljén indíts felvételt, és keresd az „LCP" eseményt a Timings sávon. Kattintásra az Elements panelben kiugrik a kiválasztott csomópont. Alternatív megoldás a PageSpeed Insights, ami megjeleníti az LCP-elem CSS-szelektorát.

Befolyásolja-e a CDN az LCP-t?

Igen, közvetlenül a TTFB-n keresztül. Egy edge cache hit jellemzően 200–400 ms-ot vág le a TTFB-ből, ami közvetlenül az LCP teljes idejéből jön le. Ha a HTML-t és a kritikus képeket ugyanaz a CDN szolgálja ki, a hálózati versengés is mérséklődik HTTP/2 multiplexing miatt.

Számít-e a Soft Navigation LCP a Google rangsorolásban?

2026 közepén még nem, a CrUX továbbra is csak a hard navigációkat méri. A Google jelezte, hogy a 2027-es Page Experience frissítés beolvasztja a Soft Navigation metrikákat, ezért SPA-knál érdemes már most mérni és optimalizálni.