Core Web Vitals 2026: kompletny przewodnik optymalizacji INP dla WordPressa

#Zrozumienie Core Web Vitals w 2026

#Trzy metryki, które się liczą

#Dlaczego INP jest najtrudniejszy do naprawienia

LCP dotyczy głównie szybkości serwera i optymalizacji obrazów - dobrze zrozumianych problemów z jasnymi rozwiązaniami. CLS to kwestia rezerwacji miejsca dla dynamicznych treści - dyscyplina CSS i HTML. INP dotyczy efektywności wykonywania JavaScriptu - fundamentalnie trudniejszego problemu, ponieważ wymaga zrozumienia głównego wątku przeglądarki, planowania zadań i obsługi zdarzeń.

Strony WordPress są szczególnie podatne na słaby INP z powodu:

1. Nadmiaru wtyczek - każda wtyczka może dodawać JavaScript blokujący główny wątek
2. Page builderów - Elementor, Divi, WPBakery dodają ciężkie frameworki frontendowe
3. Skryptów zewnętrznych - analityka, reklamy, widgety czatu, embeddy społecznościowe - wszystkie rywalizują o czas głównego wątku
4. Zależności od jQuery - wiele motywów i wtyczek nadal opiera się na jQuery, dodając 85KB+ blokującego JavaScriptu
5. Brak code splitting - tradycyjne motywy ładują cały JavaScript na każdej stronie

#Jak działa INP

#Cykl życia interakcji

Gdy użytkownik klika przycisk, dotyka linku lub naciska klawisz, przeglądarka przetwarza to w trzech fazach:

1. Opóźnienie wejścia - czas między fizyczną interakcją a rozpoczęciem przetwarzania handlera zdarzenia (spowodowane zajęciem głównego wątku innymi zadaniami)
2. Czas przetwarzania - czas wykonania wszystkich handlerów zdarzeń dla danej interakcji
3. Opóźnienie prezentacji - czas renderowania aktualizacji wizualnej po zakończeniu handlerów

INP = Opóźnienie wejścia + Czas przetwarzania + Opóźnienie prezentacji

Metryka wychwytuje najgorszą interakcję (98. percentyl) podczas całej wizyty. Oznacza to, że pojedyncza wolna interakcja może zrujnować wynik INP, nawet jeśli wszystkie pozostałe interakcje są szybkie.

#Co liczy się jako interakcja

• Kliknięcia na przyciski, linki, przełączniki, menu
• Dotknięcia na urządzeniach mobilnych (zdarzenia touch)
• Naciśnięcia klawiszy w polach tekstowych, wyszukiwarkach
• NIE scrollowanie (scrollowanie jest mierzone osobno)
• NIE najechanie kursorem (sam hover nie wyzwala INP)

#Mierzenie INP na stronach WordPress

#Google Search Console (dane terenowe)

Najważniejsze źródło danych do oceny INP. Nawiguj do Core Web Vitals → Mobilne/Desktop. Search Console pokazuje rzeczywiste dane INP użytkowników zagregowane przez 28 dni. Strony są grupowane według wzorca URL i oznaczane jako Dobre, Wymaga poprawy lub Słabe.

Praktyczne kroki:

1. Otwórz Search Console i przejdź do raportu Core Web Vitals
2. Przełącz się na widok mobilny - tam INP jest zwykle gorszy
3. Kliknij grupy URL oznaczone jako „Słabe” lub „Wymaga poprawy”
4. Zanotuj konkretne szablony stron z problemami (np. strony produktów, archiwów)
5. Sprawdzaj raport regularnie - dane terenowe aktualizują się z opóźnieniem 28 dni

#PageSpeed Insights (lab + dane terenowe)

Wprowadź dowolny URL i otrzymaj oba rodzaje danych:

• Dane terenowe - rzeczywiste pomiary użytkowników z Chrome UX Report (CrUX), agregowane przez 28 dni
• Dane laboratoryjne - symulowane pomiary z Lighthouse, wykonane w kontrolowanym środowisku

Dla INP dane terenowe są ważniejsze, ponieważ testy laboratoryjne mogą nie odwzorować tych samych interakcji, które wykonują prawdziwi użytkownicy. PageSpeed Insights wskazuje też konkretne skrypty blokujące główny wątek w sekcji „Diagnostics”.

#Chrome DevTools (debugowanie)

Otwórz DevTools → panel Performance → kliknij Record → wchodź w interakcje że stroną (kliknij menu, otwórz modal, wpisz tekst w wyszukiwarkę) → Stop. Szukaj:

• Long Tasks (żółte/czerwone paski) - każde zadanie powyżej 50ms blokuje główny wątek i opóźnia reakcję na interakcje użytkownika
• Event handlers - jak długo trwa przetwarzanie każdego kliknięcia lub dotknięcia
• Layout thrashing - wymuszone synchroniczne przeliczenia layoutu podczas interakcji, widoczne jako fioletowe paski

W zakładce Performance insights DevTools automatycznie oznacza interakcje i przypisuje im wartość INP. Możesz też włączyć flagę „Core Web Vitals” w ustawieniach DevTools, aby widzieć wartość INP na żywo w nakładce na stronie.

#Biblioteka web-vitals (monitoring w czasie rzeczywistym)

Dla ciągłego monitorowania INP na produkcji możesz użyć biblioteki web-vitals od Google, która loguje wartości INP w czasie rzeczywistym i pozwala je wysyłać do dowolnego systemu analitycznego.

#Poprawki INP specyficzne dla WordPressa

#1. Odrocz niekrytyczny JavaScript

Pojedyncza najbardziej wpływowa poprawka. Większość wtyczek WordPress ładuje JavaScript w <head>, blokując główny wątek zanim strona zdąży się wyrenderować:

<!-- Przed: blokujący skrypt -->
<script src="plugin-slider.js"></script>

<!-- Po: odroczony skrypt -->
<script src="plugin-slider.js" defer></script>

Atrybut defer informuje przeglądarkę, że skrypt ma zostać pobrany równolegle, ale wykonany dopiero po sparsowaniu HTML. Atrybut async pobiera i wykonuje skrypt natychmiast po pobraniu - użyj go dla skryptów niezależnych od DOM (np. analityka).

Wtyczki, które najbardziej zyskują na odroczeniu:

• Analityka (GA4, GTM) - dodaj defer lub ładuj poprzez requestIdleCallback
• Widgety czatu (Intercom, Tawk.to) - ładuj po pierwszym scrollu użytkownika lub po upływie 5 sekund
• Embeddy społecznościowe (Facebook, Twitter/X) - ładuj tylko gdy element staje się widoczny (Intersection Observer)
• Slidery i karuzele - odrocz inicjalizację do momentu, gdy sekcja z sliderem stanie się widoczna w viewport

W WordPressie możesz dodać defer do konkretnych skryptów za pomocą filtra script_loader_tag w functions.php:

add_filter('script_loader_tag', function($tag, $handle) {
    $defer_handles = ['contact-form-7', 'slider-plugin', 'social-share'];
    if (in_array($handle, $defer_handles)) {
        return str_replace(' src', ' defer src', $tag);
    }
    return $tag;
}, 10, 2);

#2. Usuń nieużywany JavaScript wtyczek

Wykonaj audyt, które wtyczki faktycznie potrzebują frontendowego JavaScriptu. Zacznij od wylistowania wszystkich zakolejkowanych skryptów:

# Wylistuj wszystkie zakolejkowane skrypty na stronie
wp eval 'global $wp_scripts; foreach($wp_scripts->queue as $s) echo $s . "\n";'

To polecenie WP-CLI wyświetla identyfikatory wszystkich skryptów zarejestrowanych do załadowania. Porównaj tę listę z rzeczywistymi potrzebami danej strony.

Najczęstsi sprawcy:

• Contact Form 7 ładuje swój JavaScript i CSS na każdej stronie witryny, ale formularze kontaktowe istnieją zwykle tylko na jednej podstronie. Rozwiązanie: warunkówo ładuj skrypty CF7 tylko na stronach z formularzami
• WooCommerce - skrypt cart fragments wykonuje zapytania AJAX na każdej stronie, aby aktualizować licznik koszyka. Na stronach nie związanych że sklepem (blog, strony informacyjne) ten skrypt jest zbędny. Dezaktywuj go za pomocą wp_dequeue_script('wc-cart-fragments')
• Bloki Gutenberg - WordPress ładuje style CSS i JavaScript dla wszystkich zarejestrowanych bloków, nawet tych nieużywanych na danej stronie. Użyj wp_dequeue_style() aby usunąć style nieużywanych bloków

Warunkowe ładowanie skryptów CF7 tylko na stronach z formularzem:

add_action('wp_enqueue_scripts', function() {
    // Dezaktywuj CF7 na wszystkich stronach oprócz strony kontaktowej
    if (!is_page('kontakt')) {
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
    }
}, 20);

#3. Rozbij długie zadania

Każde zadanie JavaScript powyżej 50ms blokuje główny wątek. Podczas gdy to zadanie się wykonuje, przeglądarka nie może reagować na interakcje użytkownika - właśnie to generuje opóźnienie wejścia (input delay), pierwszy składnik INP.

Użyj scheduler.yield() (nowoczesne API dostępne w Chrome 115+) lub setTimeout jako fallback, aby rozbić długie zadania na mniejsze fragmenty:

// Rozbij długą pętlę na mniejsze fragmenty
async function processItems(items) {
  for (const item of items) {
    processItem(item);
    // Oddaj kontrolę przeglądarce między elementami
    if (navigator.scheduling?.isInputPending?.()) {
      await scheduler.yield();
    }
  }
}

Mechanizm isInputPending() sprawdza, czy użytkownik próbuje wejść w interakcję że stroną. Jeśli tak, scheduler.yield() oddaje kontrolę nad głównym wątkiem przeglądarce, aby mogła obsłużyć tę interakcję. Po jej zakończeniu przeglądarka wraca do przerwanego zadania.

Dla starszych przeglądarek użyj wzorca z setTimeout:

function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function processItemsFallback(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    // Co 5 elementów oddaj kontrolę przeglądarce
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

#4. Użyj pasywnych event listenerów

Listenery zdarzeń scroll i touch domyślnie blokują przeglądarkę przed płynnym scrollowaniem, ponieważ przeglądarka musi czekać na wynik handlera - handler mógłby wywołać preventDefault() i anulować scrollowanie. Jeśli wiesz, że handler nie będzie blokował scrollowania, dodaj { passive: true }:

// Przed: blokujący listener
element.addEventListener('touchstart', handler);

// Po: pasywny listener (informuje przeglądarkę, że scrollowanie nie zostanie zablokowane)
element.addEventListener('touchstart', handler, { passive: true });

// Pasywny listener na scroll
window.addEventListener('scroll', onScroll, { passive: true });

Wiele starszych motywów WordPress i wtyczek (szczególnie tych opartych na jQuery) rejestruje listenery scroll i touch bez flagi passive. Użyj Chrome DevTools → panel Issues, aby zidentyfikować niepasywne listenery na swojej stronie. Chrome automatycznie oznaczy je ostrzeżeniem.

Dodatkowo, zastosuj debouncing dla handlerów scroll i resize, które wykonują ciężkie operacje:

function debounce(func, wait) {
  let timeout;
  return function(...args) {
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(this, args), wait);
  };
}

window.addEventListener('scroll', debounce(function() {
  // Ciężka logika - np. lazy loading, sticky header
}, 100), { passive: true });

#5. Zoptymalizuj rozmiar DOM

Duże drzewa DOM (powyżej 1500 elementów) spowalniają każdą interakcję, ponieważ przeglądarka musi przeliczać style i layout dla większej liczby elementów. Page buildery są tutaj głównym winowajcą - pojedyncza sekcja Elementora może generować dziesiątki zagnieżdżonych wrapperów <div>.

Praktyczne kroki do redukcji DOM:

• Usuń zbędne wrappery <div> generowane przez page buildery
• Lazy-loaduj treść poniżej foldu - nie generuj DOM dla sekcji, których użytkownik jeszcze nie widzi
• Użyj wirtualnego scrollowania dla długich list (np. lista produktów, tabel z danymi)
• Uprość layouty page buildera - mniej kolumn, mniej zagnieżdżeń
• Sprawdź rozmiar DOM w Lighthouse (sekcja „Avoid an excessive DOM size”) - celem jest poniżej 1500 elementów, a głębokość drzewa poniżej 32 poziomów

#6. Wyeliminuj jQuery gdzie to możliwe

jQuery dodaje 85KB JavaScriptu i blokuje główny wątek podczas inicjalizacji. Wiele operacji, które historycznie wymagały jQuery, jest teraz natywnie wspieranych przez przeglądarki. Nowoczesne zamienniki:

// jQuery: document ready
$(function() { /* ... */ });

// Nowoczesny JavaScript: DOMContentLoaded
document.addEventListener('DOMContentLoaded', () => { /* ... */ });

// jQuery: selektor
$('.my-class');

// Nowoczesny JavaScript: querySelectorAll
document.querySelectorAll('.my-class');

// jQuery: dodawanie klasy
$('.element').addClass('active');

// Nowoczesny JavaScript: classList
document.querySelector('.element').classList.add('active');

// jQuery: AJAX
$.ajax({ url: '/api/data', success: callback });

// Nowoczesny JavaScript: fetch
fetch('/api/data').then(res => res.json()).then(callback);

// jQuery: animacja
$('.box').fadeIn();

// Nowoczesny CSS: transition + klasa
// .box { opacity: 0; transition: opacity 0.3s; }
// .box.visible { opacity: 1; }
document.querySelector('.box').classList.add('visible');

Jeśli nie możesz całkowicie usunąć jQuery (zbyt wiele wtyczek od niego zależy), przynajmniej dodaj do niego atrybut defer, aby nie blokował parsowania HTML. W WordPressie możesz to zrobić filtrem script_loader_tag dla handle jquery-core.

#Zaawansowana optymalizacja INP

#Web Workers dla ciężkich obliczeń

Przenieś operacje intensywne CPU poza główny wątek używając Web Workers. Worker wykonuje się w osobnym wątku - nie blokuje interakcji użytkownika, nie wpływa na INP. Jest idealny dla operacji takich jak parsowanie dużych zbiorów danych, przetwarzanie obrazów czy złożone obliczenia.

// main.js - przenieś przetwarzanie do workera
const worker = new Worker('heavy-task.js');
worker.postMessage(data);
worker.onmessage = (event) => {
  // Aktualizuj UI wynikami z workera
  updateUI(event.data);
};

// heavy-task.js - kod wykonywany w osobnym wątku
self.onmessage = (event) => {
  const result = expensiveCalculation(event.data);
  self.postMessage(result);
};

Ograniczenia Web Workers: nie mają dostępu do DOM, nie mogą bezpośrednio modyfikować UI. Komunikacja odbywa się wyłącznie przez postMessage. Dlatego Web Workers sprawdzają się najlepiej do zadań obliczeniowych, których wyniki są potem stosowane w głównym wątku.

#Content Visibility dla treści poza ekranem

Właściwość CSS content-visibility: auto informuje przeglądarkę, że może pominąć renderowanie treści znajdującej się poza widocznym obszarem ekranu. Przeglądarka nadal buduje DOM, ale pomija kosztowne etapy layoutu i malowania. Gdy użytkownik scrolluje do danej sekcji, przeglądarka renderuje ją na bieżąco.

/* Pomiń renderowanie sekcji poniżej foldu */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px; /* Oszacowana wysokość sekcji */
}

/* Zastosuj do powtarzalnych elementów - np. artykuły na blogu, produkty */
.product-card,
.blog-post-card {
  content-visibility: auto;
  contain-intrinsic-size: 0 350px;
}

Właściwość contain-intrinsic-size zapobiega skokom layoutu (CLS) - podaje przeglądarce przybliżone wymiary sekcji, zanim ta zostanie wyrenderowana. Bez tej właściwości przeglądarka traktuje niewyrenderowane sekcje jako elementy o zerowej wysokości, co powoduje przeskok treści podczas scrollowania.

#requestIdleCallback dla niepilnych zadań

Odrocz nieistotną pracę do okresów bezczynności przeglądarki. requestIdleCallback wywołuje podaną funkcję wtedy, gdy główny wątek nie ma nic do robienia - idealny moment na ładowanie analityki, prefetch zasobów czy raportowanie metryk.

// Załaduj analitykę podczas bezczynności przeglądarki
requestIdleCallback(() => {
  loadGoogleAnalytics();
}, { timeout: 3000 }); // Fallback: załaduj w ciągu 3 sekund nawet przy braku bezczynności

// Prefetch następnej strony w bezczynności
requestIdleCallback(() => {
  const nextPageLink = document.querySelector('.pagination .next');
  if (nextPageLink) {
    const link = document.createElement('link');
    link.rel = 'prefetch';
    link.href = nextPageLink.href;
    document.head.appendChild(link);
  }
});

Parametr timeout gwarantuje, że nawet na bardzo obciążonej stronie zadanie zostanie wykonane w rozsądnym czasie. Bez timeout zadanie mogłoby nigdy nie zostać wywołane na stronach z ciągłą aktywnością głównego wątku.

#Przewaga Headless dla INP

#Astro: INP zasadniczo zero

Astro domyślnie wysyła zero JavaScriptu. Na stronach bez interaktywnych wysp INP nie ma zastosowania, ponieważ nic nie blokuje głównego wątku. Nawet z wyspami, tylko konkretne interaktywne komponenty ładują JavaScript - reszta to statyczny HTML wysyłany z serwera.

Architektura wysp (Islands Architecture) w Astro pozwala selektywnie hydrować tylko te fragmenty strony, które wymagają interaktywności. Formularz kontaktowy, karuzela czy menu mobilne ładują swój JavaScript niezależnie od siebie - reszta strony pozostaje czysto statyczna i nie generuje żadnego obciążenia dla głównego wątku.

#Next.js: React Server Components

Next.js z React Server Components (RSC) renderuje UI na serwerze i wysyła do klienta tylko niezbędny JavaScript. Komponenty serwerowe nie dodają ani bajta JavaScriptu po stronie klienta. Automatyczny code splitting zapewnia, że każda strona ładuje wyłącznie ten JavaScript, którego faktycznie potrzebuje.

#Porównanie wydajności

Różnica jest szczególnie widoczna na urządzeniach mobilnych że słabszymi procesorami. Na flagowym smartfonie 300ms opóźnienia może być niezauważalne, ale na budżetowym telefonie z Androidem - ta sama ilość JavaScriptu może generować opóźnienie przekraczające 1000ms.

#Checklist optymalizacji INP

• Sprawdź Search Console Core Web Vitals dla aktualnych wyników INP
• Zidentyfikuj strony z najgorszym INP w PageSpeed Insights
• Odrocz cały niekrytyczny JavaScript (defer lub async)
• Warunkowo ładuj skrypty wtyczek tylko na stronach które ich potrzebują
• Usuń lub zastąp kod zależny od jQuery
• Dodaj { passive: true } do listenerów scroll/touch
• Rozbij długie zadania z scheduler.yield() lub setTimeout
• Lazy-loaduj treść poniżej foldu i embeddy zewnętrzne
• Zredukuj rozmiar DOM do poniżej 1500 elementów
• Użyj content-visibility: auto dla sekcji poniżej foldu
• Przenieś ciężkie obliczenia do Web Workers
• Ładuj analitykę przez requestIdleCallback
• Rozważ migrację do Astro lub Next.js dla najbardziej dramatycznej poprawy
• Monitoruj terenowy INP w Search Console przez 28 dni po zmianach

#Podsumowanie

INP to Core Web Vital, który oddziela strony czujące się szybko od ospałych. Podczas gdy LCP mierzy ładowanie a CLS stabilność, INP mierzy jak strona się czuje gdy z nią wchodzisz w interakcję. Dla stron WordPress droga do dobrego INP wymaga zdyscyplinowanego zarządzania JavaScriptem - lub fundamentalnej zmiany architektury na Headless.

Inwestycja w optymalizację INP zwraca się bezpośrednio w pozycjach wyszukiwania, zaangażowaniu użytkowników i współczynnikach konwersji. Każda milisekunda poprawy INP sprawia, że strona czuje się bardziej responsywna - a Google nagradza to lepszą widocznością w wynikach wyszukiwania. Witryny z INP poniżej 200ms notują średnio 15-25% niższy współczynnik odrzuceń i wyraźnie wyższy czas spędzony na stronie. To nie jest kosmetyczna poprawa - to mierzalny wpływ na przychody.

Potrzebujesz pomocy z optymalizacją Core Web Vitals? Sprawdź nasze usługi optymalizacji szybkości WordPress lub skontaktuj się z nami po bezpłatną ocenę wydajności.