Performance i Core Web Vitals 2026 — kompletny przewodnik

Dlaczego Core Web Vitals to nie kosmetyka, tylko biznes

Core Web Vitals to trzy mierzalne wskaźniki Google które od 2021 są oficjalnym sygnałem rankingowym, a od 2024 mają jeszcze większą wagę po wprowadzeniu INP zamiast FID. Strona z dobrymi Core Web Vitals (LCP poniżej 2.5s, INP poniżej 200ms, CLS poniżej 0.1) ranguje wyżej, ma niższy bounce rate, wyższy CTR z SERP-u i lepszą konwersję — wszystkie te efekty działają niezależnie i się sumują.

Konkretne liczby z mojej praktyki: strona Przystani u Miksera z PageSpeed mobile 45 punktów po przebudowie do custom WordPress osiągnęła 91 punktów — bez wdrażania CDN-a, cache plugin-u czy żadnej dodatkowej warstwy. To case study z konkretami. Skąd taka różnica? Page-buildery (Elementor, Divi, WPBakery) generują 4× więcej HTML-a niż custom theme, ładują własne biblioteki CSS i JS niezależnie od tego czy ich używasz, i dorzucają wrappery wokół każdej sekcji. Zoptymalizować strony na page-builderze do PageSpeed 90+ w ogóle nie da się bez przepisania jej na custom.

Dla biznesu Core Web Vitals to nie tylko ranking. Amazon w swoim research pokazał że każde 100 ms zwłoki LCP to ~1% spadek konwersji — dla sklepu robiącego 100 000 zł/mies oznacza to 5 000 zł/mies przychodu rocznie tylko na różnicy 500 ms ładowania. Plus każdy procent spadku bounce rate to dodatkowy ruch który Google zaczyna premuować pozycjami. Stąd performance to nie task techniczny, tylko biznesowy — i powinien być wyceniany w kategoriach ROI, nie godzinach pracy.

Kiedy ten przewodnik jest dla Ciebie

• Twoja strona ma PageSpeed mobile poniżej 70 — sekcja „Najczęstsze powody”
• Strona ładuje się powyżej 4 sekund — sekcja „LCP — Largest Contentful Paint”
• Czujesz że strona „skacze” przy ładowaniu — sekcja „CLS — Cumulative Layout Shift”
• Audytujesz cudzą stronę — sekcja „Jak czytać raport PageSpeed Insights”

LCP — Largest Contentful Paint

LCP to czas od rozpoczęcia ładowania do momentu gdy największy element above-the-fold (zwykle hero image albo nagłówek) jest w pełni widoczny. Cel: poniżej 2.5 sekundy na 75% wizyt. Powyżej 4 sekund — Google uznaje stronę za „wolną” i degraduje rangi.

Najczęstsze powody słabego LCP w stronach WordPress:

• Brak optymalizacji obrazów hero — typowy hero w PNG/JPG bez WebP fallback to 800 KB – 2 MB. Tylko sam ten obraz może dawać LCP 3-5 sekund. Rozwiązanie: konwersja do WebP (60-70% mniejszy rozmiar), `loading=”eager”` dla above-the-fold, plus `fetchpriority=”high”`
• Wolny serwer (TTFB powyżej 600 ms) — shared hosting albo overloaded VPS. Każdy moment serwerowego TTFB jest dodawany do LCP. Naprawa: managed WP hosting albo dedykowany VPS z LiteSpeed/Nginx + Redis dla object cache
• Render-blocking CSS i JS — pliki CSS/JS w head który blokują pierwsze wyświetlenie. Naprawa: krytyczny CSS inline w head, reszta CSS lazy-loaded, JS z `defer` albo `async`
• Cudze fonty bez preload — Google Fonts wczytane „normalnie” dodaje 300-800 ms do LCP. Naprawa: „ na fonty above-the-fold albo (ideal) self-hosted fonty z `font-display: swap`

Dla typowej strony usługowej z hero image LCP poniżej 1.8 s jest osiągalne na sensownym hostingu. Sklepy WooCommerce z dużym hero i sliderami: 2.0-2.5 s realistyczne. Powyżej tego — problem nie w „WordPressie” ale w konkretnej kombinacji theme + plugins + hosting.

INP — Interaction to Next Paint

INP zastąpił FID w marcu 2024 jako oficjalna metryka responsywności w Core Web Vitals. Mierzy jak szybko strona reaguje na interakcje użytkownika (kliknięcia, taps, key presses) — od momentu kliknięcia do widocznej reakcji. Cel: poniżej 200 ms. Powyżej 500 ms — strona „laguje” według Google.

Główne źródła słabego INP:

• Ciężkie JavaScript main thread — szczególnie na mobilnych CPU. Każdy wywołany skrypt blokuje UI thread; jeśli Twoja strona ma 5+ MB JS, INP będzie wysokie
• Third-party scripts — Google Analytics, Facebook Pixel, chat widgety, A/B testing platforms. Każdy z nich może dorzucić 100-300 ms do INP. Naprawa: ładowanie z `async`, opóźnienie do user interaction, użycie GTM jako single entry point
• WordPress admin bar w trybie edytora — jeśli klient widzi wolny INP w panelu admina, to nie jest typowe „wolny WordPress”, tylko jQuery i admin scripts. Front jest oddzielny
• Heavy event listeners — np. scroll listener wywołujący kosztowną funkcję bez throttling/debouncing

Dla custom WordPress bez page-buildera typowy INP to 50-150 ms — bez specjalnych optymalizacji. Strony na Elementorze często mają 300-600 ms INP na mobile, co już bezpośrednio uderza w ranking.

CLS — Cumulative Layout Shift

CLS mierzy ile elementów na stronie „przeskakuje” w trakcie ładowania. Cel: poniżej 0.1. Powyżej 0.25 — Google uznaje to za poważny problem UX.

Klasyczne przyczyny CLS:

• Obrazy bez zadeklarowanych wymiarów — `` zapobiega skokowi gdy obraz się załaduje. Brak tych atrybutów → przeglądarka rezerwuje 0px miejsca, a po załadowaniu obrazu reszta strony zjeżdża w dół
• Web fonty bez fallback z dopasowaniem rozmiaru — fonta gruba ładuje się 500 ms, w międzyczasie tekst pokazuje się fontem fallback (cieńszym), potem skacze gdy gruba się załaduje. Naprawa: `font-size-adjust` plus `size-adjust` w `@font-face`
• Reklamy / iframes bez zarezerwowanej przestrzeni — Google AdSense, embedy YouTube, banner cookie, all this loads asynchronously and pushes content. Naprawa: kontener z `min-height` żeby zarezerwować przestrzeń
• Wstrzykiwany content przez JavaScript — np. „cookie banner pojawia się 2 sek po załadowaniu” pcha cały content w dół. Naprawa: render banner od razu z initial HTML, nie później

CLS jest jedyną z trzech CWV gdzie custom WordPress nie ma przewagi nad page-builderami z natury — zarówno custom jak i Elementor mogą mieć dobry albo zły CLS, zależy od konkretnej implementacji. Cel 0.0 (idealne) jest osiągalny dla niemal każdej strony jeśli zwraca się uwagę na te punkty od początku projektu.

TTFB — czas pierwszej odpowiedzi serwera

TTFB to nie jest oficjalna Core Web Vital, ale wpływa bezpośrednio na LCP i jest pierwszym wąskim gardłem które trzeba zoptymalizować. Cel: poniżej 600 ms. Powyżej 1.5 s — winowajcą jest hosting albo źle skonfigurowany WP.

Typowe TTFB wartości w polskim ekosystemie hostingowym:

• Shared hosting (zenbox starter, hostinger basic): 800-2500 ms — niesensowne dla profesjonalnej strony
• Managed WordPress hosting (zenbox WP, Cloudways): 200-500 ms — sensowne dla większości projektów
• Własny VPS z LiteSpeed + Redis (Hetzner, DigitalOcean): 80-200 ms — najlepsze dla e-commerce i premium projektów
• Cloudflare jako frontend (z cache na edge): 30-150 ms dla stron statycznych — top class

Najszybszy fix dla wolnego TTFB to często nie optymalizacja kodu, ale zmiana hostingu. Migracja z shared na VPS to typowo 1-2 dni roboty, a zysk LCP rzędu 1-2 sekund. To znacznie więcej niż jakąkolwiek pojedynczą optymalizację frontendu daje.

Najczęstsze powody słabego performance w WordPressie

Lista, którą zbieram z audytów strony klientów. W kolejności od najczęściej spotykanego do najrzadszego:

1. Page-builder (Elementor / Divi / WPBakery / Avada / Flatsome) — odpowiedzialny za ~60% słabego performance w stronach WordPress. Generuje code bloat, dorzuca własne biblioteki, wymusza wrappery. Naprawa: przepisanie na custom theme. Pełen pillar strony WordPress argumentuje to szczegółowo.
2. Tani hosting — drugie najczęstsze. Strona za 30 000 zł na hostingu za 200 zł/rok rozczaruje wynikiem niezależnie od jakości kodu. Naprawa: managed WP hosting (~150-300 zł/mies) albo VPS
3. 10+ pluginów których 80% nie używasz — każdy ładuje swój CSS i JS. Naprawa: audit aktywnych pluginów, wykasowanie nieużywanych
4. Kupiony szablon Themeforest — Avada, Flatsome, Shoptimizer mają wbudowane 30+ pluginów które ładują się zawsze, nawet jeśli nie używasz
5. Brak optymalizacji obrazów — JPG/PNG zamiast WebP, brak lazy loading, zbyt duże rozmiary (zdjęcia 4000×3000 px na stronę gdzie i tak są wyświetlone w 800×600)
6. Render-blocking resources — CSS i JS w head który blokuje pierwsze wyświetlenie
7. Database bloat — opcje WooCommerce, transients, revisions wpisów. Naprawa: cleanup co 6-12 miesięcy przez plugin albo bezpośrednio w bazie

Powiązane szczegółowe poradniki:

• Dlaczego strona WordPress jest wolna mimo CDN
• Dlaczego WordPress jest wolny — pełna lista przyczyn
• Dlaczego WordPress zjada pamięć mimo niewielkiego ruchu
• Dlaczego WordPress pokazuje „Error establishing database connection”

Cache i CDN — kiedy mają sens

Cache i CDN są klasycznymi narzędziami optymalizacji, ale nie są magicznym rozwiązaniem dla wszystkich problemów. Złe założenie: „dorzucimy CDN-a i będzie szybko”. Prawdziwe pytanie: czy Twój problem jest na poziomie network latency (CDN pomoże), serwerowym (cache pomoże), czy aplikacyjnym (page-builder, code bloat — wtedy ani cache ani CDN nie pomoże).

Cache plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache): sensowne dla każdej strony WordPress z ruchem powyżej 100 wizyt/dzień. Zmniejsza TTFB dla cached pages do 30-50 ms. WP Rocket płatny (49 USD/rok), LiteSpeed Cache darmowy (jeśli serwer ma LiteSpeed), W3 Total Cache darmowy ale skomplikowana konfiguracja. Polecenie: LiteSpeed jeśli Twój hosting używa LSWS (większość polskich managed WP), WP Rocket dla wszystkich innych.

CDN (Cloudflare, BunnyCDN, KeyCDN): sensowne gdy masz ruch międzynarodowy (większość Twoich klientów jest poza Polską) albo ciężkie media (sklep z dużymi zdjęciami produktów). Cloudflare ma darmowy plan, BunnyCDN $1/mies + transfer. Dla typowej polskiej firmy obsługującej tylko polskich klientów CDN poprawia 50-100 ms LCP — sensowne dla Core Web Vitals, niekoniecznie krytyczne dla biznesu.

Object cache (Redis, Memcached): krytyczne dla sklepów WooCommerce z 100+ produktami i dla stron z aktywnym contentem. Redis w połączeniu z managed WordPress hostingiem to typowo 20-40% szybsze response time dla dynamicznych zapytań.

Jak czytać raport PageSpeed Insights

PageSpeed Insights (pagespeed.web.dev) to oficjalne narzędzie Google do mierzenia Core Web Vitals. Wprowadza dwie warstwy danych: Field Data (z realnych użytkowników, ostatnie 28 dni) i Lab Data (synthetic test w warunkach laboratoryjnych). Ta różnica jest kluczowa.

Field Data to to czego doświadczają realni użytkownicy. Jeśli Twoja strona ma „dobre” CWV w Field Data — Google używa tych liczb do rankingu. Jeśli „złe” — degraduje. Field Data dostępne tylko gdy strona ma wystarczająco ruchu (Google pokazuje „Insufficient data” dla nowych albo małoruchliwych stron).

Lab Data to symulacja na konkretnym device (Mobile Mid-range Pixel albo Desktop), z konkretnym networkiem (4G slow). Dobre dla debug-u i porównań przed/po. Złe dla podejmowania decyzji rankingowych — Google nie ranguje na Lab Data, tylko na Field Data.

Praktyczna interpretacja:

• Lab Score 90+ ale Field Data poniżej 75% „dobre” — masz różne warunki w realnym użytkowaniu niż w laboratorium. Najczęściej: third-party scripts (chat widget, analytics) które nie są w Lab Data ale obciążają realnych userów
• Field Data dobre ale Lab Score słaby — rzadkie, ale zdarza się gdy masz aggressive caching. Field Data widzi cached pages, Lab cold starts
• Oba słabe — fundamentalny problem (page-builder, hosting, code bloat). Wymaga przebudowy, nie patch-y

Metryki w raporcie pochodzą z Chrome User Experience Report (CrUX), który Google buduje z realnych Chrome users opt-in do telemetrii. Lighthouse to silnik za PageSpeed Insights — możesz go uruchomić lokalnie w Chrome DevTools (zakładka Lighthouse) dla iteracyjnego debugowania.

Cele PageSpeed dla różnych typów biznesu

• Strona usługowa B2B (księgowa, prawnik, freelancer): mobile 85+, desktop 95+. Realnie osiągalne dla custom WordPress bez ekstremalnej optymalizacji.
• E-commerce (WooCommerce 100-500 produktów): mobile 75+, desktop 90+. Wymaga aktywnej optymalizacji obrazów, cache, czasem CDN.
• Strona kliniki / gabinetu: mobile 80+, desktop 95+. Branża medyczna ma wysokie standardy UX, klienci kierują się intuicją.
• Strona portfolio / brand (z dużymi mediami, animacjami): mobile 70+, desktop 90+. Animacje GSAP-owe i scroll storytelling kosztują 10-20 punktów performance — świadomy tradeoff.
• Strona-aplikacja / SaaS: mobile 60+, desktop 85+. Heavy JavaScript app charakter, niemożliwe dojść do 95+ przy zachowaniu pełnej funkcjonalności.

Powyżej tych liczb — projekt jest w dobrym stanie. Poniżej — warto zainwestować w optymalizację.

Najczęstsze pytania o performance i Core Web Vitals

Co dalej

Jeśli chcesz najpierw zdiagnozować obecny stan strony — uruchom PageSpeed Insights dla swojego URL i sprawdź Field Data oraz Lab Data. Jeśli oba są poniżej 75% „dobre” — masz fundamentalny problem do naprawienia, najczęściej page-builder + hosting + plugin bloat. Najszybsze diagnozy: zacznij od „Dlaczego WordPress jest wolny” jako check-list.

Jeśli planujesz pełną przebudowę albo nową stronę z naciskiem na performance — wypełnij kalkulator cen strony WP, zaznacz „SEO foundations” w sekcji wymagań. Pełne SEO foundations w mojej standardowej dostawie obejmuje optymalizację Core Web Vitals — strony którą wdrażam startują z PageSpeed 85-95 mobile od pierwszego dnia.

Konkretne realizacje pokazujące przebudowy z perspektywy performance:

• Przystań u Miksera — z PageSpeed 45 (mobile) do 91, bez dodatkowych warstw cache
• Roseti Med&Beauty — przebudowa kliniki z Elementora na custom WordPress

Powiązane przewodniki: Strony WordPress 2026 — kompletny przewodnik, WooCommerce 2026, Wdrożenie GA4.

Pobierz Brief — szablon do wypełnienia przed wyceną

Jeśli planujesz przebudowę albo nową stronę z naciskiem na performance, najszybsza droga do konkretnej wyceny to wypełniony brief. 10-stronicowy PDF z 30+ pytaniami i checklistami — wpisujesz email, dostajesz link na skrzynkę.

Wszystkie powyższe wdrażam jednoosobowo, bez agencyjnego balastu — 15+ lat w WordPressie i performance marketingu. Więcej o tym jak pracuję: O mnie. Jak wygląda współpraca krok po kroku: Proces. Pakiety i widełki cenowe: Cennik.

Sprawdź swój sklep — bezpłatny audyt 30 punktów

Większość sklepów WooCommerce ma 5-10 problemów technicznych, o których właściciel nie wie. Każdy z nich kosztuje ułamek konwersji albo procent ruchu. Pobierz 30-punktową checklistę audytu — przejdź ją sam w 30-45 minut, dostań mapę co naprawić w pierwszej kolejności.