LCP: miért tűnik lassúnak a weboldal, és hogyan gyorsítható a fő tartalom betöltése?

Amikor valaki megnyit egy weboldalt, nem az számít neki, mikor töltődik be az utolsó szkript, hanem hogy mikor jelenik meg az, amiért jött: a fejléckép, a termékfotó vagy a fő szövegblokk. Ezt méri a Largest Contentful Paint, röviden LCP. A web.dev cikke, a Largest Contentful Paint (LCP) szerint az LCP stabil Core Web Vitals mutató, amely az érzékelt betöltési sebességet méri: azt a pillanatot jelöli, amikor az oldal fő tartalma valószínűleg már betöltődött. Az alábbiakban ezt és a web.dev kapcsolódó útmutatóit foglaljuk össze weboldal-üzemeltetői szemmel.

Mit mér pontosan az LCP

A web.dev szerint az LCP a nézetablakban látható legnagyobb kép, szövegblokk vagy videó megjelenítési idejét jelzi ahhoz képest, hogy a felhasználó elindította az oldal megnyitását. Ebbe beleszámít az előző oldal elhagyása, a kapcsolat felépítése, az átirányítások ideje és a szerver első bájtjáig eltelt idő (Time to First Byte, TTFB) is. Ezért térhet el a valós felhasználóknál mért és a laborban mért érték.

A cikk szerint LCP-elem lehet egy img elem, egy SVG-n belüli image elem, egy videó (a poszterkép vagy az első képkocka), egy CSS url() függvénnyel betöltött háttérkép, illetve egy szöveget tartalmazó blokkszintű elem. A Chromium-alapú böngészők kiszűrik a láthatatlan, 0 átlátszóságú elemeket, a teljes nézetablakot kitöltő, inkább háttérnek tekintett elemeket, valamint az alacsony információtartalmú helykitöltő képeket.

Mikor jó az érték

A web.dev azt javasolja, hogy az LCP legfeljebb 2,5 másodperc legyen. Azt, hogy ez a látogatók többségénél teljesül-e, a mezőben mért oldalbetöltések 75. percentilisén érdemes nézni, mobilon és asztali gépen külön. A küszöbértékek módszertanát bemutató web.dev cikk, a The research and methodology behind Core Web Vitals thresholds szerint 4 másodperc a „gyenge” határ.

• 2,5 másodperc vagy kevesebb: jó.
• 2,5 és 4 másodperc között: javítandó.
• 4 másodperc felett: gyenge.

A kattintásokra adott válaszidőt mérő INP mutatóról külön cikkben írtunk.

Miért gyakori gond

A web.dev The most effective ways to improve Core Web Vitals című útmutatója szerint az LCP az a Core Web Vitals mutató, amellyel a fejlesztők a legtöbbet küzdenek: a Chrome UX Report webhelyeinek 40%-a nem éri el a javasolt értéket. Az útmutató a HTTP Archive 2024-es Web Almanacjára hivatkozva azt írja, hogy a mobiloldalak 73%-ánál kép az LCP-elem. A gyenge LCP-jű oldalaknál a 75. percentilisen 1290 ezredmásodpercet késik az LCP-kép betöltésének elindulása a böngészőben, ami a gyors élményhez szükséges időkeret több mint fele.

Az útmutató szerint azoknál az oldalaknál, ahol kép volt az LCP-elem, a képek 35%-ának forrás-URL-je nem volt megtalálható az első HTML-válaszban, így a böngésző nem tudta korán felfedezni őket.

Mit javasol a web.dev

• Legyen a fő kép benne a HTML-ben. Az LCP-képet img elemmel, src vagy srcset attribútummal érdemes betölteni, nem JavaScriptet igénylő data-src megoldással; az útmutató szerint az oldalak 7%-a így rejti el az LCP-képét.
• Szerveroldali renderelés. Az útmutató a szerveroldali renderelést (SSR) javasolja a kliensoldalival (CSR) szemben, mert SSR-nél a teljes oldal jelölése, a képpel együtt, ott van a HTML-forrásban, CSR-nél viszont előbb le kell futnia a JavaScriptnek.
• Előtöltés. Ha a képre külső CSS- vagy JS-fájl hivatkozik, egy <link rel="preload"> címkével akkor is bekerülhet a HTML-forrásba.
• Elsőbbség. Az LCP-kép img vagy preload címkéjére kerüljön fetchpriority="high" attribútum; a Web Almanac szerint az erre alkalmas oldalak 15%-a használta ezt.
• Ne legyen lusta betöltés a fő képen. Az LCP-kép img címkéjéről vegyük le a loading="lazy" attribútumot.
• A nem kritikus elemek várhatnak. A nem fontos erőforrásokat érdemes később vagy aszinkron módon betölteni, hogy a fő kép gyorsabban érkezzen.
• CDN a gyorsabb első bájtért. Az útmutató szerint a TTFB csökkentésének legjobb módja a CDN, amely a látogatóhoz földrajzilag közel szolgálja ki és gyorsítótárazza a tartalmat; a Web Almanac szerint a HTML-dokumentum-kéréseknek csak 33%-át szolgálta ki CDN.
• Azonnali navigáció. A vissza/előre gyorsítótár (bfcache) a korábban meglátogatott oldalt azonnal visszaállítja, a Speculation Rules API-val előre renderelt oldal pedig közel nulla LCP-vel jelenhet meg. Az útmutató szerint a bfcache-ből gyakran a no-store gyorsítótár-utasítás vagy egy unload eseménykezelő zárja ki az oldalt.

Hogyan mérjük

A web.dev szerint az LCP mezőben a Chrome User Experience Reporttal, a PageSpeed Insightsszal, a Search Console Core Web Vitals jelentésével és a web-vitals JavaScript-könyvtárral mérhető, laborban a Chrome DevToolsszal, a Lighthouse-szal, a PageSpeed Insightsszal és a WebPageTesttel. Fontos részlet, hogy a böngésző az első felhasználói interakció (koppintás, görgetés, billentyűleütés) után nem jelent új LCP-jelöltet, a háttérlapon megnyitott oldalakra pedig a Google mérőeszközei nem közölnek LCP-értéket.

Mit nézünk meg egy ügyféloldalon

A Flybuiltnél ezt a rövid listát használjuk, amikor egy élő oldal betöltését ellenőrizzük. Nem Google-garancia, hanem a web.dev útmutatóinak lefordítása a napi munkára.

• A PageSpeed Insightsban a mezőadatot nézzük, mobilon és asztali gépen külön, ha az oldal szerepel a CrUX-ban.
• Megnézzük, melyik elem az LCP: a fejléckép, egy termékfotó vagy egy szövegblokk.
• Ha kép, ellenőrizzük, hogy benne van-e az első HTML-válaszban, nincs-e rajta loading="lazy", és kapott-e fetchpriority="high" jelölést.
• Ha a fő tartalom csak JavaScript lefutása után jelenik meg, megvizsgáljuk az előrenderelés vagy a szerveroldali renderelés lehetőségét.
• Megnézzük az első bájtig eltelt időt és a CDN-beállítást.

Források: web.dev, Philip Walton és Barry Pollard, Largest Contentful Paint (LCP); web.dev, The most effective ways to improve Core Web Vitals; web.dev, Bryan McQuade és Barry Pollard, The research and methodology behind Core Web Vitals thresholds.