Google PageSpeed Insights – LCP/INP/CLS hibák javítása fejlesztői szinten - Vidensdatabase

Vidensdatabase

Rövid válasz: Ebben a cikkben azt mutatjuk meg, hogy a PageSpeed Insights (PSI) tipikus figyelmeztetései mögött milyen konkrét kódszintű okok állnak, és mit érdemes javítani (különösen WordPressnél, de általánosan is érvényes).

Fontos: a cél nem csak a pontszám, hanem hogy a Core Web Vitals mutatók „jó” tartományba kerüljenek.

Tartalom

PSI riport: Opportunities / Diagnostics – mire figyelj?
Mielőtt javítasz: így azonosítsd be a valódi problémát (DevTools workflow)
LCP javítása – fejlesztői szinten
INP javítása – fejlesztői szinten
CLS javítása – fejlesztői szinten
PSI üzenetek „fordítótáblája” – gyors párosítás fejlesztőknek
Visszamérés: honnan tudod, hogy tényleg jobb lett?
Kapcsolódó cikkek

PSI riport: Opportunities / Diagnostics – mire figyelj?

A PageSpeed Insights riportban az Opportunities és Diagnostics részek adják a legtöbb konkrét „nyomot” ahhoz, hogy mit kell javítanod: tipikusan render-blocking erőforrások, unused CSS/JS, long main-thread tasks, képek és fontok.

Mielőtt javítasz: így azonosítsd be a valódi problémát (DevTools workflow)

A PSI sokszor „tünetet” ír le. A gyors javításhoz először derítsd ki: melyik elem/erőforrás a felelős.

1. Chrome DevTools → Performance

Indíts felvételt (Record), majd frissítsd az oldalt.
Keresd meg:
- LCP eseményt (Largest Contentful Paint) és hogy melyik elem volt az (kép / szöveg / hero blokk).
- Layout Shift eseményeket (CLS).
- Long task szakaszokat (INP gondoknál gyakori).

2. DevTools → Network (waterfall)

Nézd meg, mi indul későn:

a hero kép letöltése,
CSS fájlok,
fontok,
3rd-party scriptek (chat, analytics, heatmap).

Külön figyeld: mi blokkolja a renderelést (CSS/JS), és mennyi a szerver válasz (TTFB).

3. DevTools → Rendering

Kapcsold be a „Layout Shift Regions” nézetet (ha elérhető), így vizuálisan is látod, mi ugrik el.

4. Ismételj kontrolláltan

Cache plugint/optimalizáló plugint teszt előtt ne kapcsolgass össze-vissza.
Mindig üríts cache-t, és futtass 2–3 mérést, hogy trendet láss.

LCP javítása (betöltésérzet / „hero” tartalom) – fejlesztői szinten

Mit jelent a gyakorlatban?

Az LCP azt méri, mikor jelenik meg a legnagyobb, fontos tartalmi elem a viewportban (gyakran: hero kép, főcím, kiemelt blokk). LCP-nél tipikus cél: a hero tartalom minél hamarabb felfedezhető legyen és magas prioritással töltődjön.

LCP: tipikus kiváltó okok (fejlesztői szemmel)

Túl nagy hero kép / slider (feleslegesen nagy fájl, több slide betöltés, JS vezérlés)
Későn felfedezett LCP erőforrás (CSS background-image, JS-ből beszúrt kép)
Render-blocking CSS/JS (a böngésző nem tud rajzolni)
Magas TTFB (lassú backend / nincs cache / túl sok dinamikus művelet)
Hosszú kritikus kéréslánc (HTML → CSS → font → csak utána derül ki a kép)

Mit csinálj: konkrét beavatkozások sorrendben

1. Azonosítsd: mi az LCP elem?

Performance felvételben keresd: LCP → kattintva látod, melyik elem volt az.
Döntsd el: kép az LCP vagy szöveg/blokk?

2. Ha az LCP egy kép (hero): tedd „korán indulóvá” és „magas prioritásúvá”

Mit kerülj:

Above-the-fold hero ne legyen lazy-load.
Ne CSS background-image legyen (gyakran későn derül ki), ha LCP-kritikus.

Javasolt minta (reszponzív hero kép):

<img
  src="/media/hero-1200.webp"
  srcset="/media/hero-640.webp 640w, /media/hero-1200.webp 1200w, /media/hero-1920.webp 1920w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async"
  alt="Kiemelt tartalom képe"
/>

Ha a waterfallban későn indul a hero kép letöltése: használj preloadot:

<link rel="preload"
      as="image"
      href="/media/hero-1200.webp"
      imagesrcset="/media/hero-640.webp 640w, /media/hero-1200.webp 1200w, /media/hero-1920.webp 1920w"
      imagesizes="(max-width: 768px) 100vw, 1200px">

3. Render-blocking CSS/JS csökkentése (kritikus render útvonal rövidítése)

Cél: amitől a „first paint” és a „hero” késik, azt vedd ki az útból.

CSS: kritikus (above-the-fold) minimálisan inline, a többi később.

<link rel="preload" href="/assets/app.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/assets/app.css"></noscript>

JS: saját script defer, nem kritikus 3rd-party késleltetése.

<script src="/assets/app.js" defer></script>

WordPressnél ez gyakran azt jelenti: kevesebb globálisan betöltött builder/plug-in CSS/JS, és csak ott töltsön, ahol tényleg szükséges.

4. TTFB javítása (szerver oldali gyorsítás)

Ha a Networkben a dokumentum (HTML) válasza lassú, a cél a gyorsabb kiszolgálás:

legyen oldal cache (teljes oldal gyorsítótár),
dinamikus oldalaknál objektum cache (DB terhelés csökkentése),
optimalizáld a lassú lekérdezéseket, csökkentsd a felesleges plugineket,
statikus fájlokhoz CDN (ha használsz, DNS beállítás is érintett lehet).

Kapcsolódó cikkek (ha DNS/CDN beállítás kell):

INP javítása (kattintás/űrlap/menü reakcióidő) – fejlesztői szinten

Mit jelent a gyakorlatban?

Az INP azt mutatja, mennyi idő telik el egy felhasználói interakció (kattintás, input, billentyű) és a következő látható frissülés között. A leggyakoribb ok: túlterhelt main thread (sok/nehéz JavaScript).

INP: tipikus kiváltó okok

túl sok JS (builder, animáció, űrlap, tracking)
harmadik fél scriptek (chat/heatmap/reklám)
nagy DOM + sok komponens + drága stílus- és layout számítás
„long tasks” (50ms feletti blokkoló futások)

Mit csinálj: konkrét beavatkozások

1. Találd meg a long taskokat és a lassú event handler-eket

Performance felvételben keresd a hosszú sárga (script) blokkokat.
Keresd az interakcióhoz köthető eseményeket (click/input/keydown) és nézd meg:
- mennyi JS fut,
- van-e layout thrash (olvasás/írás keverve),
- mi fut 3rd-party oldalról.

2. Darabold fel a munkát (ne blokkolj 200–500ms-ig)

Ha egy interakció egyben sok mindent számol, bontsd kisebb szeletekre requestAnimationFrame-mel (UI barát):

function runChunked(workItems) {
  function step() {
    const start = performance.now();
    while (workItems.length && performance.now() - start < 8) {
      doWork(workItems.shift());
    }
    if (workItems.length) requestAnimationFrame(step);
  }
  requestAnimationFrame(step);
}

3. Kerüld a kényszerített layoutot (forced synchronous layout)

Tipikus hiba: DOM-mérés (getBoundingClientRect) + azonnali DOM-módosítás ugyanabban a ciklusban.
Jó minta: előbb olvasd ki, aztán írj (read → write).
Animációkhoz preferáld: transform / opacity (ne top/left/height).

4. Eseménykezelés optimalizálás

Scroll/touch esetén passzív listener:

window.addEventListener('scroll', onScroll, { passive: true });

Debounce/throttle inputoknál (pl. keresőmező): ne minden billentyűre fussanak drága műveletek.

5. 3rd-party scriptek kontrollja (gyakori INP „gyilkos”)

csak azokon az oldalakon töltsd, ahol kell,
töltsd consent után vagy első interakció után,
„facade” minta: placeholder → kattintásra töltöd be az embedet (chat/térkép/videó).

WordPressnél ide tartozik: tracking kódok, chat widget, heatmap, marketing automatizációk – ezek sokszor a main thread-et terhelik.

CLS javítása (elugráló tartalom) – fejlesztői szinten

Mit jelent a gyakorlatban?

A CLS azt méri, mennyit „ugrál” az oldal betöltés közben. A leggyakoribb ok: nincs hely lefoglalva a később betöltődő elemeknek.

CLS: tipikus kiváltó okok

képek/videók/iframe-ek méret nélkül
későn betöltött webfont → szöveg átméreteződik
dinamikusan beszúrt elemek a tartalom tetejére (cookie sáv, promo csík, hirdetés)

Mit csinálj: konkrét beavatkozások

1. Adj fix méretet a médiának (width/height vagy arány)

<img src="/media/pic.webp" width="800" height="450" alt="…" />

Reszponzív blokknál használj aspect-ratio-t:

.hero { aspect-ratio: 16 / 9; }
.hero img { width: 100%; height: 100%; object-fit: cover; }

2. Dinamikus elemek: ne „tolják le” a tartalmat

Jó megoldások:

overlay (pl. position: fixed; bottom: 0;) – nem változtatja a layoutot
vagy előre lefoglalt hely (placeholder):

.cookie-bar-slot { min-height: 80px; }

3. Font betöltés stabilan

font-display: swap; alapnak jó:

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont.woff2") format("woff2");
  font-display: swap;
}

Ha még így is ugrik a szöveg: válassz metrically kompatibilis fallback fontot, és csak indokolt esetben használj preloadot (különben más erőforrástól vehet el sávszélt).

PSI üzenetek „fordítótáblája” – gyors párosítás fejlesztőknek

Hasznos, ha a riportban ilyen sorokat látsz:

Eliminate render-blocking resources → kritikus CSS minimalizálás/inline + nem kritikus CSS/JS halasztása
Reduce unused CSS / Reduce unused JavaScript → page-szintű betöltés, felesleges pluginek/builder modulok kigyomlálása
Avoid long main-thread tasks / Reduce JavaScript execution time → task darabolás, 3rd-party késleltetés, kevesebb DOM munka
Avoid large layout shifts → width/height/aspect-ratio, dinamikus elemek helyfoglalása, font stratégia

Visszamérés: honnan tudod, hogy tényleg jobb lett?

Módosítás után cache ürítés (WP plugin + szerver oldali, ha van).
PSI újramérés mobil/desktop.
DevTools Performance-ben nézd meg:
- LCP elem letöltése korábban indul-e,
- kevesebb-e a render-blocking,
- csökkentek-e a long taskok,
- eltűntek-e a layout shift események.
Ha van Field (CrUX) adat: számolj azzal, hogy az nem azonnal frissül (valós, gördülő időszak).

Vidensdatabase

Kategorier

Kategorier