Core Web Vitals: az INP mélyen

Scheo · 2026-07-18 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha valaha ráböktél egy gombra egy telefonon, és egy fél másodpercig nem történt semmi, akkor pontosan azt tapasztaltad meg, amit az INP mutató megpróbál számszerűsíteni. Ez a cikk végigveszi, mi is ez a mutató, miért lépett a FID helyébe, hogyan méred, mi rontja el a leggyakrabban, és milyen konkrét irányokban tudsz rajta javítani.

Mi az INP, és miért váltotta le a FID-et?

Az INP (Interaction to Next Paint) azt méri, mennyi idő telik el egy felhasználói interakció (kattintás, koppintás, billentyűleütés) és a képernyő következő vizuális frissítése között, a teljes oldal-élettartamra vetítve. A Google 2024. március 12-én tette hivatalos Core Web Vitals mutatóvá a korábbi FID (First Input Delay) helyett (hivatalos információ, Google Search Central és web.dev).

A FID-nek két komoly korlátja volt. Egyrészt csak az első interakciót mérte az oldalon, holott a valós frusztráció gyakran később, görgetés vagy űrlap-kitöltés közben jelentkezik. Másrészt a FID kizárólag az input-késleltetést mérte, vagyis azt az időt, amíg a böngésző egyáltalán hozzáfért az eseményhez, de nem számolta bele az esemény feldolgozását és a változás kirajzolását. Emiatt sok oldal remek FID-et mutatott, közben a gyakorlatban akadozott. Az INP mindezt kiegészíti: minden számottevő interakciót figyel, és a rosszabbak közül választ egy reprezentatív, csúcs körüli értéket, így jobban tükrözi a tényleges élményt.

Mennyi a jó INP-érték?

A Google szerint a jó INP 200 ms alatti, a 200 és 500 ms közötti tartomány javításra szorul, az 500 ms feletti pedig gyenge. Ezek a küszöbök (hivatalos információ, web.dev) a 75. százalékos értékre vonatkoznak, vagyis a valós felhasználói mérések felső negyedét is bele kell férned a jó sávba ahhoz, hogy az oldalad átmenjen.

Fontos értened, hogy egyetlen interakció három szakaszra bomlik. Az input-késleltetés az az idő, amíg a böngésző el tud kezdeni foglalkozni az eseménnyel (jellemzően más, még futó feladatok miatt vár). A feldolgozási idő az eseménykezelő kódod futása. A megjelenítési késleltetés pedig az, amíg az új állapotot ki is rajzolja a böngésző. Az INP a három összegét adja. Ha tudod, melyik szakasz a legnagyobb, célzottan tudsz beavatkozni.

Hogyan méred az INP-t a gyakorlatban?

Két forrást érdemes kombinálnod: a valós felhasználóktól származó terepadatot és a labor-jellegű, hibakeresésre alkalmas mérési eszközöket. A kettő másra jó, ezért egyiket se hagyd ki.

Terepadat (valós felhasználók mérése):

• Google Search Console Core Web Vitals jelentése, amely CrUX-adatra épül és URL-csoportokat mutat.
• PageSpeed Insights, ahol a felső blokk a valós, 28 napos terepadat, az alsó a laboreredmény.
• CrUX (Chrome User Experience Report) nyers adatai, ha mélyebbre ásnál.

Laboradat és hibakeresés (saját gépen reprodukálva):

• A Web Vitals Chrome-kiegészítő, amely élő INP-t mutat, miközben te magad kattintgatsz az oldalon.
• A Chrome DevTools Performance panelje, ahol a hosszú feladatok (long tasks) és a Long Animation Frames adatok kirajzolódnak.

Saját tapasztalatom szerint a leggyorsabb út az, ha a Web Vitals kiegészítővel bekapcsolod a részletes naplózást, majd valódi felhasználói utakat játszol le (menü megnyitása, szűrő váltása, kosárba tétel). Az akadozó interakció szinte azonnal kiugrik. A Lighthouse egyszeri futása nem ad közvetlen INP-értéket, mert az INP természeténél fogva interakciót igényel, ezért a laborban neked kell előállítanod az interakciót.

Mi rontja el leggyakrabban az INP-t?

A leggyakoribb ok a fő szálat hosszan blokkoló JavaScript, ami miatt a böngésző nem tud időben reagálni a felhasználói interakcióra. A böngésző egyetlen fő szálon végzi a szkriptfuttatást, az elrendezést és a rajzolást egyaránt, így ha ott egy hosszú feladat fut, minden más vár.

Tipikus kiváltók, amelyekkel a munkám során a legtöbbet találkozom:

• Nehéz eseménykezelők: egy kattintásra túl sok munka indul el szinkron módon (nagy lista újrarajzolása, komplex számítás).
• Harmadik felek szkriptjei: chat-widgetek, A/B-teszt eszközök, hőtérkép-követők, hirdetési kódok, amelyek a fő szálon dolgoznak.
• Nagy és mély DOM: sok ezer elem esetén már maga a stílus-újraszámítás és a rajzolás is lassú.
• Keretrendszeri újrarenderelés: egy állapotváltozás indokolatlanul nagy komponensfát renderel újra (React, Vue, egyéb).
• Hidratáció (hydration): szerveroldalon renderelt oldalaknál a betöltés utáni JavaScript-aktiválás közben érkező kattintások könnyen beragadnak.

Szakmai feltételezés, de a tapasztalat is ezt támasztja alá: a problémák többsége nem egyetlen nagy hibából, hanem sok kicsi, egyenként ártalmatlannak tűnő szkriptből áll össze, amelyek egyszerre terhelik a fő szálat.

Miért rosszabb az INP mobilon?

Mobilon ugyanaz a JavaScript sokkal lassabban fut, mert a telefonok CPU-ja gyengébb, ezért a fő szálat blokkoló feladatok aránytalanul nagyobb INP-t okoznak. Egy asztali gépen 50 ms alatt lefutó feladat egy középkategóriás telefonon könnyen 200-300 ms is lehet.

Ehhez jön, hogy a valós felhasználói terepadat túlnyomó része mobilról származik, tehát a Search Console értékelése főként a mobil élményt tükrözi. Ha csak asztali Chrome-ban tesztelsz, jó eséllyel alábecsülöd a problémát. Érdemes a DevToolsban bekapcsolnod a CPU-lassítást (4x vagy 6x throttling), hogy közelebb kerülj a valós mobil viselkedéshez.

Milyen konkrét irányokban javíthatod az INP-t?

A leghatásosabb irányok: a hosszú feladatok feldarabolása, a fő szálnak való rendszeres visszaadás, a szükségtelen JavaScript eltávolítása és a harmadik felek szkriptjeinek visszafogása. Nem garantált, hogy minden eset ugyanúgy javul, de ezek fedik le a problémák nagy részét.

Gyakorlati lépések:

1. Darabold fel a hosszú feladatokat. Minden 50 ms feletti feladat kockázatos. Bontsd kisebb részekre, és add vissza a vezérlést a böngészőnek köztük.
2. Adj vissza a fő szálnak (yield). A modern megközelítés a scheduler.yield(), ahol elérhető, egyébként egy setTimeout vagy egy await beszúrása is segít, hogy a böngésző közben feldolgozhassa a felhasználó kattintását.
3. Halaszd el a nem kritikus munkát. Ami nem az azonnali válaszhoz kell, azt tedd requestIdleCallback-be vagy az interakció utáni rajzolás utánra.
4. Csökkentsd a szállított JavaScriptet. Kód-szeletelés (code splitting), nem használt könyvtárak eltávolítása, lusta betöltés.
5. Fogd vissza a harmadik feleket. Töltsd be őket később, és mérlegeld, tényleg kell-e minden widget.
6. Tehermentesítsd a nehéz számítást. A tisztán számítási munkát Web Workerbe teheted, hogy le se terhelje a fő szálat.
7. Fogd vissza az újrarenderelést. Keretrendszerben memoizálj, told le az állapotot lejjebb, kerüld a felesleges nagy renderelést.

Egy egyszerű minta arra, hogyan add vissza a vezérlést egy hosszú ciklusban:

async function feldolgoz(elemek) { for (let i = 0; i < elemek.length; i++) { munka(elemek[i]); if (i % 50 === 0) { await new Promise(r => setTimeout(r)); } } }

Ebben a példában minden ötvenedik elem után a setTimeout visszaadja a vezérlést a böngészőnek, így egy közben érkező kattintás nem ragad be a ciklus végéig. Ahol elérhető, a scheduler.yield() ennél is jobb, mert a feladatod utána visszakapja a prioritását.

Egy praktikus ellenőrzőlista, mielőtt lezárnád a munkát:

• Mértem-e valós mobil terepadatot, nem csak asztali labort?
• Melyik szakasz dominál: az input-késleltetés, a feldolgozás vagy a megjelenítés?
• Van-e 50 ms feletti hosszú feladat a legfontosabb interakcióknál?
• Kikapcsolva egy-egy harmadik feles szkriptet, javul-e az INP?
• Bekapcsoltam-e a CPU-lassítást a tesztelés közben?

Az INP javítása ritkán egyetlen kapcsoló átbillentése. Inkább egy mérési kör: kideríted, melyik interakció a leglassabb, megnézed, melyik szakasza a szűk keresztmetszet, beavatkozol, majd újramérsz. Ez a módszeres kör segítheti, hogy az oldalad ténylegesen gyorsabbnak érződjön, ami jó eséllyel a felhasználói élményre és közvetve a keresési láthatóságra is pozitívan hat.

Források és további olvasnivalók

• Google Search Central: Core Web Vitals és oldalélmény dokumentáció
• web.dev: Interaction to Next Paint (INP) útmutató és küszöbértékek
• Chrome for Developers: Optimize INP és Long Animation Frames API dokumentáció
• Chrome User Experience Report (CrUX) dokumentáció
• W3C Event Timing API és Long Tasks API specifikációk