Core Web Vitals przestały być debatą “czy to ważne” w okolicach 2022 roku. W 2026 są jedną z trzech rzeczy, które Google sprawdza zanim w ogóle rozważy Twoją stronę do wyświetlenia w TOP 10. Co więcej, AI Overviews oraz odpowiedzi ChatGPT preferują serwisy szybkie i czyste strukturalnie – dlatego wolny WordPress nie zacytuje się w AI search. Tymczasem w projektach klienckich regularnie widujemy strony, których LCP siedzi na poziomie 4-6 sekund. Każda taka strona traci pozycje, klientów oraz pieniądze na reklamy, które nie konwertują. Walmart oraz Amazon publicznie raportowali, że każde 100 ms wolniejszego ładowania to około 1% spadku konwersji. Ten sam wzór widujemy regularnie w polskim e-commerce.
Ten artykuł rozkłada trzy metryki Core Web Vitals (LCP, INP, CLS), pokazuje konkretne źródła problemów, koszt oraz czas naprawy w środowisku WordPress oraz w sklepach e-commerce. Bez tutoriala “co to jest LCP” – od razu na konkrety, których szuka zarząd firmy.
Disclaimer rynkowy. Wszystkie widełki kosztu naprawy oraz czasu wdrożenia podajemy jako orientacyjne stawki rynkowe (rynek polski, maj 2026), na podstawie obserwacji Devstocka w projektach klienckich oraz publicznych cenników agencji optymalizacyjnych. Konkretna wycena zależy od skali strony, środowiska oraz stanu wyjściowego. To nie jest cennik Devstocka – oferta wymaga briefu i analizy.
Trzy metryki Core Web Vitals – co naprawdę mierzy Google
Core Web Vitals to zestaw trzech metryk, które Google używa jako sygnał rankingowy od czerwca 2021 roku. W 2024 roku jedna z metryk (FID) została zastąpiona przez INP, a w 2026 obowiązują:
| Metryka | Co mierzy | Cel “Good” | Cel “Needs improvement” | Cel “Poor” |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Czas wyświetlenia największego elementu na ekranie | ≤ 2,5 s | 2,5 – 4,0 s | > 4,0 s |
| INP (Interaction to Next Paint) | Czas reakcji strony na interakcję użytkownika | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Sumaryczne przeskakiwanie elementów podczas ładowania | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Aby strona “przeszła” Core Web Vitals, 75% rzeczywistych odwiedzin musi mieścić się w progu “Good” dla każdej z trzech metryk. Dlatego nie wystarczy, że Lighthouse w trybie laboratoryjnym pokazuje LCP 1,8 sekundy – liczy się to, co widzą realni użytkownicy na realnych urządzeniach.
Field data vs lab data – krytyczna różnica
Najczęstszy błąd przy mierzeniu CWV: firma uruchamia Lighthouse w Chrome DevTools, dostaje wynik 95/100 i uznaje sprawę za załatwioną. Tymczasem Google nie patrzy na Lighthouse. Google patrzy natomiast na CrUX (Chrome User Experience Report) – czyli dane z realnych odwiedzin użytkowników Chrome’a w ciągu ostatnich 28 dni.
Lighthouse to lab data – test w sterylnych warunkach, na symulowanej sieci 4G, na symulowanym CPU. Z kolei CrUX to field data – prawdziwy ruch z telefonów, słabego LTE w tramwaju, starych Androidów. Dlatego różnica między tymi dwoma światami potrafi wynosić nawet 2-3 sekundy LCP.
Dlatego do oceny CWV używaj w tej kolejności:
- Search Console – Core Web Vitals report (field data z CrUX, 28 dni rzeczywistych odwiedzin)
- PageSpeed Insights (pokazuje field oraz lab w jednym widoku)
- Lighthouse w Chrome DevTools (lab data, do diagnostyki konkretnego problemu)
- WebPageTest (zaawansowana analiza, kaskada zasobów, klatka po klatce)
LCP – co psuje wynik i ile kosztuje naprawa
LCP odpowiada na pytanie “kiedy użytkownik widzi główny element strony”. W praktyce to zwykle największy obraz hero na stronie głównej, główny nagłówek H1 lub główny film w tle. Dlatego optymalizacja LCP zaczyna się od identyfikacji, który element na Twojej stronie jest tym “największym”.
Pięć najczęstszych przyczyn słabego LCP
Najpierw zbyt wolny hosting. Strona na sharedzie za 9 zł miesięcznie ma TTFB (Time To First Byte) na poziomie 800-1 500 ms, co automatycznie wyklucza dobry LCP. Naprawa: migracja na dedykowany hosting WordPress (60-150 zł / miesiąc) lub VPS (od 80 zł). Czas wdrożenia – 2-5 dni, koszt migracji 400-1 500 zł.
Kolejny winowajca to niezoptymalizowane obrazy. Hero w formacie JPG ważący 2 MB to klasyk. Naprawa: konwersja do WebP lub AVIF, kompresja przez ShortPixel albo Imagify, loading="lazy" na obrazach poza viewportem. Czas – 1-3 dni dla całej strony, koszt 600-2 500 zł.
Następnie render-blocking JavaScript oraz CSS. Skrypty marketing automation, A/B testing oraz chat widgety wstawione w <head> blokują renderowanie. Naprawa: defer lub async dla niekrytycznych skryptów, przeniesienie chatu na lazy load po interakcji oraz critical CSS dla viewportu. Czas – 2-5 dni, koszt 1 500-5 000 zł.
Czwarty wzorzec to brak preconnect oraz preload dla zasobów krytycznych. Webfonty ładowane z Google Fonts bez <link rel="preconnect"> opóźniają LCP o 200-400 ms. Naprawa: preconnect do CDN-ów oraz preload dla hero image i głównych fontów. Czas – kilka godzin, koszt 200-800 zł.
Ostatni klasyk to brak CDN. Strona serwowana z jednej lokalizacji (Warszawa) odpowiada szybko klientom z Warszawy, ale wolno z Berlina czy Krakowa. Naprawa: Cloudflare (darmowy plan starczy dla większości stron) lub Bunny CDN (od 1 USD miesięcznie). Czas – 1-2 dni, koszt 200-1 000 zł.
W projektach klienckich widujemy, że poprawa LCP z 4-5 sekund do 1,5-2 sekund mieści się w przedziale 3 000 – 12 000 zł oraz 2-4 tygodnie pracy. Natomiast pełen koszt naprawy zależy od stanu wyjściowego oraz architektury strony – dlatego widełki są tak szerokie.
INP – nowa metryka, która zaskakuje
INP zastąpił FID (First Input Delay) jako oficjalna metryka Core Web Vitals w marcu 2024 roku. Zmiana jest istotna, ponieważ FID mierzył tylko opóźnienie pierwszej interakcji, podczas gdy INP mierzy najgorszy czas reakcji w całej sesji użytkownika. W efekcie strony, które wyglądały na szybkie w FID, regularnie wpadają w “Poor INP” – bo użytkownik klika 5 razy, a jedno kliknięcie zajmuje 600 ms.
Główni winowajcy słabego INP
Pierwsza kategoria to zbyt duży JavaScript bundle. Aplikacja React czy Vue z niedociętym kodem (200+ KB JS) blokuje główny wątek przeglądarki przy każdej interakcji. Naprawa: code splitting, tree shaking oraz dynamiczne importy komponentów. Czas – 3-8 dni, koszt 2 000 – 8 000 zł.
Druga kategoria to third-party scripts. Google Tag Manager z 30 tagami, Hotjar, Intercom, FB Pixel – każdy z tych skryptów wykonuje swój kod przy interakcjach użytkownika. Naprawa: audyt skryptów, lazy loading non-critical tagów oraz użycie Partytown lub Web Workers do offloadowania third-party. Czas – 2-5 dni, koszt 1 200-4 000 zł.
Trzecia kategoria to event listeners blokujące główny wątek. Tu wpadają skomplikowane animacje przy scrollu, ciężkie obliczenia w onClick oraz formularze z walidacją synchroniczną. Naprawa: debouncing, throttling, przeniesienie obliczeń do Web Workers oraz requestIdleCallback dla niekrytycznych zadań. Czas – 2-4 dni, koszt 1 500-5 000 zł.
INP to też metryka, w której WordPress z dużą liczbą wtyczek regularnie traci. Dlatego standardowo w projektach klienckich audyt zaczynamy od listy aktywnych wtyczek – często okazuje się, że 30% z nich można wyłączyć bez utraty funkcjonalności.
Strona ładuje się 5 sekund i tracisz pozycje?
Robimy audyt Core Web Vitals oraz plan naprawy LCP, INP i CLS. Diagnoza z listą priorytetów, widełki czasu oraz kosztu – bez ściemy.
Zamów audyt CWV →CLS – layout shift psuje doświadczenie i SEO
CLS mierzy, jak bardzo elementy na stronie przeskakują podczas ładowania. Klasyczny scenariusz: czytasz nagłówek artykułu, w tej chwili ładuje się banner reklamowy nad treścią, a cała strona przeskakuje w dół – w efekcie klikasz nie tam, gdzie chciałeś. Dlatego właśnie zły CLS z perspektywy użytkownika oznacza frustrację, a z perspektywy SEO – czerwony alert w Search Console.
Cztery główne źródła problemów z CLS
Najczęstszy klasyk to brak zadeklarowanych wymiarów obrazów oraz iframe. Obraz bez atrybutu width i height (lub odpowiednika w CSS) “rośnie” w trakcie ładowania, przesuwając resztę treści. Naprawa: dodanie wymiarów do wszystkich obrazów oraz iframe oraz użycie aspect-ratio w CSS. Czas – 1-2 dni, koszt 400-1 200 zł.
Drugi winowajca to wstawiane dynamicznie reklamy oraz banery. Reklama AdSense ładująca się z opóźnieniem 2 sekund i wstawiająca się między dwa akapity to gwarantowane CLS powyżej 0,3. Naprawa: rezerwowanie miejsca na reklamę (placeholder o zadeklarowanej wysokości) oraz lazy loading reklam tylko poniżej viewportu. Czas – 1-3 dni, koszt 600-2 500 zł.
Trzecia kategoria to webfonty z FOIT lub FOUT. Strona ładuje się z fontem systemowym, a po 500 ms podmienia go na custom font – dlatego przesuwa cały układ. Naprawa: font-display: swap, preload fontów oraz fallback fonts z podobnymi metrykami. Czas – kilka godzin, koszt 200-800 zł.
Ostatnia z czwórki to animacje na CSS top, left, width, height. Animacje na tych właściwościach wywołują reflow całej strony. Naprawa: refactor animacji na transform oraz opacity (które nie wywołują reflow). Czas – 1-2 dni, koszt 400-1 500 zł.
CLS to zwykle najszybsza do naprawy metryka spośród trzech, ponieważ 80% problemów można rozwiązać w tydzień pracy. Dlatego CWV report w Search Console z CLS w czerwieni to często pierwszy alarm, od którego zaczyna się audyt całej strony.
Ile kosztuje poprawa Core Web Vitals – tabela widełek rynkowych
Dla skanującego decydenta zebraliśmy 12 najczęstszych źródeł problemów z trzech metryk w jedną tabelę porównawczą – z widełkami czasu i kosztu naprawy osobno dla wizytówki WordPress oraz dla sklepu e-commerce (rynek polski, maj 2026):
| Metryka | Typowa przyczyna | Czas naprawy | Koszt WordPress | Koszt sklep e-commerce |
|---|---|---|---|---|
| LCP | Zbyt wolny hosting (TTFB 800+ ms) | 2-5 dni | 400 – 1 500 zł (migracja) | 800 – 3 000 zł |
| LCP | Niezoptymalizowane obrazy (JPG 2 MB) | 1-3 dni | 600 – 2 500 zł | 1 200 – 4 000 zł |
| LCP | Render-blocking JS oraz CSS | 2-5 dni | 1 500 – 5 000 zł | 3 000 – 8 000 zł |
| LCP | Brak preconnect oraz preload | kilka godzin | 200 – 800 zł | 400 – 1 200 zł |
| LCP | Brak CDN dla zdjęć i statyk | 1-2 dni | 200 – 1 000 zł | 500 – 2 500 zł |
| INP | Zbyt duży JavaScript bundle | 3-8 dni | 2 000 – 8 000 zł | 4 000 – 15 000 zł |
| INP | Third-party scripts (GTM, chat, pixel) | 2-5 dni | 1 200 – 4 000 zł | 2 500 – 7 000 zł |
| INP | Event listeners blokujące wątek | 2-4 dni | 1 500 – 5 000 zł | 3 000 – 8 000 zł |
| CLS | Brak wymiarów obrazów oraz iframe | 1-2 dni | 400 – 1 200 zł | 800 – 2 500 zł |
| CLS | Dynamiczne reklamy oraz banery | 1-3 dni | 600 – 2 500 zł | 1 200 – 4 000 zł |
| CLS | Webfonty z FOIT lub FOUT | kilka godzin | 200 – 800 zł | 400 – 1 200 zł |
| CLS | Animacje na CSS top/left/width | 1-2 dni | 400 – 1 500 zł | 800 – 2 500 zł |
W typowym projekcie poprawa CWV nie wymaga jednoczesnej naprawy wszystkich 12 wzorców. W efekcie audyt zaczyna się od raportu Search Console, który pokazuje 2-3 najgorsze obszary do natychmiastowej akcji. Dlatego całościowy koszt mieści się w widełkach 3 000 – 12 000 zł dla wizytówki WordPress oraz 8 000 – 30 000 zł dla średniego sklepu. Dokładna kwota zależy od stanu wyjściowego i wybranych priorytetów.
Optymalizacja CWV w WordPress – 7-punktowy plan
WordPress to środowisko, w którym 80% problemów CWV ma standardowe rozwiązania. Dlatego dla większości stron WordPress nie trzeba wymyślać od zera, wystarczy zastosować sprawdzoną kolejność:
- Cache plugin – LiteSpeed Cache (jeśli hosting LiteSpeed) lub WP Rocket (49 USD / rok). Po włączeniu LCP spada średnio o 30-50%
- Optymalizacja obrazów – ShortPixel lub Imagify – konwersja do WebP, kompresja, lazy loading. Koszt 30-100 zł / miesiąc
- CDN – Cloudflare (darmowy) lub Bunny (1-5 USD / miesiąc). LCP klientów spoza Polski spada o 200-500 ms
- Critical CSS – plugin Asset CleanUp lub WP Rocket. Eliminuje render-blocking CSS dla viewportu
- Disable WP Heartbeat oraz autosave – zmniejsza obciążenie serwera przy aktywnych edycjach
- Database optimization – WP Sweep raz w miesiącu, czyszczenie revisions oraz transientów
- Audyt wtyczek – przegląd aktywnych wtyczek, wyłączenie nieużywanych. Standardowo 20-30% można usunąć bez utraty funkcji
W typowym projekcie WordPress poprawa CWV ze stanu “Poor” do “Good” mieści się w widełkach 3 000 – 10 000 zł oraz 2-3 tygodnie pracy. Natomiast pełne audyty SEO z sekcją CWV rozkładamy szczegółowo w Audyt SEO firmy 2026 – co sprawdzamy i ile kosztuje oraz w widełkach cenowych w Audyt SEO cena 2026.
Jeśli Twoja strona dostała czerwone alerty CWV w Search Console i chcesz dostać konkretny plan naprawy, zostaw brief w formularzu wyceny. Odpowiadamy z diagnozą oraz widełkami w 2-3 dni roboczych.
CWV w sklepach e-commerce – specjalny przypadek
Sklepy internetowe (WooCommerce, Shoper, PrestaShop, Magento) mają strukturalnie trudniejszą sytuację niż wizytówki. Powodów jest kilka: większa liczba zdjęć produktów, silniki rekomendacji, opinie klientów, A/B testing platforms, marketing automation oraz integracje z magazynem. W efekcie “Good” w CWV dla sklepu wymaga 2-3 razy więcej pracy niż dla wizytówki.
W praktyce sklepowej CWV optymalizacja obejmuje:
- Migrację do szybszego silnika sklepowego, jeśli obecny tnie wydajność na poziomie architektury (Shoper Premium → Shoper Headless, WooCommerce → WooCommerce + headless frontend w Next.js)
- Optymalizację stron kategorii (pagination, filtry AJAX, lazy load produktów poniżej viewportu)
- CDN dla zdjęć produktów (Cloudflare Images, BunnyCDN Stream, ShortPixel Adaptive Images)
- Refactor wtyczek e-commerce – widget recenzji, kalkulator dostaw, wishlist – lazy loading po interakcji
- Optymalizacja koszyka oraz checkoutu (kluczowy moment konwersji, każde 100 ms LCP to mierzalny spadek conversion rate)
Realistyczne widełki optymalizacji CWV dla średniego sklepu (do 500 SKU) to 8 000 – 25 000 zł oraz 4-8 tygodni. Natomiast dla dużych sklepów (1 000+ SKU) z wielojęzycznością – 20 000 – 60 000 zł oraz 8-16 tygodni. Dlatego konkretna wycena zależy zawsze od silnika sklepu oraz stanu wyjściowego.
Dlaczego CWV są krytyczne w 2026 – trzy powody, których nie było rok temu
Najpoważniejszą zmianą są AI Overviews oraz odpowiedzi LLM. Google AI Overviews częściej cytują strony szybkie i czyste strukturalnie. Z kolei ChatGPT, Perplexity oraz Claude pobierają treść stron w real-time przy pytaniach użytkowników – dlatego jeśli Twoja strona ładuje się 6 sekund, LLM jej po prostu nie wczyta. W efekcie nieoptymalizowana strona w 2026 traci nie tylko ruch z tradycyjnego SERP, ale też z AI search, który rośnie szybciej niż klasyczne wyszukiwanie.
Druga istotna zmiana to silniejszy ranking signal niż w 2021. Google nigdy oficjalnie nie podało wagi CWV w algorytmie, jednak obserwacje branżowe sugerują, że waga rośnie z każdym update’em. Dodatkowo Google testuje nowe metryki (responsywność wizualna, stability after interaction) – dlatego strona “Good” w 2026 ma większą przewagę nad konkurencją niż w 2024.
Branża ma już też twarde liczby o biznesowych skutkach wolnego ładowania. Walmart raportował 1% spadku conversion na każde 100 ms wolniejszego LCP. Amazon pokazał podobny wzór. Polskie sklepy e-commerce, które mierzymy w projektach klienckich, wykazują podobne korelacje. Dlatego każda sekunda LCP to mierzalna strata przychodu. CWV przestały tym samym być tematem działu IT i stały się tematem zarządu.
FAQ – najczęstsze pytania o Core Web Vitals
Czy CWV wpływają na pozycję w Google?
Tak, CWV są oficjalnym sygnałem rankingowym Google od czerwca 2021 roku. Nie jest to najmocniejszy sygnał, ponieważ jakość treści oraz profil linków ważą więcej. Jednak przy podobnej jakości treści Google preferuje stronę z lepszymi CWV. Dlatego CWV “Poor” potrafi obniżyć pozycję o 3-10 miejsc, podczas gdy CWV “Good” nie gwarantuje TOP 1, ale jest warunkiem koniecznym walki o TOP 5.
Czy CWV są ważne dla AI Overviews?
Tak, choć Google nie podał oficjalnie wagi CWV w AI Overviews. Obserwacje branżowe sugerują, że szybko ładujące się oraz czyste strukturalnie strony częściej trafiają do cytatów AI. Dodatkowo LLM scrapery (GPTBot, ClaudeBot, PerplexityBot) mają timeouty – wolna strona po prostu nie zostanie pobrana w czasie zapytania użytkownika.
Co jest ważniejsze – LCP czy INP?
To zależy od typu strony. Dla wizytówek B2B oraz stron contentowych LCP jest ważniejszy, ponieważ użytkownik czyta i rzadko klika. Z kolei dla sklepów oraz aplikacji webowych INP często bywa większym problemem, bo użytkownik aktywnie interaktuje z filtrami, koszykiem, formularzami. Standardowo audyt zaczynamy od raportu Search Console, który pokazuje, która metryka jest w czerwieni.
Czy mogę poprawić CWV bez programisty?
Częściowo tak. W WordPress można zainstalować WP Rocket, ShortPixel oraz Cloudflare bez dotykania kodu – dlatego to zwykle poprawia CWV o 30-50%. Natomiast głębsza optymalizacja (critical CSS, refactor wtyczek, code splitting) wymaga programisty. W efekcie self-service rozwiązuje 60-70% problemów, a reszta wymaga audytu eksperckiego.
Ile trwa optymalizacja CWV od stanu “Poor” do “Good”?
Dla typowej strony WordPress (wizytówka B2B do 50 podstron) trwa to 2-4 tygodnie. Średni sklep WooCommerce (do 500 SKU) wymaga 4-8 tygodni. Z kolei duży sklep z wielojęzycznością – 8-16 tygodni. Po wdrożeniu zmian czeka się dodatkowo 28 dni na zaktualizowanie danych field w CrUX, ponieważ dopiero wtedy Search Console pokaże, że strona “przeszła” CWV.
Jak często Google mierzy CWV?
Google używa danych CrUX z 28-dniowego okna kroczącego. Oznacza to, że Search Console pokazuje średnią z ostatnich 4 tygodni – dlatego po wdrożeniu naprawy pełen efekt jest widoczny dopiero po miesiącu. Z kolei PageSpeed Insights pokazuje field data CrUX (28 dni) plus lab data (aktualny test) – dlatego po wdrożeniu lab data poprawia się natychmiast, a field data dopiero stopniowo.
Podsumowanie – co naprawdę warto zapamiętać
Core Web Vitals w 2026 to nie kosmetyka, lecz fundament widoczności w Google oraz cytowalności przez AI search. Trzy metryki Google obserwuje w Search Console. Pierwsza to LCP – czas wyświetlenia głównej zawartości, cel poniżej 2,5 sekundy. Druga to INP – czas reakcji na interakcję, cel poniżej 200 ms. Trzecia to CLS – stabilność układu, cel poniżej 0,1.
Wartość zaczyna się od pomiaru field data (CrUX), a nie lab data (Lighthouse). Dlatego pierwszym krokiem jest zawsze raport CWV w Google Search Console – to on pokazuje, jak Twoja strona wygląda z perspektywy realnych użytkowników, a nie symulacji w Chrome DevTools.
W środowisku WordPress 80% problemów CWV można rozwiązać kombinacją WP Rocket plus ShortPixel plus Cloudflare plus audyt wtyczek. Realistyczny koszt poprawy ze stanu “Poor” do “Good” to 3 000 – 10 000 zł oraz 2-3 tygodnie pracy. Natomiast w sklepach e-commerce zakres rośnie do 8 000 – 25 000 zł oraz 4-8 tygodni, a dla dużych sklepów wielojęzycznych nawet do 60 000 zł oraz 16 tygodni.
