Core Web Vitals 2025 - INP Zastapil FID. Kompletny Przewodnik

W marcu 2024 Google oficjalnie zastapil FID (First Input Delay) nowa metryka INP (Interaction to Next Paint). To nie kosmetyczna zmiana - INP mierzy responsywnosc strony w sposob bardziej kompleksowy i wymagajacy. Jesli Twoja strona "zdawala" FID, wcale nie znaczy, ze zda INP.

Czym jest INP i dlaczego zastapil FID

INP (Interaction to Next Paint) to metryka mierzaca czas od interakcji uzytkownika do momentu, gdy przegladarka wyswietli wizualna odpowiedz. W przeciwienstwie do FID, ktory mierzyl tylko pierwsza interakcje, INP bierze pod uwage wszystkie interakcje podczas calej sesji uzytkownika.

Roznice miedzy FID a INP

Aspekt	FID (stary)	INP (nowy)
Co mierzy	Opoznienie pierwszej interakcji	Opoznienie wszystkich interakcji
Zakres pomiaru	Tylko input delay	Input delay + processing + presentation
Interakcje	Pierwsza interakcja	Cala sesja (wybiera najgorsza)
Prog "Good"	do 100ms	do 200ms
Wymagania	Niskie	Znacznie wyzsze

Google zdecydowal sie na ta zmiane, poniewaz FID mial powazne ograniczenia:

• Mierzyl tylko delay - ignorowal czas przetwarzania i renderowania
• Tylko pierwsza interakcja - strona mogla byc wolna przez reszte sesji
• Zbyt latwy do zdania - 93% stron zdawalo FID, co czyniło go bezuzytecznym jako wyroznik
• Nie odwzorowywal UX - uzytkownik mogl odczuwac wolna strone mimo "dobrego" FID

Jak INP jest obliczany

INP sklada sie z trzech faz, ktore razem tworza calkowity czas odpowiedzi:

1. Input Delay - czas od klikniecia do rozpoczecia obslugi zdarzenia (event handler)
2. Processing Time - czas wykonania kodu JavaScript obslugujacego zdarzenie
3. Presentation Delay - czas od zakonczenia przetwarzania do wyrenderowania nowej klatki

Wzor: INP = Input Delay + Processing Time + Presentation Delay

Google zbiera dane o wszystkich interakcjach podczas sesji i wybiera wartosc z 75. percentyla (lub najgorsza wartosc, jesli interakcji bylo malo). To oznacza, ze nawet jedna wolna interakcja moze zniszczyc Twoj wynik INP.

Progi INP - kiedy strona jest "dobra"

Wynik INP	Ocena	Interpretacja
0-200ms	Good (Dobry)	Strona reaguje natychmiast, uzytkownik nie zauwa zaopoznienia
200-500ms	Needs Improvement (Do poprawy)	Zauwa zalne opoznienie, moze wplywac na konwersje
500ms+	Poor (Slaby)	Wyrazne "zamrozenie" strony, frustracja uzytkownika

200ms to prog percepcji czlowieka dla "natychmiastowej" odpowiedzi. Powyzej tej wartosci mozg rejestruje opoznienie jako odrebne zdarzenie - stąd wybor tego progu przez Google.

Jak mierzyc INP

INP mozna mierzyc na dwa sposoby: dane laboratoryjne (syntetyczne testy) i dane polowe (real user monitoring).

Dane polowe (Field Data) - najwazniejsze

To dane zbierane od prawdziwych uzytkownikow. Google uzywa ich do oceny Core Web Vitals w rankingu:

• Google Search Console - raport Core Web Vitals pokazuje INP dla Twojej strony
• PageSpeed Insights - sekcja "Field Data" (jesli strona ma wystarczajacy ruch)
• Chrome UX Report (CrUX) - publiczna baza danych z metrykami dla popularnych stron
• web-vitals.js - biblioteka JavaScript do wlasnego monitoringu

Dane laboratoryjne (Lab Data)

Symulacje przydatne do debugowania, ale nie wplywaja na ranking:

• Chrome DevTools - zakladka Performance z nagrywaniem interakcji
• Lighthouse - pokazuje TBT (Total Blocking Time) jako proxy dla INP
• WebPageTest - zaawansowane testy z roznych lokalizacji

Implementacja pomiaru INP

<script type="module">
import {onINP} from 'https://unpkg.com/web-vitals@3/dist/web-vitals.js';

onINP((metric) => {
  console.log('INP:', metric.value);
  // Wyslij do analytics
  gtag('event', 'web_vitals', {
    event_category: 'Web Vitals',
    event_label: metric.name,
    value: Math.round(metric.value),
    non_interaction: true,
  });
});
</script>

Najczestsze problemy z INP

Po analizie setek stron, oto najczestsze przyczyny slabego INP:

1. Dlugie zadania JavaScript (Long Tasks)

Kazde zadanie JS blokujace main thread dluzej niz 50ms to Long Task. Podczas jego wykonywania przegladarka nie moze odpowiedziec na interakcje uzytkownika.

Zrodlo problemu	Typowy wplyw na INP	Rozwiazanie
Ciezkie frameworki JS	+100-300ms	Code splitting, lazy loading
Skrypty zewnetrzne (ads, analytics)	+50-200ms	Asynchroniczne ladowanie, defer
Hydration (React, Vue, Next.js)	+100-500ms	Progressive hydration, Islands
Duze manipulacje DOM	+50-150ms	Virtual scrolling, batching

2. Za duzo event listenerow

Kazdy event listener dodaje naklad pracy. Szczegolnie problematyczne sa listenery na scroll, mousemove i resize bez throttlingu.

3. Layout Thrashing

Wymuszanie ponownego obliczenia layoutu przez przegladarke w trakcie obslugi zdarzenia. Dzieje sie gdy kod na przemian czyta i zapisuje do DOM:

// ZLE - wymusza 1000 przeliczen layoutu
for (let i = 0; i < 1000; i++) {
  const height = element.offsetHeight; // czytanie
  element.style.height = height + 1 + 'px'; // zapis
}

// DOBRZE - jedno przeliczenie
const height = element.offsetHeight;
element.style.height = height + 1000 + 'px';

4. Ciezkie CSS

Skomplikowane selektory CSS i duze arkusze stylow spowalniaja rendering. Szczegolnie problematyczne:

• Selektory uniwersalne: * { }
• Gleboko zagniezdzene selektory: .a .b .c .d .e { }
• Filtry CSS: filter: blur(), backdrop-filter
• Duze animacje bez will-change

5. Third-party scripts

Skrypty zewnetrzne to czesto glowny winowajca. Typowi "zabojcy" INP:

• Chat widgets (Intercom, Drift, Zendesk)
• Skrypty reklamowe (Google Ads, Facebook Pixel)
• Heatmapy (Hotjar, Crazy Egg)
• A/B testing (Optimizely, VWO)

Praktyczne metody optymalizacji INP

1. Identyfikacja problemow

Zanim zaczniesz optymalizowac, znajdz konkretne interakcje powodujace problemy:

// Znajdz najwolniejsze interakcje
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 200) {
      console.log('Slow interaction:', {
        type: entry.name,
        duration: entry.duration,
        target: entry.target
      });
    }
  }
}).observe({ type: 'event', buffered: true, durationThreshold: 16 });

2. Rozbij dlugie zadania

Podziel dlugie operacje na mniejsze chunki uzywajac scheduler.yield() lub setTimeout:

// Zamiast jednego dlugiego zadania
async function processItems(items) {
  for (const item of items) {
    processItem(item);
    // Daj przegladarce szanse na odpowiedz
    await scheduler.yield();
  }
}

3. Uzyj requestIdleCallback

Przenies niekrytyczne operacje do momentow, gdy przegladarka jest bezczynna:

// Odloz analytics i tracking
requestIdleCallback(() => {
  trackPageView();
  initializeAnalytics();
}, { timeout: 2000 });

4. Optymalizuj event handlery

• Debounce/throttle - dla scroll, resize, input
• Passive listeners - { passive: true } dla scroll i touch
• Event delegation - jeden listener na rodzicu zamiast wielu na dzieciach

// Passive listener - nie blokuje scrollowania
window.addEventListener('scroll', handleScroll, { passive: true });

// Throttle dla scroll
let ticking = false;
window.addEventListener('scroll', () => {
  if (!ticking) {
    requestAnimationFrame(() => {
      handleScroll();
      ticking = false;
    });
    ticking = true;
  }
}, { passive: true });

5. Lazy loading i code splitting

Nie laduj kodu, ktory nie jest potrzebny przy pierwszej interakcji:

• Dynamic imports - import('./module.js') gdy potrzebne
• Intersection Observer - laduj komponenty gdy wchodza w viewport
• Route-based splitting - osobne bundles dla roznych stron

6. Optymalizacja third-party scripts

Strategia	Implementacja	Wplyw na INP
Opoznione ladowanie	defer lub async	-50-100ms
Facade pattern	Placeholder do klikniecia	-100-300ms
Web Worker	Przenies do osobnego watku	-50-200ms
Usun niepotrzebne	Audyt wartosci skryptow	-100-500ms

7. Facade pattern dla ciezkich widgetow

Zamiast ladowac pelny widget chatu od razu, pokaz statyczny placeholder:

<!-- Facade - statyczny przycisk -->
<button id="chat-facade" onclick="loadChat()">
  Potrzebujesz pomocy? Kliknij, aby otworzyc czat
</button>

<script>
function loadChat() {
  // Laduj prawdziwy widget dopiero po kliknieciu
  const script = document.createElement('script');
  script.src = 'https://widget.chat.com/bundle.js';
  document.body.appendChild(script);
}
</script>

INP w kontekscie Shopify

Sklepy Shopify maja specyficzne wyzwania z INP:

Typowe problemy

• Ciezkie theme'y - popularne motywy czesto maja nadmiar JS
• Aplikacje Shopify - kazda aplikacja dodaje swoj JS
• Dynamic checkout - przyciski "Kup teraz" laduja dodatkowy kod
• Product recommendations - czesto blokuja main thread

Rekomendacje dla Shopify

1. Audytuj aplikacje - usun te, ktore nie sa niezbedne
2. Uzyj natywnych funkcji - Shopify ma wbudowane rekomendacje produktow
3. Lazy load obrazkow - uzyj loading="lazy"
4. Minimalizuj customowy JS - kazda linia kodu to potencjalny problem
5. Testuj na realnych urzadzeniach - emulacja w DevTools nie oddaje prawdy

Monitoring i ciagle doskonalenie

Optymalizacja INP to nie jednorazowe zadanie. Ustaw monitoring:

• Alerty w GSC - powiadomienia gdy Core Web Vitals spadna
• Real User Monitoring (RUM) - np. przez web-vitals.js do GA4
• Syntetyczne testy - automatyczne testy Lighthouse w CI/CD
• Budzet wydajnosci - maksymalne wartosci dla JS, CSS, obrazkow

INP to metryka, ktora naprawde odwzorowuje doswiadczenie uzytkownika. Strony z dobrym INP maja wyzsze konwersje - bo uzytkownik czuje, ze strona "reaguje" na jego dzialania.