INP pod 200ms: Pokročilé Techniky pro Rychlejší Odezvu Webu

V dubnu 2025 jsem řešila záhadu. Klient provozoval e-shop s elektronikou. Web se načítal bleskově — LCP pod 2 sekundy. Přesto zákaznická linka řešila stížnosti každý týden: „Váš web je rozbitý, tlačítka nefungují."

Změřila jsem FID a INP. Hodnota 780 ms. Katastrofa. Po týdnu optimalizací jsme INP dostali na 140 ms. Stížnosti zmizely. Konverzní poměr vzrostl o 34 %.

Proč Interaction to Next Paint (INP) nahradilo FID (a proč je to dobře)

FID vs INP - co přesně se změnilo

FID (First Input Delay) měřil zpoždění pouze u první interakce. Zákazník přišel na web, klikl poprvé — a FID změřil, jak rychle prohlížeč začal reagovat.

Problém? Co když bylo první kliknutí rychlé, ale druhé, třetí nebo desáté bylo pomalé? FID to nezachytil. A právě ty pozdější interakce jsou často nejdůležitější — přidání do košíku, odeslání objednávky, vyplnění formuláře.

INP (Interaction to Next Paint) měří všechny interakce během celé návštěvy. Kliknutí, ťuknutí na mobilu, stisk klávesy — všechno. A vybírá tu nejhorší hodnotu (přesněji 98. percentil, aby se ignorovaly extrémní výjimky způsobené NAPř. pomalým připojením).

Další zásadní rozdíl: FID měřil jen čas do začátku zpracování. INP měří čas až do zobrazení vizuální změny. To je obrovský rozdíl — web mohl začít zpracovávat kliknutí rychle (dobré FID), ale trvalo mu věčnost, než něco zobrazil (špatné INP).

Proč INP lépe odráží reálnou zkušenost

Představte si nákup v e-shopu:

1. Zákazník klikne na kategorii — rychlé
2. Použije filtr ceny — rychlé
3. Klikne na produkt — rychlé
4. Klikne na „Přidat do košíku" — trvá 800 ms

FID by řekl: „Vše v pořádku, první klik byl rychlý." INP řekne: „Máte problém, přidání do košíku trvá příliš dlouho."

A právě to čtvrté kliknutí rozhoduje o tom, jestli zákazník nakoupí.

Časová osa: od FID k INP

• Červen 2021: Google zavádí Core Web Vitals včetně FID
• Květen 2022: Google oznamuje INP jako experimentální metriku
• Únor 2023: Google potvrzuje, že INP nahradí FID
• 12. března 2024: INP oficiálně nahrazuje FID v Core Web Vitals
• Prosinec 2025: Google zvyšuje váhu technických faktorů v rámci Core Update
• 2026: INP je klíčovou metrikou — weby s INP nad 300 ms zaznamenávají až o 31 % větší propady v rankingu

Podle aktuálních dat z Chrome UX Report (CrUX) splňuje práh pro dobré INP přibližně 86 % WordPress webů a 96 % Squarespace webů. Mobilní zařízení vykazují o 60–80 % horší INP než desktopy kvůli nižšímu výkonu procesorů. V USA je typická hodnota INP 100 ms na mobilu a 50 ms na desktopu.

Anatomie Interakce - Co Všechno INP Měří

Když kliknete na tlačítko, proběhne několik kroků. INP měří celý tento proces.

Input delay - čekání na zpracování

Input delay je čas od momentu, kdy kliknete, do momentu, kdy prohlížeč začne váš klik zpracovávat. Proč vzniká zpoždění? Prohlížeč může být zaneprázdněný jiným úkolem — zpracovává těžký JavaScript, načítá reklamy nebo běží analytické skripty.

Představte si to jako čekání ve frontě. Kliknete na tlačítko, ale prohlížeč říká: „Moment, ještě dokončuji něco jiného." Čím delší ta „jiná práce", tím delší input delay.

Typické hodnoty:

• Dobrý web: 0-16 ms
• Problémový web: 50-200 ms
• Katastrofa: 200+ ms

Hlavní viníci:

• Long Tasks (úlohy trvající více než 50 ms)
• Příliš mnoho JavaScriptu na hlavním vlákně
• Těžké třetí strany (chatboti, analytika, reklamy)
• Synchronní skripty blokující hlavní vlákno

Processing time - běh event handleru

Processing time je doba, po kterou běží váš kód — funkce reagující na kliknutí. Zákazník klikne na „Přidat do košíku" a JavaScript musí aktualizovat stav košíku, odeslat data na server a připravit vizuální změnu.

Typické problémy:

• Zbytečné přepočítávání celé stránky
• Synchronní volání na server
• Neoptimalizované frameworky bez memoizace

Presentation delay - vykreslení výsledku

Presentation delay je čas od dokončení zpracování do momentu, kdy uživatel vidí změnu. Prohlížeč musí přepočítat layout stránky (které prvky se změnily, kam se posunou), překreslit změněné pixely a zobrazit výsledek na obrazovce.

Co prodlužuje presentation delay:

• Velké změny v DOM (struktuře stránky)
• Těžké CSS animace běžící na hlavním vlákně
• Forced reflow (vynucený přepočet layoutu)
• Příliš mnoho prvků k překreslení najednou

Celkový vzorec: INP = vstupní zpoždění (input delay) + doba zpracování (processing time) + zpoždění vykreslení (presentation delay)

Pro dosažení INP pod 200 ms musíte optimalizovat všechny tři fáze. V praxi má většina webů největší problémy se vstupním zpožděním (příliš mnoho JavaScriptu) a dobou zpracování (neefektivní obsluhy událostí).

Debugging INP v Chrome DevTools

Než začnete optimalizovat, musíte najít problém. Chrome DevTools jsou nejlepší bezplatný nástroj pro debugging INP.

Performance panel - identifikace Long Tasks

1. Otevřete Chrome DevTools (F12)
2. Přejděte na záložku Performance
3. Klikněte na Record
4. Proveďte interakci na webu (klikněte na tlačítko)
5. Klikněte na Stop

Hledejte Long Tasks — úlohy trvající více než 50 ms označené červeným rohem. Tyto úlohy blokují hlavní vlákno a zpomalují reakci na kliknutí.

Web Vitals annotation - sledování interakcí

Chrome má funkci pro živé zobrazení INP:

1. DevTools → tři tečky → More tools → Rendering
2. Zaškrtněte Core Web Vitals
3. V horním rohu stránky uvidíte živá data

Každá interakce se zobrazí s hodnotou v milisekundách. Rychle najdete problémové interakce.

INP breakdown v Lighthouse

PageSpeed Insights zobrazuje detailní rozklad INP. V sekci Diagnostics hledejte „Minimize main-thread work" a „Reduce JavaScript execution time".

Důležité: Pro skutečný stav používejte Field Data (data od reálných uživatelů), ne laboratorní testy.

Optimalizace #1: Minimalizace JavaScriptu

JavaScript je hlavní příčinou špatného INP. Čím méně JavaScriptu prohlížeč zpracovává, tím rychleji reaguje.

Audit nepoužívaného kódu (Coverage tool)

Chrome DevTools obsahuje nástroj Coverage, který ukáže, kolik kódu se skutečně používá:

1. DevTools → More tools → Coverage
2. Klikněte na Reload (kroužek se šipkou)
3. Prohlížejte stránku, klikejte na tlačítka
4. Sledujte sloupec Unused Bytes

Červená část označuje kód, který se nikdy nespustil. Na běžném webu bývá nevyužito 50-70 % JavaScriptu. To je obrovské množství kódu, který prohlížeč stáhne, zparsuje, ale nikdy nespustí.

Co s tím:

• Odstraňte nepotřebné pluginy (WordPress: každý plugin = další JavaScript)
• Zkontrolujte, jestli potřebujete všechny knihovny
• Zvažte lightweight alternativy (místo jQuery můžete použít vanilla JavaScript)
• Použijte bundle analyzer pro vizualizaci velikosti souborů

Rozdělení kódu (code splitting) - načítání jen potřebného

Rozdělení kódu (code splitting) rozdělí velký JavaScript na menší části, které se načítají jen když jsou potřeba.

// S code splittingem (React)
const Cart = React.lazy(() => import('./cart.js'));
const Checkout = React.lazy(() => import('./checkout.js'));

Když zákazník klikne na košík, teprve pak se stáhne příslušný kód.

Odstranění mrtvého kódu (tree shaking) v moderních nástrojích

Odstranění mrtvého kódu (tree shaking) odstraní kód, který nepoužíváte. Představte si knihovnu s 200 funkcemi — vy používáte jen 5. Tree shaking automaticky zahodí zbylých 195.

Podmínky pro tree shaking:

• Používejte ES modules (import/export, ne require)
• Moderní build tool (Webpack 5, Vite, Rollup, esbuild)
• Správná konfigurace sideEffects v package.json

Praktický tip: Před přidáním nové knihovny zkontrolujte její velikost na Bundlephobia. Rozdíl mezi knihovnami pro stejnou funkcionalitu může být i 10x.

Optimalizace #2: Rozdělení Long Tasks

Long Task je úloha trvající více než 50 ms. Během ní prohlížeč nemůže reagovat na kliknutí.

Uvolnění hlavního vlákna - scheduler.yield()

Nové API umožňuje „pustit" hlavní vlákno uprostřed dlouhého výpočtu:

async function processLargeData(items) {
  for (const item of items) {
    processItem(item);
    if (items.indexOf(item) % 50 === 0) {
      await scheduler.yield();
    }
  }
}

Po scheduler.yield() prohlížeč zpracuje případné kliknutí uživatele a pak se vrátí k vašemu kódu.

RequestIdleCallback pro nekritický kód

requestIdleCallback() spustí kód jen tehdy, když prohlížeč nemá nic na práci:

requestIdleCallback(() => {
  sendAnalytics();
  prefetchNextPage();
}, { timeout: 2000 }); // Max čekání 2 sekundy

Kdy použít: analytika, pre-loading dalších stránek, inicializace nekritických funkcí, lazy loading komentářů.

Kdy nepoužít: cokoliv, co uživatel očekává okamžitě — přidání do košíku, odeslání formuláře.

Web Workers pro těžké výpočty

Web Workers běží na samostatném vlákně — úplně mimo hlavní vlákno prohlížeče. Cokoliv v Worker neblokuje INP.

// main.js
const worker = new Worker('calculator.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (e) => displayResult(e.data);

Kdy použít: komplexní výpočty (kalkulačky, filtry), zpracování velkých dat (JSON parsing), validace, kryptografie.

Omezení: Workers nemají přístup k DOM — nemohou přímo měnit stránku. Musí poslat výsledek hlavnímu vláknu.

Optimalizace #3: Event Handler Optimization

Event handlery jsou funkce reagující na akce uživatele. Špatně napsané handlery jsou častou příčinou pomalého INP.

Debounce a throttle - kdy co použít

Debounce čeká, až uživatel přestane psát/scrollovat, a pak spustí funkci jednou. Příklad: live vyhledávání — nechcete posílat dotaz po každém písmenu, ale až uživatel dopíše.

Throttle spouští funkci maximálně jednou za daný interval, bez ohledu na to, kolikrát uživatel akci provedl. Příklad: scroll tracking — stačí aktualizovat pozici 10x za sekundu, ne 60x.

Passive event listeners

U scroll a touch událostí řekněte prohlížeči, že nebude potřeba čekat:

document.addEventListener('scroll', handleScroll, { passive: true });

Event delegation místo mnoha handlerů

Místo přidání handleru na každé tlačítko přidejte jeden handler na rodiče:

// Špatně - 100 produktů = 100 handlerů
document.querySelectorAll('.add-to-cart').forEach(btn => {
  btn.addEventListener('click', handleAddToCart);
});

// Správně - 1 handler pro všechny
document.getElementById('product-list').addEventListener('click', (e) => {
  if (e.target.matches('.add-to-cart')) {
    addToCart(e.target.dataset.productId);
  }
});

Výhody: méně paměti, funguje i pro dynamicky přidané prvky, rychlejší inicializace stránky.

Optimalizace #4: Vizuální Feedback

Někdy nemůžete zrychlit samotnou akci. Ale můžete změnit vnímání rychlosti.

Okamžitá reakce UI (spinner, disabled state)

Uživatel klikne na tlačítko. I když operace trvá 500 ms, okamžitá vizuální změna vytvoří dojem rychlosti. Při kliknutí tlačítko okamžitě deaktivujte a změňte text na „Přidávám..." se spinnerem. Po dokončení zobrazte „Přidáno!" nebo chybovou hlášku.

Optimistické aktualizace (optimistic updates)

Místo čekání na odpověď serveru předpokládejte úspěch a aktualizujte UI okamžitě. Pokud server odpoví chybou, vraťte změnu zpět.

Kdy použít: like/unlike, hodnocení, přidání do oblíbených, změna nastavení. Kdy nepoužít: platby (musíte čekat na potvrzení), kritické operace (mazání dat).

Skeleton loading při akci

Pokud akce načítá nový obsah, zobrazte skeleton místo prázdné stránky nebo spinneru. Skeleton ukazuje tvar budoucího obsahu — uživatel ví, co očekávat, a má jistotu, že se „něco děje".

Framework-specifické Tipy

React: useMemo, useCallback, React.memo

React při každém renderu vytváří nové funkce a objekty. Použijte useMemo pro zapamatování výpočtů, useCallback pro funkce a React.memo pro přeskočení zbytečných renderů.

Vue: computed properties, v-once

Computed properties se přepočítají jen když se změní závislosti. v-once renderuje element pouze jednou — ideální pro statický obsah.

WordPress: odložení 3rd party skriptů

WP Rocket nebo Flying Scripts (zdarma) odloží načítání analytiky, chatbotů a Facebook Pixelu až po interakci uživatele. Přidejte do seznamu: gtag, fbq, hotjar, tawk, intercom.

Problém - kalendář nereagoval na kliknutí

Wellness centrum mělo online rezervační systém. Zákazníci volali: „Kalendář nefunguje."

Audit odhalil:

• INP: 1 240 ms (limit je 200 ms)
• LCP: 1,8 s (v pořádku)
• CLS: 0,05 (v pořádku)

Web se načítal rychle, ale nereagoval na kliknutí.

Analýza a řešení

V Chrome DevTools jsem identifikovala:

1. Dlouhý úkol (long task) při kliknutí na datum: 890 ms — kalendářová knihovna přepočítávala dostupnost pro celý měsíc synchronně
2. Těžké třetí strany: Live chat widget a Facebook Pixel přidávaly 300 ms
3. Neoptimalizované handlery: Každé políčko kalendáře mělo vlastní click handler

Řešení:

• Rozdělení dlouhého úkolu pomocí scheduler.yield()
• Delegování událostí (event delegation) místo 30 handlerů
• Odložení chat widgetu o 5 sekund
• Nahrazení kalendářové knihovny lehčí alternativou

Výsledky (+52% dokončené rezervace)

Po dvou týdnech optimalizací:

Klíčová zjištění: Kalendářová knihovna byla největší problém — nahradili jsme ji lehčí alternativou. Chat widget blokoval interakce — odložili jsme jeho načítání. Investice do optimalizace se vrátila za méně než měsíc.

Shrnutí: Co udělat hned

INP měří, jak rychle váš web reaguje na interakce. Cílová hodnota je pod 200 ms.

4 oblasti optimalizace:

1. Minimalizace JavaScriptu — audit nepoužívaného kódu, rozdělení kódu (code splitting), odstranění mrtvého kódu (tree shaking)
2. Rozdělení dlouhých úkolů (long tasks) — scheduler.yield(), requestIdleCallback, Web Workers
3. Optimalizace obsluhy událostí (event handlerů) — debounce, throttle, pasivní posluchače, delegování
4. Vizuální feedback — spinner, optimistické aktualizace, skeleton loading

3 věci, které můžete udělat dnes:

1. Změřte INP v PageSpeed Insights nebo Search Console
2. Otevřete DevTools Performance a najděte dlouhé úkoly (long tasks)
3. Zkontrolujte, jestli máte vizuální feedback při kliknutí na tlačítka

Potřebujete pomoct s optimalizací INP?

Nabízím technický SEO audit, kde zkontroluji Core Web Vitals vašeho webu včetně INP a dodám konkrétní plán optimalizace. Za roky v SEO jsem pomohla desítkám webů zrychlit odezvu a zvýšit konverze.

Objednejte si Technický SEO audit

Potřebujete pomoct s optimalizací Core Web Vitals?

Pomáhám firmám zrychlit weby a zlepšit uživatelskou zkušenost. Bez složitých smluv, jen výsledky.

Domluvte si konzultaci

Související články

• INP: Proč web nereaguje na kliknutí — základní vysvětlení INP metriky
• Core Web Vitals: Kompletní průvodce — všechny tři metriky LCP, INP, CLS
• PageSpeed Insights: Jak číst metriky — kompletní návod na měření rychlosti webu
• Technický SEO audit: 8 oblastí — kompletní kontrola webu

Často kladené otázky (FAQ)

Kdy Google přešel z FID na INP?

Google nahradil FID metrikou INP 12. března 2024. Od tohoto data je INP oficiální součástí Core Web Vitals a Google ji používá jako ranking faktor ve vyhledávání.

Proč mám dobré FID ale špatné INP?

FID měřil pouze první interakci na stránce. Pokud byl první klik rychlý, FID ukazoval dobrou hodnotu. INP měří všechny interakce během návštěvy — pokud je jakákoliv další interakce pomalá, INP to zachytí. Weby s velkým množstvím JavaScriptu nebo komplexními formuláři často mají dobré FID, ale špatné INP.

Jaký je rozdíl mezi INP a TBT?

TBT (Total Blocking Time) je laboratorní metrika — měří se při simulovaném testu v Lighthouse. INP je terénní metrika — měří se u skutečných uživatelů. Google pro ranking používá INP, protože odráží reálnou zkušenost. TBT je užitečný pro debugging, ale není to to samé jako INP.

Mohu zlepšit INP bez programátora?

Některé optimalizace zvládnete sami: odinstalování nepotřebných pluginů, odložení načítání chatbotů a analytických skriptů (pomocí pluginů jako WP Rocket nebo Flying Scripts). Ale hlubší optimalizace (code splitting, Web Workers, optimalizace event handlerů) vyžadují programátorské znalosti nebo pomoc vývojáře.

Jak často Google aktualizuje INP data v Search Console?

Google aktualizuje data v Search Console přibližně každých 28 dní. Používá klouzavý 28denní průměr z Chrome User Experience Report (CrUX). Po provedení optimalizací počítejte s tím, že změny uvidíte v Search Console za 4-6 týdnů.