INP (Interaction to Next Paint): odezva na interakce uživatele

Co je INP (Interaction to Next Paint) a proč je důležitý

INP (Interaction to Next Paint) je metrika rychlosti odezvy rozhraní, která měří, jak rychle stránka vizuálně reaguje na interakci uživatele. Na rozdíl od historické metriky FID (First Input Delay) sleduje celý průběh interakce až po nejbližší viditelné překreslení (paint), a zohledňuje tak nejen prodlevu při zahájení, ale také zpracování a vykreslení výsledku. V Core Web Vitals je INP hlavním ukazatelem odezvy a kvality interakcí.

Jak se INP počítá: tři fáze interakce

Input delay – doba od vstupu (kliknutí, klepnutí, stisknutí klávesy) po zahájení zpracování handleru na hlavním vlákně.
Processing time – doba vykonávání obslužného kódu (event handler, logika, aktualizace stavu).
Presentation delay – doba potřebná k tomu, aby prohlížeč aktualizoval DOM/CSSOM, rozložení a vykreslení a výsledek se objevil na obrazovce.

INP je definováno jako zástupce „nejhorší typické interakce“ v rámci relace (např. 98. percentil interakcí), aby byly penalizovány občasné, ale skutečně pociťované špičky latence.

Prahové hodnoty: co je dobré, co je třeba zlepšit a co je špatné

Dobré: ≤ 200 ms (uživatel subjektivně vnímá odezvu jako okamžitou).
Je třeba zlepšit: > 200 ms a ≤ 500 ms (odezva je znatelná, ale snesitelná).
Špatné: > 500 ms (frustrující odezva, která snižuje konverze a zapojení uživatelů).

Jaké interakce INP sleduje

Ukazovací interakce: kliknutí myší, klepnutí na dotykové obrazovce.
Textová interakce: stisknutí klávesy, odeslání formuláře.
Kompozitní gesta: např. rozbalení nabídky, přepnutí karty, otevření modálního okna.

Posouvání a gesta se „samostatným“ vláknem (compositor thread) se obvykle nepočítají, pokud nejsou spojena s event handlerem, který blokuje hlavní vlákno.

Souvislost s ostatními Core Web Vitals

LCP (Largest Contentful Paint) – vnímaná rychlost načtení; optimalizace LCP snižuje zatížení hlavního vlákna na začátku relace.
CLS (Cumulative Layout Shift) – stabilita rozložení; zkracuje presentation delay po interakci.
INP – dynamická odezva po načtení; týká se především JavaScriptu a vykreslovacích průchodů.

Typické příčiny špatného INP

Dlouhé úlohy (Long Tasks > 50 ms) na hlavním vlákně – bundly, synchronní výpočty, parsování JSON, složité smyčky.
Příliš náročné zpracování v event handlerech – komplexní logika, rozsáhlé manipulace s DOM, synchronní I/O (např. localStorage).
Kaskády reflow/repaint – časté čtení a zapisování do rozložení v rámci jednoho ticku.
Hydratace SPA/MPA – opožděné připojení handlerů, blokující inicializace knihoven.
Vykreslování „všeho“ – zbytečné opětovné vykreslování celého stromu komponent při drobné změně stavu.

Diagnostika: laboratorní versus terénní měření

Laboratorní (syntetické) – pomocí nástrojů, jako jsou Lighthouse nebo WebPageTest. Vhodné pro iterace, ale INP je interakční metrika, proto mohou být laboratorní hodnoty pouze orientační.
Terénní (RUM) – skutečná zařízení a sítě. Shromažďujte percentily (p50/p75/p95) a segmentujte podle zařízení, operačního systému, prohlížeče a cesty (page → interaction type).

Implementujte knihovnu web-vitals nebo vlastní měření RUM a zaznamenávejte typ interakce, časová razítka a identifikátor komponenty.

Plán měření INP: co zaznamenávat

Časové složky: input delay, processing time, presentation delay, celkové INP.
Kontext: typ události, název komponenty (např. „AddToCartButton“), zda šlo o první interakci po zobrazení.
Technické proměnné: velikost JS na stránce, počet dlouhých úloh, TTFB, paměť zařízení, typ aktivního síťového připojení.
Výsledek: zda došlo k navigaci, otevření modálního okna, ověření formuláře atd.

Strategie optimalizace: od architektury po komponenty

Omezte práci na hlavním vlákně – rozdělte dlouhé úlohy (scheduler.postTask, requestIdleCallback, rozdělení smyček na menší části), pro operace náročné na CPU využívejte Web Workers.
Odložte hydrataci – částečná/odložitelná hydratace, ostrovní architektura, selektivní připojování handlerů až při viditelnosti nebo signálu záměru.
Minimalizujte JS – code-splitting na úrovni tras i komponent, tree-shaking, odstranění polyfillů pro moderní prohlížeče.
Event handlery udržujte krátké – handler by měl pouze zaznamenat záměr, spustit mikroulohu a rychle předat řízení dál; aktualizace UI dávkujte.
Optimalizujte vykreslování – memoizace, selektivní opětovné vykreslování (architektury založené na signals/store), virtuální seznamy, vyhněte se synchronnímu přetěžování layoutu.
CSS a rozložení – používejte containment (content-visibility, contain), předvídatelné velikosti prvků a vyhněte se rozsáhlému reflow při interakcích.
Grafika a animace – upřednostňujte kompozitor (transform/opacity), během interakce se vyhněte box-shadow a výrazným efektům rozostření.

Vzorový návrh handleru s minimálním blokováním

Při kliknutí proveďte pouze to nejnutnější a další kroky naplánujte asynchronně:

Okamžitě změňte stav tlačítka (načítání/zakázáno) a nastavte atributy ARIA.
Spusťte asynchronní logiku (fetch, výpočty) mimo hlavní vlákno nebo v rámci mikro-/makroúloh.
Změny DOM slučte do jednoho vykreslení (např. pomocí requestAnimationFrame).

Tím se zkrátí presentation delay a uživatel uvidí reakci prakticky okamžitě (i kdyby finální data dorazila později).

Frameworky a INP: doporučení podle typu UI

React: používejte souběžné vykreslování, useTransition pro neurgentní aktualizace, selektivní memoizaci a serverové komponenty pro omezení JS na straně klienta.
Vue: defineComponent + script setup, granularita reaktivity (signals), líná registrace komponent, v-memo a keep-alive pro náročné podstromy.
Solid/Qwik/Svelte: využívejte jemnozrnnou reaktivitu, obnovitelnou hydrataci, ostrovní model a streaming SSR.
MPA s malým množstvím JS: interakce rozšiřujte postupně; použijte defer, nápovědy priority a modulární importy pouze pro interaktivní ostrovy.

Minimalizace presentation delay: taktiky pro okamžitou vizuální odezvu

Optimistické UI – okamžitě zobrazte očekávanou změnu (např. přepnutý stav), případnou opravu proveďte později.
Kostry a zástupné prvky – vizuální potvrzení odezvy, které neblokuje vlákno.
Připravené vrstvy – předem vyhraďte místo pro modální okno/panel, aby jeho otevření nevyvolalo náročný reflow.
Předběžná cache – použijte prefetch/prerender pro nadcházející akce (např. detail po kliknutí na kartu).

Stanovení priorit a plán refaktoringu pro lepší INP

Identifikujte „nejčastější“ interakce – podle frekvence a vlivu na cestu ke konverzi (přidání do košíku, filtrování, vyhledávání, přihlášení).
Zmapujte příčiny – trasujte hlavní dlouhé úlohy a zjistěte, kdo je spouští (knihovna, komponenta, polyfill).
Stanovte cíle – p75 INP ≤ 200 ms pro nejdůležitější interakce; p95 ≤ 300–400 ms jako „ochrannou hranici“.
Iterujte – rychlé výhry (debounce/throttle, líné importy) a následně architektonické změny (SSR, ostrovy, workers).

Formuláře a INP: speciální doporučení

Ověřování rozdělte na lehké (okamžité) a náročné (asynchronní, po uvolnění hlavního vlákna).
Při odeslání zobrazte stav do 50 ms (spinner, deaktivace), síťový požadavek spusťte asynchronně.
Vyhněte se synchronnímu čtení rozložení při každém stisknutí klávesy.

Komponenty filtrů a seznamů: jak se vyhnout nákladnému opětovnému vykreslování

Virtualizujte seznamy a dávkujte změny filtrů (použijte je po jediném kliknutí).
Oddělte stav UI (vizuální) od stavu dat (dotaz filtru) a synchronizujte je v době nečinnosti.
Výpočty filtrů přesuňte do web workeru, UI musí reagovat okamžitě.

Síť a INP: proč rychlá odpověď nestačí

Zpoždění sítě ovlivňuje „hot path“ až po kliknutí (fetch). I když server odpovídá rychle, špatné zpracování na straně klienta (parsování JSON, vykreslování) může presentation delay výrazně prodloužit. Optimalizujte proto také formát dat (streaming, částečné odpovědi, menší JSON, komprese) a jejich zpracování na klientovi (postupné zobrazování).

Monitoring a reporting: KPI, upozornění, segmenty

Hlavní KPI: p75 INP pro stránku a typ interakce.
Segmentace: zařízení (mobilní/desktop), prohlížeč, země, sítě (4G/5G/Wi-Fi), vstupní cesta.
Korelace: počet dlouhých úloh, velikost JS, TTI/TTFB, počet opětovných vykreslení.
Upozornění: náhlé zhoršení p95 INP po vydání nové verze (regrese v konkrétním modulu).

Kontrolní seznam pro zlepšení INP (rychlé výhry)

Rozdělte všechny úlohy > 50–75 ms na menší části; zaveďte sledování Long Tasks.
Přesuňte náročné výpočty do Web Workerů.
Ověřte, že event handlery předávají řízení dál do 50 ms.
Dávkujte změny DOM; čtení rozložení oddělte od zápisů.
Snižte množství JS o 20–40 % (code-splitting, odstranění nepoužívaných balíčků).
Zaveďte optimistické UI a okamžitou vizuální odezvu.
Částečná/odložitelná hydratace a ostrovy pro interaktivní sekce.

Příklad „před/po“: tlačítko přidat do košíku

Před: kliknutí → synchronní výpočet ceny + vykreslení celého košíku → fetch → reflow. INP ~ 600–900 ms.
Po: kliknutí → okamžité přepnutí stavu + odznak + asynchronní zařazení výpočtů do fronty (worker) → postupná aktualizace. INP ~ 120–200 ms.

Přístupnost (a11y) a vnímaná odezva

Po interakci aktualizujte živé oblasti ARIA, aby čtečky obrazovky oznamovaly změny bez prodlevy.
Správa fokusu – přesné přesunutí fokusu po otevření modálního okna nebo potvrzení akce.
Kontrastní a přehledné stavy „pressed/selected/loading“ – okamžité vizuální potvrzení.

Proces prevence regresí: jak INP dlouhodobě udržet

Každý PR obsahující interakce musí projít syntetickým testem (trace) a kontrolou percentilů RUM „canary“.
Ochranné limity: pokud p95 INP vzroste o > X %, vydání nové verze se zablokuje.
Automatizované rozdělení bundlů, kontrola limitů velikosti a detekce nových dlouhých úloh.

Měření úspěchu: dopad na byznys

Korelace zlepšení INP s CTR u klíčových prvků (nabídka, filtry, košík).
Vliv na konverze a opuštění košíku po zkrácení presentation delay.
Snížení počtu zákaznických požadavků souvisejících s „nefunkčním“ UI.

Shrnutí

INP měří skutečnou kvalitu odezvy na interakce – od vstupu až po viditelnou změnu. Zlepšení vyžaduje omezení práce na hlavním vlákně, krátké handlery, optimalizované vykreslování a architekturu zaměřenou na ostrovy, workery a postupné aktualizace. Při cílové hodnotě p75 ≤ 200 ms a důsledném monitoringu RUM se odezva stává předvídatelnou a příjemnou pro uživatele a přímo přispívá k vyšším konverzím i lepším výsledkům SEO.