LCP-probléma mobilon: miért lassú a fő tartalom megjelenése, és hogyan javítsd?
Az LCP (Largest Contentful Paint) azt méri, hány másodperc alatt jelenik meg az oldal legnagyobb látható eleme – általában a fő kép vagy a főcím. A Google szerint 2,5 mp alatt jó, 4 mp felett gyenge, a látogatók 75%-ának mért értéke alapján. Az LCP négy részből áll: szerver-válaszidő, a fő elem letöltésének késése, a letöltés ideje és a kirajzolás késése. Javítás: gyorsítsd a szervert (cache), a fő képet tömörítsd és töltsd elsőbbséggel, ne lazy-loadold, és szüntesd meg a kirajzolást blokkoló CSS-t és szkripteket.
Mit jelent ez az üzletednek?
Súlyosság: közepes. A Core Web Vitals egyik fő mutatója: a valós látogatói élményt és az oldalélmény-jeleket is rontja.
Az LCP a látogató első benyomása: ameddig a fő tartalom nem jelenik meg, a látogató egy üres vagy félkész oldalt néz. Mobilon, gyengébb kapcsolaton ez a pillanat dönti el, marad-e, vagy visszalép a találati listára a következő céghez.
A leggyakoribb okok – és hogyan ismered fel őket
- 1
Lassú szerver-válaszidő (TTFB)
Ha a szerver 1–2 másodpercig gondolkodik, mielőtt bármit küldene, az LCP már eleve vesztes helyzetből indul.
Így ellenőrizd: PageSpeed → „A kiszolgáló kezdeti válaszideje” vagy a valós adatoknál a TTFB.
- 2
A fő kép későn kezd letöltődni
CSS-háttérképként, JavaScripttel vagy lazy loadinggal betöltött hero kép: a böngésző csak későn fedezi fel.
Így ellenőrizd: A PageSpeed LCP-elem részletezésében a „betöltési késleltetés” (load delay) nagy?
- 3
Túl nagy a fő kép
Egy 2–3 MB-os hero kép mobilneten másodpercekig töltődik.
Így ellenőrizd: Mekkora a fő kép fájlmérete? Mobilra is az asztali változat töltődik?
- 4
Blokkolt kirajzolás
A kép már megvan, de a böngésző még CSS-re, betűtípusra vagy JavaScriptre vár, mielőtt kirajzolhatná.
Így ellenőrizd: A „renderelési késleltetés” (render delay) része nagy az LCP-bontásban?
Javítás lépésről lépésre
- 1. lépés
Azonosítsd az LCP-elemet
Futtasd a PageSpeed Insightsot mobilra, és a diagnosztikában nézd meg, melyik elem az LCP, és hogyan oszlik meg a négy részidő között. Mindig a legnagyobb részidővel kezdd.
- 2. lépés
Gyorsítsd a szerver válaszát
Oldalszintű cache, CDN, gyorsabb tárhely és a felesleges átirányítások megszüntetése. A cél: 0,8 mp alatti TTFB.
- 3. lépés
Töltsd elsőbbséggel a fő képet
Ha a hero kép CSS-háttér, tedd át <img> elembe, vagy töltsd elő. Soha ne legyen rajta loading="lazy".
HTML <head> – a fő kép előtöltése <link rel="preload" as="image" href="/kepek/hero-800.avif" imagesrcset="/kepek/hero-480.avif 480w, /kepek/hero-800.avif 800w, /kepek/hero-1400.avif 1400w" imagesizes="100vw" fetchpriority="high"> - 4. lépés
Csökkentsd a fő kép méretét
Mobilra 480–800 px széles, AVIF vagy WebP formátumú, 100–150 kB alatti hero kép általában elég. Szöveges főcímnél (ha az az LCP) a betűtípus gyors betöltése a kulcs.
- 5. lépés
Szüntesd meg a kirajzolás akadályait
A kritikus CSS kerüljön a fejlécbe, a többi töltődjön később; a szkriptek kapjanak defer attribútumot; a betűtípusoknál használj font-display: swap beállítást.
HTML – szkript a kirajzolás után <script src="/js/app.js" defer></script> - 6. lépés
Validáld a javítást
A Search Console Core Web Vitals jelentésében kattints a „Javítás ellenőrzése” gombra. A valós adatok 28 napos időablakban gyűlnek, ezért az eredmény néhány hét alatt válik láthatóvá.
Tippek platformonként
WordPress
Sok sablon és oldalépítő a hero képet háttérképként tölti be, és a cache-bővítmények is lazy loadingot tehetnek rá. Zárd ki a fő képet a lazy loadingból, és kapcsold be az előtöltést.
Shopify
A témában a hero/slideshow szakasz első képe kapja meg a fetchpriority="high" értéket, és használd az image_url szűrő méretezését mobilra.
Next.js
A next/image komponensnél a hajtás feletti képre add meg a priority (újabb verzióban preload) tulajdonságot, és ügyelj a sizes értékre.
Gyakori hibák javítás közben
- Csúszkát (slider) használni a hajtás felett – az első kép késik, a többi feleslegesen töltődik.
- Videós hátteret tenni a mobil hero részbe.
- Csak a laborértéket figyelni, a Search Console valós adatait nem.
Mikor kérj segítséget?
Ha a négy részidő közül a szerver-válaszidő a nagy, az tárhely- vagy fejlesztési kérdés; ha a renderelési késleltetés, akkor a sablon CSS- és JavaScript-szerkezetét kell átalakítani. Az auditban megmérjük, melyik oldalsablonnál mi a szűk keresztmetszet, és kész javítást adunk.
Gyakori kérdések
Mi számít jó LCP-nek?
A Google szerint 2,5 másodperc alatt jó, 2,5 és 4 másodperc között javítandó, 4 másodperc felett gyenge – a látogatók 75%-ánál (75. percentilis) mért érték alapján.
Miért nem változik azonnal a Search Console jelentés?
A Core Web Vitals jelentés valós látogatói adatokat használ, 28 napos időablakban. A javítás hatása ezért fokozatosan, néhány hét alatt jelenik meg.
Nincs elég adat az oldalamhoz – mit tegyek?
Kis forgalmú oldalnál a Google nem jelenít meg valós adatot. Ilyenkor a PageSpeed laborteszt LCP-értékére hagyatkozz, és azon dolgozz.