INP (Interaction to Next Paint): Odezva na uživatelskou interakci

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

INP (Interaction to Next Paint) je metrika rychlosti odezvy uživatelského 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 zpoždění při startu, ale i zpracování a vykreslení výsledku. V rámci Core Web Vitals je INP primárním ukazatelem odezvy a kvality interakcí.

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

Input delay – doba od vstupu (kliknutí, tapnutí, stisk klávesy) po začátek zpracování handleru na hlavním vlákně.
Processing time – čas 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í, vykreslení a aby se výsledek zobrazil na obrazovce.

INP je definován jako reprezentant „nejhorší typické interakce“ během relace (např. 98. percentil interakcí), aby byly penalizovány ojedinělé, ale uživatelsky vnímané špičky latence.

Hranice hodnot: co je dobré, co je potřeba zlepšit a co je špatné

Dobré: ≤ 200 ms (uživatel subjektivně vnímá okamžitou odezvu).
Potřeba zlepšení: > 200 ms a ≤ 500 ms (odezva je znatelná, ale tolerovatelná).
Špatné: > 500 ms (frustrující odezva, snižuje konverze a angažovanost).

Jaké interakce INP sleduje

Ukazovací interakce: klik myší, tapnutí na dotykové obrazovce.
Textové interakce: stisk klávesy, potvrzení formuláře.
Kompozitní gesta: například rozbalení menu, přepnutí záložky, otevření modalu.

Scrollování a gesta vykonávaná na „samostatném“ vlákně kompozitoru (compositor thread) se obvykle nezapočítávají, pokud nejsou spojena s event handlerem, který blokuje hlavní vlákno.

Propojení s ostatními Core Web Vitals

LCP (Largest Contentful Paint) – vnímané načítání; optimalizace LCP snižuje zatížení hlavního vlákna na začátku relace.
CLS (Cumulative Layout Shift) – stabilita rozložení; snižuje presentation delay po interakci.
INP – dynamická odezva po načtení; týká se především JavaScriptu a renderovací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.
Nadměrná náročnost v event handleru – komplexní logika, masivní manipulace s DOM, synchronní vstupně-výstupní operace (např. localStorage).
Reflow/repaint smyčky – časté čtení a zápis do rozložení během jednoho ticku.
Hydratace SPA/MPA – zpožděné připojení handlerů, blokující inicializace knihoven.
Render „pro všechen obsah“ – zbytečné překreslování celého stromu komponent při drobné změně stavu.

Diagnostika: laboratorní vs. reálné měření

Laboratorní (syntetické) – pomocí nástrojů jako Lighthouse nebo WebPageTest. Vhodné pro iterace, ale INP je interakční metrika, proto laboratorní hodnoty mohou být pouze orientační.
Reálné (RUM) – měření na skutečných zařízeních a sítích. Sbírejte percentily (p50/p75/p95) a segmentujte podle zařízení, operačního systému, prohlížeče a cesty (stránka → typ interakce).

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

Měřící plán pro INP: co logovat

Časové složky: input delay, processing time, presentation delay, celkový INP.
Kontext: typ eventu, název komponenty (např. „AddToCartButton“), zda šlo o první interakci po zobrazení stránky.
Technické proměnné: velikost JS na stránce, počet dlouhých úloh, TTFB, zařízení a jeho paměť, typ připojení (effective connection type).
Výsledek: zda došlo k navigaci, otevření modalu, validaci formuláře apod.

Optimalizační strategie: od architektury po komponenty

Omezte práci na hlavním vlákně – rozdělte dlouhé úlohy (scheduler.postTask, requestIdleCallback, dělení smyček), využívejte Web Workers pro CPU náročné operace.
Lazy hydratace – částečná/odkládaná hydratace, ostrovní architektura, selektivní připojování handlerů při viditelnosti nebo signálu uživatelského záměru.
Minimalizujte JS – code-splitting na úrovni rout i komponent, tree-shaking, odstraňování polyfillů pro moderní prohlížeče.
Event handlery dělejte krátké – aby handler pouze zaznamenal záměr, spustil mikrotask a rychle vrátil kontrolu; aktualizace UI dávkujte.
Optimalizujte renderování – memoizace, selektivní re-renderování (signály, store architektury), virtuální seznamy/virtualizace, vyhýbejte se synchronnímu layout thrashingu.
CSS a layout – používejte containment (content-visibility, contain), předvídatelné velikosti prvků, vyhněte se masivním reflow při interakcích.
Grafika a animace – preferujte compositor (transformace, opacity), vyhněte se box-shadow a velkým blur efektům během interakce.

Vzorový design handleru s minimem blokování

Při kliknutí vykonejte pouze nezbytné minimum a plánujte další kroky asynchronně:

Okamžitě změňte stav tlačítka (loading/disabled) a přiřaďte ARIA atributy.
Spusťte asynchronní logiku (fetch, výpočty) mimo hlavní vlákno nebo v mikro/makro tasku.
Dávejte DOM změny do jednoho renderu (např. v rámci requestAnimationFrame).

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

Frameworky a INP: doporučení podle typu UI

React: používejte concurrent rendering, useTransition pro neurgentní aktualizace, memoizujte selektivně, server components pro snížení množství JS na klientovi.
Vue: defineComponent + script setup, granularita reaktivity (signály), lazy registrace komponent, v-memo a keep-alive pro těžké podstromy.
Solid/Qwik/Svelte: využijte jemnozrnnou reaktivitu, shrnutí hydratace, ostrovní model a streaming SSR.
MPA s malým JS: progresivně rozšiřujte interakce; použijte defer, priority hinty, modulární import pouze pro interaktivní ostrovy.

Minimalizace presentation delay: taktiky pro okamžitou vizuální zpětnou vazbu

Optimistické UI – okamžitě zobrazte očekávanou změnu (např. přepnutý stav), později případná korekce.
Skeletony a placeholdery – vizuální důkaz odezvy, který neblokuje vlákno.
Předpřipravené vrstvy – rezervujte místo pro modal/panel dopředu, aby otevření nevyvolalo náročný reflow.
Předběžná cache – prefetch/prerender nejbližších akcí (např. detail po kliknutí na kartu).

Prioritizace a plán refaktoringu pro lepší INP

Identifikujte „horké“ interakce – podle frekvence a vlivu na cestu ke konverzi (přidání do košíku, filtrování, vyhledávání, přihlášení).
Namapujte příčiny – trace hlavních dlouhých úloh, kdo je spouští (knihovna, komponenta, polyfill).
Stanovte cíle – p75 INP ≤ 200 ms pro top interakce; p95 ≤ 300–400 ms jako „guardrail“.
Iterujte – rychlé vítězství (debounce/throttle, lazy importy), následně architektonické změny (SSR, ostrovy, workers).

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

Rozdělte validaci na lehký (okamžitý) a těžký (asynchronní po uvolnění hlavního vlákna).
Při odeslání zobrazte stav do 50 ms (spinner, zakázání), síťový request spusťte asynchronně.
Vyhněte se synchronnímu čtení layoutu při každém stisku klávesy.

Komponenty filtrů a seznamů: jak se vyhnout náročným re-renderům

Virtualizujte seznamy, dávkujte změny filtrů (aplikujte na jedno kliknutí).
Oddělte stav UI (vizuální) od stavu dat (dotaz na filtr) a synchronizujte je při idle.
Přepočty filtrů delegujte na web worker, UI nechte okamžité.

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

Síťové zpoždění ovlivňuje „hot path“ až po kliknutí (fetch). I když má server rychlou odezvu, špatné zpracování na klientovi (parsování JSON, renderování) může výrazně prodloužit presentation delay. Proto optimalizujte formát dat (streaming, částečné odpovědi, menší JSON, komprese) a příjem na klientovi (inkrementální zobrazování).

Monitoring a reporting: KPI, alerty, segmenty

Hlavní KPI: p75 INP na stránku a dle typu 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 re-renderů.
Alerty: náhlé zhoršení p95 INP po releasu (regrese v konkrétním modulu).

Check-list pro zlepšení INP (rychlé vítězství)

Rozdělte všechny úlohy > 50–75 ms; zaveďte sledování Long Tasks.
Přesuňte těžké výpočty do Web Workerů.
Zkontrolujte, že event handlery vracejí kontrolu do 50 ms.
Dávkujte DOM změny; oddělte čtení layoutu od zapisování.
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.
Partial/deferrable hydratace a ostrovy pro interaktivní sekce.

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

Před: klik → synchronní výpočet ceny + render celého košíku → fetch → reflow. INP ~ 600–900 ms.
Po: klik → okamžitý toggle stavu + badge + asynchronní „enqueue“ výpočtů (worker) → inkrementální update. INP ~ 120–200 ms.

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

Aktualizujte ARIA live regiony po interakci, aby čtečky obrazov oznamovaly změny bez zpoždění.
Focus management – přesné přesuny fokusů po otevření modalu nebo po potvrzení akce.
Kontrastní, přehledné stavy „pressed/selected/loading“ – okamžité vizuální potvrzení.

Anti-regresní proces: jak INP udržet dlouhodobě

Každý PR s interakcemi musí projít syntetickým testem (trace) a RUM „canary“ percentily.
Guardrails: pokud p95 INP vzroste o více než X %, releas se blokuje.
Automatizované dělení bundlů, kontrola limitů velikosti a detekce nových dlouhých úloh.