Klepnete na „Přidat do košíku" a chvíli se neděje nic. Tak klepnete znovu, pro jistotu třikrát — a v košíku máte tři kusy. Web přitom není rozbitý, jen má pomalou odezvu. Přesně tuhle vlastnost měří INP (Interaction to Next Paint) — a protože se odezva s načítáním plete skoro všude, stojí za to vědět, co ta zkratka znamená, kde zjistíte svoje čísla a co s nimi zmůžete i bez programátora.
INP je jedna ze tří metrik Core Web Vitals. Přehled všech tří najdete v článku o Core Web Vitals; tady jdu do hloubky jen u odezvy.
Co přesně INP měří
INP sleduje všechna kliknutí, ťuknutí na mobilu a stisky kláves během celé návštěvy stránky. U každé takové interakce měří čas od akce návštěvníka do chvíle, kdy se na obrazovce něco viditelně změní. Posouvání stránky se nepočítá.
Výsledek není průměr. INP stránky je zhruba nejpomalejší interakce, kterou návštěvník zažil (jen u návštěv s mnoha interakcemi Google odpustí jednu nejhorší na každých 50). To je záměr: rozhoduje ta chvíle, kdy jste klikli a čekali, ne padesát bezproblémových kliknutí okolo.
Hranice podle Googlu (platné k červenci 2026, ověřeno na web.dev):
Aby web prošel, musí se pod 200 ms vejít 75 % návštěv. Nestačí tedy, že u vás v kanceláři na novém notebooku všechno lítá — hodnotí se i pomalejší telefony vašich zákazníků.
Ve starších návodech narazíte na metriku FID (First Input Delay). Ta měřila odezvu do března 2024, jenže jen u první interakce na stránce, a ještě jen její začátek. Web mohl mít výborný FID a přesto košík, který po kliknutí sekundu přemýšlí. Proto Google 12. března 2024 nasadil místo FID právě INP — a v září 2024 FID vyřadil i ze svých nástrojů. Pokud vám dnes někdo reportuje FID, čte hodně staré materiály.
Kde se těch 200 ms ztrácí
Prohlížeč vyřizuje skoro všechnu práci na stránce v jediné frontě, říká se jí hlavní vlákno. Každý skript, který na webu běží (měření, chat, banner s cookies, animace), si v té frontě bere čas. A když klepnete na tlačítko ve chvíli, kdy frontu okupuje něco jiného, vaše kliknutí čeká.
Každá interakce má tři fáze a INP měří jejich součet:
- Vstupní zpoždění — čekání ve frontě, než se na vaše kliknutí vůbec dostane řada.
- Zpracování — běh kódu, který na kliknutí reaguje (přepočet košíku, otevření menu).
- Vykreslení — čas, než prohlížeč změnu spočítá a ukáže na obrazovce.
Úlohám, které hlavní vlákno blokují déle než 50 ms, se říká dlouhé úlohy (long tasks). Právě ony jsou nejčastější příčinou špatného INP: nezáleží ani tak na tom, kolik toho web dělá celkem, ale jestli to dělá po malých kouscích, mezi kterými stihne reagovat na lidi.
Kolik zákazníků vám tenhle měsíc uteče ke konkurenci jen proto, že vás Google nenabídne? Pošlete mi adresu webu — do 48 hodin víte, co opravit, aby vás lidé našli. Audit dělám ručně a zdarma.
Jak zjistit svoje INP (a dvě pasti při měření)
Nejrychlejší cesta je PageSpeed Insights: zadáte adresu a v horní části výsledku vidíte data od skutečných uživatelů Chromu (databáze CrUX) za posledních 28 dní, včetně INP na mobilu a na počítači. Druhé místo je Search Console — v přehledu Core Web Vitals uvidíte, které skupiny stránek mají problém, a po opravě tam jde spustit ověření.
A teď ty pasti, kvůli kterým se u INP nejčastěji měří špatně:
Past první: bez reálného provozu žádná data. Hodnoty od skutečných uživatelů existují jen pro weby, kterými projde dost návštěvníků Chromu. Menší český web se v PageSpeed Insights klidně dozví, že data nejsou k dispozici — pak zbývá měřit si odezvu vlastním nástrojem na webu, nebo aspoň ručně proklikat důležité akce na průměrném telefonu, ne na vývojářském stroji.
Past druhá: laboratorní test INP neměří. To oranžové skóre ve spodní části PageSpeed Insights vzniká simulací načtení stránky, při které nikdo nikam neklikal. INP tam proto nenajdete; nejblíž mu je metrika TBT (Total Blocking Time), která ukazuje, jak dlouho bylo hlavní vlákno ucpané. Nízké TBT obvykle znamená i slušné INP, ale je to nápověda, ne totéž číslo. V praxi to znamená jediné: web může mít skóre přes 90, a přesto košík, na který si zákazníci stěžují. Věřte datům z provozu.
Kdo bývá viník: podezřelí, které potkávám nejčastěji
U klientských webů se pod špatným INP skoro vždycky skrývá některá z těchto věcí:
- Chatovací widget. Načítá se hned při otevření stránky a jeho skript patří k nejtěžším věcem na webu, přestože ho použije zlomek návštěvníků.
- Cookie lišta. Některá řešení blokují hlavní vlákno přesně v momentě, kdy návštěvník začíná klikat — tedy tam, kde to INP bolí nejvíc.
- Měřicí skripty. Google Tag Manager sám o sobě problém není; problém je kontejner, do kterého léta přibývají tagy a nikdo je nemaže.
- Těžké šablony a page buildery. Univerzální šablona umí všechno pro všechny, a tak veze JavaScript i pro funkce, které nepoužíváte. Každé kliknutí se pak prodírá kódem navíc.
- Slidery, pop-upy a animace z pluginů, které se na web kdysi přidaly „na zkoušku" a už tam zůstaly.
Všimněte si, že polovina seznamu nejsou věci, které by vyrobil váš vývojář. Jsou to věci, které se na web přidaly jedním vloženým kódem — a přesně proto s nimi můžete pohnout i vy.
Co zvládnete sami, bez vývojáře
Poctivě: hlubší opravy kódu bez vývojáře neuděláte. Ale identifikovat viníka a zbavit se balastu zvládnete sami, a často to stačí na viditelný posun:
- Udělejte si inventuru skriptů třetích stran. Chat, měření, mapy, recenzní widgety, sociální pluginy. U každého si odpovězte: používáme to ještě? Co nepoužíváte, vypněte — je to nejlevnější optimalizace na světě.
- Odložte chat. Většina chatovacích služeb i pluginů umí načíst widget až po první interakci návštěvníka nebo po pár sekundách, místo hned při otevření stránky. Na WordPressu tohle za vás vyřeší i plugin (například WP Rocket nebo bezplatné Flying Scripts).
- Pročistěte Tag Manager. Projděte tagy a smažte ty, které patří ke kampaním a nástrojům, co už neběží.
- Najděte těžké skripty v PageSpeed Insights. V diagnostice uvidíte, které skripty nejvíc zaměstnávají hlavní vlákno — seznam bývá překvapivě konkrétní, včetně domén třetích stran.
Co zadat vývojáři (místo „zrychli web")
Zadání „zrychli web" skončí obvykle optimalizací načítání, protože ta je vidět. Odezva potřebuje přesnější objednávku. Pošlete vývojáři něco v tomhle duchu:
- „INP na mobilu máme podle CrUX 450 ms, cíl je pod 200 ms."
- „V PageSpeed Insights vychází jako největší zátěž hlavního vlákna skript X — chci vědět, jestli ho můžeme odložit, zeštíhlit, nebo vyhodit."
- „Rozdělte dlouhé úlohy: žádná úloha na hlavním vlákně by neměla běžet přes 50 ms vcelku."
- „Každé tlačítko musí dát okamžitou vizuální odezvu (stav Odesílám…), i když samotná akce trvá déle."
Vývojář si problémové interakce dohledá v panelu Výkon v Chrome DevTools: nahraje záznam, klikne na stránce a hledá červeně označené dlouhé úlohy.
Nejste si jistí, jestli to děláte správně? Vstupní SEO audit u mě máte zdarma.
Poctivě: co vám dobré INP (ne)přinese
Core Web Vitals jsou slabý signál pro pozice ve vyhledávání. Neexistuje vzoreček „INP pod 200 ms = skok o pět míst" a nevěřte nikomu, kdo vám ho slibuje. Hlavní výnos je jinde: na webu, který reaguje hned, lidé nákup dokončí. Košík, formulář a rezervační kalendář jsou přesně ta místa, kde se pomalá odezva potkává s penězi — a kde se oprava zaplatí bez ohledu na Google.
Počítejte taky s tím, že výsledek neuvidíte hned. Data od reálných uživatelů se počítají za klouzavých 28 dní, takže po opravě se čísla v PageSpeed Insights i Search Console srovnávají zhruba měsíc.
Časté otázky
Web se načítá rychle, a přesto na něj lidé nadávají. Jak to?
Načítání a odezva jsou dvě různé věci. LCP měří, za jak dlouho se stránka zobrazí; INP měří, jak rychle reaguje, když už na ní člověk pracuje. Web s rychlým načtením a zaseklým košíkem je úplně běžná kombinace — a stížnosti zákazníků („tlačítka nefungují") bývají první signál, dřív než se na metriky vůbec podíváte.
PageSpeed Insights mi píše, že data o INP nejsou. Co teď?
Váš web má málo provozu na to, aby se dostal do databáze CrUX. INP si pak můžete měřit sami: buď nasazením měřicí knihovny (vývojář bude znát web-vitals od Googlu), nebo poctivým ručním testem — vezměte starší telefon a proklikejte objednávku, formuláře a menu. Kde ucítíte zaváhání, tam je co řešit.
Za jak dlouho se oprava projeví?
V chování webu okamžitě, v datech postupně. CrUX počítá klouzavé 28denní okno, takže plný efekt opravy uvidíte v PageSpeed Insights a Search Console asi po měsíci. V Search Console můžete po opravě spustit ověření a sledovat, jak problémových adres ubývá.
Odezva je vidět v datech dřív než v tržbách
Pomalé načítání návštěvníka odradí, než web vůbec uvidí. Pomalá odezva je zákeřnější: člověk už zboží vybral, už chtěl koupit — a web ho zastavil s prstem na tlačítku. V datech je to přitom vidět černé na bílém, stačí se podívat.
Když si nejste jistí, jak na tom váš web u skutečných návštěvníků je, udělám vám SEO audit zdarma. Technický stav webu včetně Core Web Vitals je jeho pevná součást: dozvíte se svoje reálné hodnoty, kteří konkrétní podezřelí z tohohle článku běží u vás a v jakém pořadí je řešit.
Zdroje k faktům v článku:
- INP: definice, prahy 200/500 ms, 75. percentil, tři fáze interakce (ověřeno 16. 7. 2026): web.dev/articles/inp
- Nahrazení FID metrikou INP 12. 3. 2024 a vyřazení FID k 9. 9. 2024 (ověřeno 16. 7. 2026): web.dev/blog/inp-cwv-launch
- Dlouhé úlohy nad 50 ms (ověřeno 16. 7. 2026): web.dev/articles/optimize-long-tasks
- TBT jako laboratorní nápověda k INP (ověřeno 16. 7. 2026): web.dev/articles/tbt
- Data reálných uživatelů v PageSpeed Insights za klouzavých 28 dní (ověřeno 16. 7. 2026): developers.google.com/speed/docs/insights/v5/about
