Optimalizácia INP: meranie a zlepšovanie interaktivity

Prečo je INP dôležitý pre technické SEO v Rakúsku

Interaction to Next Paint (INP) meria, ako rýchlo web reaguje na interakcie používateľov. Kliknutia, ťuknutia a vstupy z klávesnice spustia spracovanie, na ktorého konci je najbližší viditeľný snímok (paint). INP zachytáva oneskorenie počas celej návštevy stránky, nie iba pri prvom vstupe. Od 12. marca 2024 je INP stabilným Core Web Vital a nahrádza First Input Delay. Metrika je tak súčasťou signálov Page Experience, ktoré sú podľa dokumentácie Google zosúladené s hlavnými rankingovými systémami.

Pre B2B poskytovateľov v Rakúsku je to dôležité z dvoch dôvodov. Po prvé, reaktivita je obchodný faktor: analýza štyroch e-commerce webov ukázala konzistentne negatívnu koreláciu medzi INP a mierou konverzie, pričom konverzie v niektorých prípadoch trpeli už pri 100 ms, teda v „dobrom“ pásme. Po druhé, v Rakúsku prichádzajú o niečo viac ako dva z piatich prístupov z mobilných zariadení: podľa StatCounter sa o prístupy delia desktop s 57,6 % a mobil so 42,4 % (máj 2026). Pri 8,69 milióna používateľov internetu a penetrácii 95,3 % (október 2025) rozhoduje mobilný výkon o podstatnej časti viditeľnosti.

Prekážka je skutočná. Podľa DebugBear na mobile celosvetovo prešlo testom INP len 64,9 % webov, pri CLS to bolo 76,9 %. Ťažšie sa dalo splniť iba LCP s 54,9 %. Tieto hodnoty vychádzajú z dát CrUX z novembra 2023. Za rok 2024 uvádza Web Almanac 74 % webov s dobrým INP na mobile, ale 97 % na desktope. Rozdiel medzi zariadeniami zostáva veľký.

Ako INP funguje: tri fázy a rozhodujúci rozdiel oproti FID

INP rozkladá každú interakciu na tri fázy. Input Delay: čas, kým sa hlavné vlákno uvoľní a môže spustiť event handler. Vlákno blokované JavaScriptom túto fázu predlžuje. Processing Time: samotné vykonanie event handlerov, teda tvojej biznis logiky, aktualizácií frameworku a výpočtov. Presentation Delay: čas, kým prehliadač vykreslí výsledok a nakreslí ďalší snímok.

Hlavný rozdiel oproti First Input Delay je v rozsahu merania. FID zachytával iba oneskorenie prvého vstupu a ignoroval čas spracovania aj zobrazenia. INP sleduje všetky interakcie počas zobrazenia stránky a hlási (zjednodušene) najvyššiu relevantnú hodnotu. Web teda mohol mať dokonalý FID, a napriek tomu slabý INP, pretože neskoršie interakcie, napríklad otvorenie menu, filtrovanie zoznamu alebo odoslanie formulára, sú pomalé. Prahová hodnota: aspoň 75 % zobrazení stránok by malo dosiahnuť INP najviac 200 milisekúnd.

Hlavnou príčinou zlých hodnôt je preťažené hlavné vlákno. Dlhé úlohy ho blokujú a zdržujú každý nový vstup. Úlohy nad 50 ms sa považujú za Long Tasks. Dáta sú jednoznačné: mediánová mobilná stránka strávi 2 366 ms v Long Tasks oproti iba 329 ms na desktope, pri 14 namiesto 3 dlhých úlohách v mediáne. Total Blocking Time, bežný laboratórny proxy ukazovateľ pre INP, je na mobile v mediáne 1 208 ms oproti 67 ms na desktope, teda približne 18-krát vyšší.

Meranie INP: terénne dáta majú prednosť pred laboratórnymi

Pre spoľahlivú diagnostiku musíš oddeliť terénne a laboratórne dáta.

Terénne dáta (rozhodujúce): Pochádzajú od skutočných používateľov. Chrome User Experience Report (CrUX) napája PageSpeed Insights a Search Console. Na priebežné monitorovanie integruješ JavaScriptovú knižnicu web-vitals alebo riešenie Real User Monitoring (RUM). Iba terénne dáta odrážajú reálne zariadenia, kvalitu siete a vzorce interakcií. Práve tu sa ukazuje nevýhoda mobilu, ktorú spôsobuje skutočný výpočtový výkon a kvalita siete.

Laboratórne dáta (diagnostické): Lighthouse a Chrome DevTools poskytujú reprodukovateľné hodnoty v kontrolovanom prostredí. Samotný INP sa v laboratóriu nedá priamo merať, pretože potrebuje interakcie v priebehu času. Ako proxy namiesto neho slúži Total Blocking Time: ukazuje, nakoľko je hlavné vlákno počas načítania blokované. Laboratórne dáta sa hodia na ladenie a regresné testy v CI pipeline, hodnotenie v teréne však nikdy nenahradia.

Dôsledok: neoptimalizuj naslepo podľa skóre Lighthouse. Prioritizuj podľa percentilu. Hodnotu INP určuje pomalý koniec rozdelenia, teda 75. percentil a vyššie. Interakcia, ktorá je pri väčšine zobrazení rýchla, ale pri tretine potrebuje 600 ms, je tvoj skutočný problém.

Osvedčené postupy: odľahčenie hlavného vlákna a rýchlejšie interakcie

Najúčinnejšie páky znižujú prácu JavaScriptu alebo ju rozkladajú v čase.

Rozdelenie dlhých úloh: Rozlož prácu na menšie časti a vráť kontrolu hlavnému vláknu skôr, ako prekročíš 50 ms. scheduler.yield() po časti práce odovzdá kontrolu a v práci potom prednostne pokračuje. scheduler.postTask() umožňuje explicitné priority. setTimeout slúži ako šíršie podporovaný fallback. Od isInputPending() Google už odrádza, pretože toto API môže vstupy prehliadnuť. Radšej odovzdávaj kontrolu pravidelne, či už nejaký vstup čaká, alebo nie.

Zníženie záťaže JavaScriptu: Na mobile sa v mediáne doručí 558 KB JavaScriptu, z toho približne 206 KB nevyužitých, teda 44 %. Code splitting, tree shaking a odstraňovanie mŕtveho kódu priamo pôsobia na Input Delay a Processing Time. Načítaj iba to, čo daná stránka potrebuje, a nekritickú logiku odlož.

Optimalizácia event handlerov: Obmedz časté udalosti. Debouncing pri vstupoch a throttling pri handleroch pre scroll alebo resize zabraňujú zbytočnej práci. Prípadová štúdia redBus to presne dokladá: vďaka debouncingu scroll handlera a lokálnej správe stavu s oneskorenou synchronizáciou Reduxu klesol INP stránky vyhľadávania o 72 % pri náraste tržieb o 7 %. Vyhni sa drahým opätovným renderom, na vizuálne aktualizácie používaj requestAnimationFrame, na animácie nasadzuj CSS namiesto JavaScriptu a vykresľovanie odľahči pomocou content-visibility.

Skrotenie skriptov tretích strán a consent skriptov: Trackingové skripty, skripty tag managerov a consent skripty často bežia na hlavnom vlákne a blokujú ho práve vtedy, keď chce používateľ interagovať. Načítaj ich oneskorene, až po prvej interakcii alebo vo Web Workeri. Over si, ktoré skripty sú naozaj kritické.

Architektúra Next.js pre nízke hodnoty INP

Pri Next.js vzniká veľká časť záťaže INP pri hydratácii: prehliadač musí HTML vykreslené na serveri „oživiť“ klientskym JavaScriptom, čo zaťažuje hlavné vlákno.

React Server Components: Komponenty bez interaktivity sa renderujú na serveri a neposielajú do prehliadača žiadny JavaScript. To zmenšuje bundle, a tým aj náklady na hydratáciu priamo pri zdroji. Účinok je v praxi zdokumentovaný: Economic Times znížil Total Blocking Time z 3 260 ms na 120 ms a INP z približne 1 000 ms na 257 ms, okrem iného migráciou na Next.js. Výsledok: o 50 % menej odchodov a o 43 % viac zobrazení stránok.

Streaming a Suspense: Pomocou <Suspense> streamuješ časti stránky hneď, ako sú pripravené, a nečakáš na všetko. Tým sa skracuje čas do interaktivity viditeľných oblastí.

Selektívna hydratácia a dynamické importy: Ako klientske komponenty ("use client") označ iba interaktívne ostrovy. Ťažké klientske komponenty načítaj cez next/dynamic, ideálne až vtedy, keď sú potrebné. Tak sa vyhneš veľkým klientskym bundlom, ktoré blokujú hlavné vlákno hneď na začiatku.

Časté chyby pri optimalizácii INP

Sledovať iba skóre Lighthouse: Zelená laboratórna hodnota nezaručuje dobrý INP v teréne. Laboratórne dáta nepoznajú skutočné interakcie v priebehu času. Bez terénnych dát a pohľadu na percentily sa so skutočným problémom minieš.

Ignorovať najpomalší prípad: Kto sa pozerá na priemery, prehliadne 75. percentil. Práve tam sa INP meria. Najpomalšiu interakciu identifikuj cielene.

Nechať consent skripty a trackingové skripty bez zásahu: Skripty bannerov sa zobrazujú veľmi skoro a často blokujú práve prvú interakciu. Bez oneskoreného načítania alebo presunu mimo hlavného vlákna zostáva efekt viditeľný, najmä v reálnych podmienkach mobilných zariadení.

Nastaviť rovnaký rozpočet pre mobil a desktop: Mobilné zariadenia majú menší výpočtový výkon. Pri mediánovom TBT 1 208 ms na mobile oproti 67 ms na desktope potrebuje mobil prísnejší rozpočet na JavaScript. Bundle, ktorý je na desktope prijateľný, môže na mobile prahovú hodnotu prekročiť.

Hromadiť JavaScript bez kontroly: Ak sa 44 % doručeného JavaScriptu nevyužije, je to mŕtva záťaž. Pravidelne kontroluj pokrytie kódu (panel Coverage) a odstraňuj nepoužívaný kód.

Metriky, ladenie a prioritizácia v praxi

Na cielené ladenie dnes existujú presné nástroje.

Long Animation Frames (LoAF) API: Poskytuje podrobné dáta o dlhých snímkoch vrátane skriptov, ktoré ich spôsobili, a blokujúceho zdroja. Vďaka tomu pri dlhom snímku vidíš aj kód, ktorý ho spôsobil.

Panel Performance v Chrome DevTools: Zobrazuje stopu interakcie s Input Delay, Processing Time a Presentation Delay. Vidíš tak, ktorá z troch fáz dominuje, a podľa toho zameriaš opatrenie: Input Delay poukazuje na blokovanie hlavného vlákna, dlhý Processing Time na drahé handlery, vysoký Presentation Delay na drahé vykresľovanie alebo layout.

Atribúcia najpomalšej interakcie: Pomocou knižnice web-vitals v režime attribution alebo RUM riešenia zachytíš pri každom zobrazení stránky najhoršiu interakciu aj s kontextom. Prioritizuj podľa frekvencie a závažnosti na 75. percentile.

Odvodenie cieľových hodnôt pre Rakúsko: Nastav 200 ms ako tvrdú hornú hranicu, no naplánuj si rezervu, pretože konverzie podľa SpeedCurve v niektorých prípadoch trpia už pri 100 ms. Definuj samostatné rozpočty pre mobil a desktop. Keďže v Rakúsku podľa StatCounter v máji 2026 pripadalo na mobil 42,4 % návštevnosti a mobilné zariadenia napriek 99,5 % širokopásmových mobilných pripojení (3G/4G/5G) prekračujú prahovú hodnotu výrazne častejšie, mal by byť mobilný rozpočet tvojou hlavnou riadiacou veličinou.

Ďalšie súvislosti: INP, AI crawlery a súhlas podľa GDPR

INP nepôsobí izolovane. Pri Generative Engine Optimization (GEO) rozhoduje predovšetkým doručený obsah, ktorý zachytia AI crawlery. Štíhla architektúra renderovaná na serveri pomáha crawlerom aj používateľom: Server Components znižujú klientsky JavaScript a doručujú obsah priamo v počiatočnom HTML. Crawlery ho tak zachytia spoľahlivejšie a používatelia sa dočkajú rýchlejšej odozvy.

Súhlas podľa GDPR je najčastejšie slepé miesto. Platformy na správu súhlasov sa načítavajú už na začiatku, vykresľujú prekryvné vrstvy a po udelení súhlasu spustia kaskádu skriptov tretích strán, ktoré všetky zaťažujú hlavné vlákno. Pomôžu tri opatrenia, ktoré neohrozia súlad s právom. Trackingové skripty načítaj až po udelení súhlasu a oneskorene. Skripty, ktoré nie sú nevyhnutné, presuň na server alebo do Web Workera. A samotný consent skript udržuj čo najštíhlejší, pretože sa z definície zobrazí pred prvou interakciou. Hlavné vlákno tak zostane voľné, keď používateľ banner zatvorí, a práve táto prvá interakcia sa započíta do INP.