Interaction to Next Paint (INP)

Čo je INP (Interaction to Next Paint) a prečo je dôležitý

INP (Interaction to Next Paint) je metrika rýchlosti odozvy rozhrania, ktorá meria, ako rýchlo stránka vizuálne zareaguje na interakciu používateľa. Na rozdiel od historickej metriky FID (First Input Delay) sleduje celý priebeh interakcie až po najbližšie viditeľné prekreslenie (paint) a zohľadňuje tak nielen oneskorenie pri štarte, ale aj spracovanie a vykreslenie výsledku. V Core Web Vitals je INP primárnym ukazovateľom odozvy a kvality interakcií.

Ako sa INP počíta: tri fázy interakcie

• Input delay – doba od vstupu (klik, tap, klávesa) po začiatok spracovania handlera na hlavnom vlákne.
• Processing time – čas vykonávania obslužného kódu (event handler, logika, aktualizácia stavu).
• Presentation delay – doba potrebná, kým prehliadač zaktualizuje DOM/CSSOM, rozloženie, maľovanie a výsledok sa objaví na obrazovke.

INP je definovaný ako zástupca „najhoršej typickej interakcie“ na reláciu (napr. 98. percentil interakcií), aby sa penalizovali sporadické, ale reálne pociťované špičky latencie.

Prahové hodnoty: čo je dobré, čo treba zlepšiť a čo je zlé

• Dobré: ≤ 200 ms (používateľ subjektívne vníma okamžitú odozvu).
• Potrebné zlepšenie: > 200 ms a ≤ 500 ms (odozva je citeľná, ale tolerovateľná).
• Zlé: > 500 ms (frustrujúca odozva, znižuje konverzie a angažovanosť).

Aké interakcie INP sleduje

• Ukazovacia interakcia: klik myšou, tap na dotyku.
• Textová interakcia: stlačenie klávesy, potvrdenie formulára.
• Kompozitné gestá: napr. rozbalenie menu, prepnutie tabu, otvorenie modalu.

Scroll a gestá so „samostatným“ vláknom (compositor thread) sa zvyčajne nepočítajú, pokiaľ nie sú spojené s event handlerom, ktorý blokuje hlavné vlákno.

Prepojenie s ostatnými Core Web Vitals

• LCP (Largest Contentful Paint) – vnímané načítanie; optimalizácia LCP znižuje tlak na hlavné vlákno na začiatku relácie.
• CLS (Cumulative Layout Shift) – stabilita rozloženia; zmenšuje presentation delay po interakcii.
• INP – dynamická odozva po načítaní; dotýka sa najmä JavaScriptu a renderovacích priechodov.

Typické príčiny zlého INP

• Dlhé úlohy (Long Tasks > 50 ms) na hlavnom vlákne – bundly, synchronné výpočty, JSON parsovanie, zložité slučky.
• Nadmerná prácnosť v event handleroch – komplexná logika, masívne DOM manipulácie, synchronné I/O (napr. localStorage).
• Reflow/repaint bubliny – časté čítanie a zapisovanie do rozloženia v jednom ticku.
• Hydratácia SPA/MPA – oneskorené pripojenie handlerov, blokujúce inicializácie knižníc.
• Render „na všetko“ – zbytočné re-renderovanie celého stromu komponentov pri drobnej zmene stavu.

Diagnostika: laboratórne vs. terénne merania

• Laboratórne (syntetické) – pomocou nástrojov ako Lighthouse alebo WebPageTest. Vhodné na iterácie, ale INP je interakčná metrika, preto lab hodnoty môžu byť len indikatívne.
• Terénne (RUM) – reálne zariadenia a siete. Zbierajte percentily (p50/p75/p95) a segmentujte podľa zariadení, OS, prehliadača a cesty (page → interaction type).

Implementujte knižnicu web-vitals alebo vlastné RUM meranie, zachytávajte typ interakcie, časové značky a identifikátor komponentu.

Merací plán pre INP: čo logovať

• Časové zložky: input delay, processing time, presentation delay, celkový INP.
• Kontext: typ eventu, názov komponentu (napr. „AddToCartButton“), či išlo o prvú interakciu po zobrazení.
• Technické premenné: veľkosť JS na stránke, počet dlhých úloh, TTFB, device memory, effective connection type.
• Výsledok: či došlo k navigácii, otvoreniu modalu, validácii formulára, atď.

Optimalizačná stratégia: od architektúry po komponenty

1. Obmedzte prácu na hlavnom vlákne – rozsekajte dlhé úlohy (scheduler.postTask, requestIdleCallback, chunkovanie slučiek), využívajte Web Workers na CPU náročné operácie.
2. Lazujte hydratáciu – partial/deferrable hydration, ostrovná architektúra, selektívne pripájanie handlerov až pri viditeľnosti alebo intent signáli.
3. Minimalizujte JS – code-splitting na úrovni route aj komponentu, tree-shaking, odstraňovanie polyfillov pre moderné prehliadače.
4. Event handlery robte krátke – nech handler iba zaznamená intent, spustí mikrotask a rýchlo vráti kontrolu; UI update batcheujte.
5. Optimalizujte render – memoizácia, selektívne re-renderovanie (signals/store architektúry), virtuálny list/virtualizácia, vyhnite sa synchronnému layout thrashingu.
6. CSS a layout – používajte containment (content-visibility, contain), predvídateľné veľkosti prvkov, vyhnite sa masívnym reflow pri interakciách.
7. Grafika a animácie – preferujte kompozitor (transform/opacity), vyhnite sa box-shadow a veľkým blur efektom počas interakcie.

Vzorový dizajn handlera s minimom blokovania

Pri kliknutí vykonajte len nevyhnutné minimum a plánujte ďalšie kroky asynchrónne:

• Okamžite zmeňte stav tlačidla (loading/disabled) a priraďte ARIA atribúty.
• Spustite asynchrónnu logiku (fetch, výpočty) mimo hlavného vlákna alebo v mikro/makro taskoch.
• Batchujte DOM zmeny do jedného renderu (napr. v rámci requestAnimationFrame).

Takto sa presentation delay skráti a používateľ vidí reakciu prakticky okamžite (aj keby finálne dáta dorazili neskôr).

Frameworky a INP: odporúčania podľa typu UI

• React: používajte concurrent rendering, useTransition pre neurgentné aktualizácie, memoizujte selektívne, server components pre zníženie JS na klientovi.
• Vue: defineComponent + script setup, granularita reaktivity (signals), lazy registrácia komponentov, v-memo a keep-alive pre ťažké subtree.
• Solid/Qwik/Svelte: využite jemnozrnnú reaktivitu, resumé hydratácie, ostrovný model a streaming SSR.
• MPA s malým JS: progresívne rozširujte interakcie; použite defer, priority hints, modulárny import iba pre interaktívne ostrovy.

Minimalizácia presentation delay: taktiky pre okamžitý vizuálny feedback

• Optimistické UI – okamžite zobrazte očakávanú zmenu (napr. prepnutý stav), neskôr prípadne korekcia.
• Skeletony a placeholdery – vizuálny dôkaz odozvy, ktorý neblokuje thread.
• Predpripravené vrstvy – rezervujte miesto pre modal/panel dopredu, aby otvorenie nevyvolalo ťažký reflow.
• Predbežná cache – prefetch/prerender najbližších akcií (napr. detail po kliknutí na kartu).

Prioritizácia a plán refaktoringu pre lepší INP

1. Identifikujte „horúce“ interakcie – podľa frekvencie a vplyvu na cestu ku konverzii (pridanie do košíka, filtrovanie, vyhľadávanie, login).
2. Namapujte príčiny – trace hlavných dlhých úloh, kto ich spúšťa (knižnica, komponent, polyfill).
3. Stanovte ciele – p75 INP ≤ 200 ms pre top interakcie; p95 ≤ 300–400 ms ako „guardrail“.
4. Iterujte – rýchle víťazstvá (debounce/throttle, lazy importy), následne architektonické zmeny (SSR, ostrovy, workers).

Formuláre a INP: špeciálne odporúčania

• Validáciu rozdeľte na lightweight (okamžitá) a heavy (async po uvoľnení hlavného vlákna).
• Pri submitte zobrazte stav do 50 ms (spinner, disable), sieťový request spúšťajte asynchrónne.
• Vyhnite sa synchronným čítaniam layoutu pri každom keypress-e.

Komponenty filtrov a zoznamov: ako sa vyhnúť drahým re-renderom

• Virtualizujte zoznamy, batchujte zmeny filtrov (apply na jedno kliknutie).
• Oddeľte stav UI (vizuálny) od stavu dát (filter query) a synchronizujte ich pri idle.
• Prepočty filtrov delegujte na web worker, UI nech je okamžité.

Sieť a INP: prečo rýchla odpoveď nestačí

Sieťové oneskorenie ovplyvňuje „hot path“ až po kliknutí (fetch). Aj keď má server rýchlu odozvu, zlé spracovanie na klientovi (parsing JSON, render) môže presentation delay výrazne predĺžiť. Preto optimalizujte aj formát dát (streaming, partial responses, menšie JSON, kompresia) a príjem na klientovi (inkrementálne zobrazovanie).

Monitoring a reporting: KPI, alerty, segmenty

• Hlavná KPI: p75 INP na stránku a na interakčný typ.
• Segmentácia: zariadenie (mobile/desktop), prehliadač, krajina, siete (4G/5G/Wi-Fi), vstupná cesta.
• Korelácie: počet dlhých úloh, veľkosť JS, TTI/TTFB, počet re-renderov.
• Alerty: náhle zhoršenia p95 INP po releasi (regresia v konkrétnom module).

Check-list na zlepšenie INP (rýchle víťazstvá)

• Rozsekajte všetky úlohy > 50–75 ms; zaveďte sledovanie Long Tasks.
• Presuňte ťažké výpočty do Web Workerov.
• Skontrolujte, že event handlery vracajú kontrolu do 50 ms.
• Batchujte DOM zmeny; čítania layoutu oddeľte od zápisov.
• Znížte JS o 20–40 % (code-splitting, odstránenie nepoužívaných balíkov).
• Zaveďte optimistické UI a okamžitý vizuálny feedback.
• Partial/deferrable hydration a ostrovy pre interaktívne sekcie.

Príklad „pred/po“: tlačidlo pridať do košíka

• Pred: klik → synchronný výpočet ceny + render celého košíka → fetch → reflow. INP ~ 600–900 ms.
• Po: klik → okamžitý toggle stavu + badge + async „enqueue“ výpočtov (worker) → inkrementálny update. INP ~ 120–200 ms.

Prístupnosť (a11y) a vnímaná odozva

• Aktualizujte ARIA live regióny po interakcii, aby čítačky obrazov oznamovali zmeny bez oneskorenia.
• Focus management – presné presuny focusu po otvorení modalu alebo po potvrdení akcie.
• Kontrastné, prehľadné stavy „pressed/selected/loading“ – vizuálne potvrdenie okamžite.

Anti-regresný proces: ako INP udržať dlhodobo

• Každý PR s interakciami musí prejsť syntetickým testom (trace) a RUM „canary“ percentilmi.
• Guardrails: ak p95 INP stúpne > X %, release sa blokuje.
• Automatizované rozdelenie bundlov, kontrola limitov veľkosti a detekcia nových dlhých úloh.

Meranie úspechu: vplyv na biznis

• Korelácia INP zlepšenia s CTR na kľúčových prvkoch (menu, filtre, košík).
• Vplyv na konverzie a opustenie košíka po skrátení presentation delay.
• Zníženie zákazníckych ticketov súvisiacich s „nefunkčným“ UI.

Zhrnutie

INP meria reálnu kvalitu odozvy na interakcie – od vstupu až po viditeľnú zmenu. Zlepšenie si vyžaduje zníženie práce na hlavnom vlákne, krátke handlery, optimalizovaný render a architektúru zameranú na ostrovy, workers a inkrementálne aktualizácie. Pri cieľoch p75 ≤ 200 ms a dôslednom RUM monitoringu sa odozva stáva predvídateľnou, používateľsky príjemnou a priamo prispieva k lepším konverziám aj SEO výsledkom.