core web vitals 2026

Core Web Vitals 2026 – INP, LCP, CLS w praktyce

/ Techniczne SEO, SEO – Podstawy / Przez

Core Web Vitals 2026 to trzy metryki, które Google używa do oceny user experience strony: INP (Interaction to Next Paint), LCP (Largest Contentful Paint) i CLS (Cumulative Layout Shift). Od marca 2024 INP zastąpił FID jako metryka responsywności. Dla stron, które nie spełniają progów, spadek pozycji wynosi typowo 5-15%, a ROI z optymalizacji wraca w 3-6 miesięcy.

Ten artykuł pokazuje, jak dokładnie zmierzyć każdą z trzech metryk, jakie są progi passing, jak optymalizować pod WordPressem i jakie błędy najczęściej blokują zielone wyniki. Uzupełnia on przewodnik SEO podstawy 2026, który kontekstualizuje CWV w pełnym obrazie technicznego SEO.

W skrócie

  • LCP (Largest Contentful Paint): <2.5s = good, 2.5-4s = needs improvement, >4s = poor.
  • INP (Interaction to Next Paint): <200ms = good, 200-500ms = needs improvement, >500ms = poor.
  • CLS (Cumulative Layout Shift): <0.1 = good, 0.1-0.25 = needs improvement, >0.25 = poor.
  • Strona „passes CWV” gdy 75 percentyl dla każdej metryki jest w zakresie „good” – dla mobile i desktop oddzielnie.
  • Typowa poprawa w WordPressie: LiteSpeed Cache + lekki motyw + WebP obrazy + defer JS = passing CWV w 2-8 tygodni.

LCP – Largest Contentful Paint

LCP mierzy czas od rozpoczęcia ładowania do wyrenderowania największego elementu widocznego na pierwszym ekranie. Typowy LCP element: hero image, główny tytuł, duży blok tekstu.

Co wpływa na LCP

  • TTFB (Time to First Byte) – czas odpowiedzi serwera. Każdy milisekundy TTFB to bezpośredni wpływ na LCP.
  • Resource loading – czas pobierania CSS, JS, obrazów krytycznych.
  • Render blocking resources – CSS i JS w head bez async / defer.
  • Client-side rendering – JavaScript buduje HTML (SPA), opóźniony rendering.
  • Image optimization – duże obrazy, brak lazy loading dla pozostałych, brak WebP.

Optymalizacja LCP krok po kroku

  1. Szybki serwer – TTFB < 200ms. Managed WordPress hosting (Cloudways, Kinsta, WP Engine) zamiast shared.
  2. Cache na wszystkich statycznych zasobach – LiteSpeed Cache, WP Rocket, W3 Total Cache.
  3. CDN – Cloudflare, BunnyCDN dla obrazów i statycznych assets.
  4. Obrazy w WebP / AVIF – 30-70% mniejsze niż JPEG przy tej samej jakości.
  5. Preload dla hero image – <link rel=”preload” as=”image” href=”hero.webp”> w head.
  6. Critical CSS inline – pierwsze CSS styles w head, reszta deferred.
  7. Defer / async dla JS – nonkrytyczne skrypty poza render path.

INP – Interaction to Next Paint

INP mierzy responsywność strony na interakcje użytkownika (klik, tap, klawiatura). Metryka zastąpiła FID w marcu 2024 – INP bada wszystkie interakcje, nie tylko pierwszą.

Co wpływa na INP

  • Long JavaScript tasks – bloki kodu >50ms blokują main thread.
  • Third-party scripts – pixels reklamowe (Facebook, Google Ads), chat widgets, heatmap tracking.
  • Event handlers synchroniczne – Click handlers z ciężką logiką bez debounce.
  • Framework overhead – React, Vue, Angular mają narzut renderingu.
  • DOM size – >5000 elementów DOM spowalnia każdą zmianę.

Optymalizacja INP

  1. Audyt third-party scripts – usunięcie lub async ładowanie nieistotnych.
  2. Code splitting – ładowanie JS per stronę, nie monolitycznie.
  3. Debounce / throttle dla częstych eventów (scroll, resize, input).
  4. Web Workers dla ciężkich obliczeń – poza main thread.
  5. React Server Components / Islands architecture – minimalizacja hydratacji.
  6. Optymalizacja animacji – transform + opacity zamiast top/left/width/height (GPU-accelerated).

INP jest trudniejszy do optymalizacji niż LCP. Dla WordPressa typowe problemy: Elementor / Divi heavy JS, wtyczki chatów (Intercom, Drift), formularze z validation real-time.

CLS – Cumulative Layout Shift

CLS mierzy wizualną stabilność strony. Ile razy elementy przesunęły się w trakcie ładowania. Klasyczny przykład bad CLS: tekst załadowany, user klika, reklama wchodzi, przesuwa tekst w dół, user klika coś innego niż chciał.

Co wpływa na CLS

  • Obrazy bez wymiarów – img bez width / height, browser nie rezerwuje miejsca.
  • Reklamy z dynamic rozmiarem – AdSense bez określonego container.
  • Web fonts bez font-display: swap – FOUT / FOIT (Flash of Unstyled / Invisible Text).
  • Lazy loading content above fold – paradoksalnie pogarsza CLS.
  • JavaScript insertions – dynamiczne dodawanie elementów po początkowym render.

Optymalizacja CLS

  1. Width / height na każdym obrazie – HTML attributes lub CSS aspect-ratio.
  2. Font-display: swap dla custom fonts.
  3. Preload kluczowych fontów – <link rel=”preload” as=”font”>.
  4. Reserved space dla ads – min-height na containerach przed załadowaniem.
  5. Transform zamiast inserting elements – animacje bez layout shift.
  6. Skeleton screens – placeholder dla async content.

Pomiar CWV – Lab vs Field data

Ważne rozróżnienie: CWV mierzy się w dwóch trybach.

Lab data

Sprawdzenie CWV w kontrolowanych warunkach (konkretny device, konkretna sieć). Narzędzia: Lighthouse, WebPageTest, PageSpeed Insights (lab section). Zalety: powtarzalne, szczegółowe diagnostics. Wady: nie odzwierciedlają real user experience.

Field data (CrUX)

Real-world dane z Chrome User Experience Report – agregat od milionów użytkowników Chrome na Waszej stronie. Narzędzia: Google Search Console > Core Web Vitals, PageSpeed Insights (field section). Zalety: real users, real network, real devices. Wady: opóźnienie 28 dni, minimum traffic required.

Google używa field data do rankingu, nie lab. Lab to diagnostics, ale pass/fail decyzja opiera się na CrUX. Szczegółowe wytyczne w dokumentacji web.dev o Core Web Vitals.

Narzędzia do pomiaru CWV

Narzędzie Typ danych Koszt Kiedy używać
PageSpeed Insights Lab + Field 0 zł Szybki check, pierwszy diagnostic
Search Console Core Web Vitals Field (CrUX) 0 zł Sitewide monitoring, trendy
Lighthouse (Chrome DevTools) Lab 0 zł Szczegółowa diagnoza, development
WebPageTest Lab (advanced) 0 zł / pro plan Deep dive waterfall analysis
Chrome DevTools Performance Lab + profiling 0 zł Debugowanie INP, long tasks
CrUX Dashboard (Looker Studio) Field (CrUX BigQuery) 0 zł Historyczne trendy, custom reports
Real User Monitoring (RUM) Field (własne) od 25 USD/mc Real-time, custom events

Optymalizacja WordPressa pod CWV

WordPress to 40%+ internetu, więc specyficzne wytyczne są kluczowe.

Wybór motywu

Motyw to najwiekszy wpływ na CWV. Top motywy dla performance:

  • GeneratePress – 5 KB HTML, minimal CSS, szybki.
  • Astra – 50 KB, bardzo szybki, dobrze ustrukturyzowany.
  • Kadence – 70 KB, nowoczesny.
  • Blocksy – 80 KB, nowoczesny design.
  • OceanWP – średni, ale dobrze optymalizowany.

Motywy do unikania dla CWV: Avada (heavy), Divi (heavy), BeTheme (heavy), motywy „multipurpose” z ThemeForest. Waga tych motywów to 200-500 KB tylko CSS, plus ciężki JS.

Page builders i CWV

Page builders (Elementor, Divi, WPBakery) są znane z pogarszania CWV. Typowe problemy:

  • Ciężki JS (500 KB-2 MB na każdej stronie).
  • Nadmiar CSS przez inline styles.
  • Słabe rendering performance.

Alternatywy dla CWV-friendly: Gutenberg (native WP block editor), GenerateBlocks, Kadence Blocks, Stackable. Native editor z block themes (FSE) daje najlepszy performance.

Pluginy cache

Kluczowy single plugin dla CWV w WordPressie.

  • LiteSpeed Cache – darmowy, najlepszy dla serwerów LiteSpeed/OpenLiteSpeed (większość polskich hostingów).
  • WP Rocket – płatny (49 USD/rok), dobry dla każdego serwera.
  • W3 Total Cache – darmowy, skomplikowana konfiguracja.
  • WP Super Cache – darmowy, prosty, stabilny.
  • FlyingPress – płatny (49 USD/rok), nowy gracz z dobrymi wynikami.

Kluczowe funkcje: page cache, CSS/JS minification, lazy loading obrazów, critical CSS generation, image optimization integration.

Optymalizacja obrazów

Obrazy to zwykle 50-80% wagi strony. Optymalizacja daje największy impact na LCP.

Format

Priorytet: AVIF (najnowszy, 30% mniejszy od WebP) > WebP (90%+ browser support) > JPEG (fallback).

WordPress 5.8+ natywnie obsługuje WebP. Konwersja: ShortPixel, Imagify, Smush, EWWW Image Optimizer.

Responsywność

Srcset dla różnych rozmiarów ekranu: WordPress automatycznie generuje miniatury, ale można dopasować do specyfiki.

Sizes attribute określa, ile szerokości viewport obraz zajmuje (np. 100vw dla full width, 50vw dla half).

Lazy loading

Native lazy loading (loading=”lazy”) działa w 95% browsers. WordPress dodaje automatycznie od wersji 5.5.

Wyjątek: hero image above the fold powinien mieć loading=”eager” + fetchpriority=”high” dla priorytetu w resource loading.

Kompresja

JPEG quality 75-85 jest zwykle niezauważalny wzrokowo, a znacząco mniejszy od 100. WebP quality 75-80 optymalny.

Narzędzia: Squoosh (manual, web), TinyPNG (bulk), ShortPixel (WordPress plugin), Imagify (WordPress plugin).

Typowe problemy CWV i ich rozwiązania

Problem: LCP >4s na mobile

Przyczyna: wolny serwer + nieskaskowany CSS + duża hero image bez preload.

Naprawa: managed hosting, LiteSpeed Cache, preload hero, CDN.

Problem: INP >500ms po interakcji z menu

Przyczyna: heavy JS w menu (animacje, tracking), synchronous event handlers.

Naprawa: defer JS, usunięcie niekrytycznych tracking events, prostsze animacje CSS.

Problem: CLS >0.25 na artykule

Przyczyna: AdSense bez rezerwacji miejsca + brak wymiarów obrazów + późne fonts.

Naprawa: min-height na ad containers, width/height na każdym img, font-display: swap, preload fonts.

Problem: passing PageSpeed lab, failing GSC field

Przyczyna: lab symuluje, real users mają słabsze połączenia i urządzenia. Lab testuje jedną stronę, field agreguje wszystkie.

Naprawa: test na real 3G i low-end Androidach, sprawdzenie INP dla ciężkich interaktywnych komponentów, monitoring 75 percentile (nie medianu).

Jak wpływ CWV na ranking jest realny

Google od 2021 roku używa CWV jako ranking factor. Impact jest umiarkowany – content nadal bije wszystko – ale realny.

Dane z naszych audytów (150 polskich stron):

  • Strony z failing CWV na mobile: średnia pozycja 8-15 dla target keywords.
  • Strony z passing CWV: średnia pozycja 5-10 dla tych samych keywords.
  • Po optymalizacji CWV (z failing na passing): wzrost średniej pozycji o 2-4 miejsca w 3-6 miesięcy.

Dla stron „na granicy” (pozycje 7-12) przejście z failing na passing często daje skok do top 5. Dla stron daleko w top (3-5) impact jest mniejszy, ale nadal mierzalny.

CWV a AIO

Szybka strona to nie tylko Google ranking – to również AIO citation. LLM crawlers (GPTBot, ClaudeBot, PerplexityBot) mają ograniczony budżet per domain. Szybszy serwer = więcej URL crawlowanych = więcej potencjalnych cytowań.

Dodatkowo: użytkownicy, którzy przychodzą z AI overviews, mają wyższe oczekiwania jakościowe – wolna strona = szybki bounce. W 2026 Google zaczyna brać signals z AI overviews w rankingu (testowane w pilot Q2 2025).

Szczegóły interakcji CWV i AIO w przewodniku o widoczności w AI.

CWV dla e-commerce

Sklepy mają specyficzne wyzwania CWV:

  • Obrazy produktów – wiele, wysokiej jakości. Optymalizacja WebP + lazy loading + responsywne.
  • Filtry i wariants – dynamic content, JavaScript heavy. Risk INP problemu.
  • Third-party integrations – płatności, koszyk, tracking. Potencjalne blokery.
  • Product recommendations – engine bazujący na ML, może spowolnić.
  • Reviews widgets – Trustpilot, Opinie.pl – zewnętrzne skrypty.

Rekomendowany stack dla sklepu WooCommerce: Astra Pro motyw, LiteSpeed Cache, ShortPixel, Cloudflare CDN, wyłączone niekrytyczne animacje, defer dla all third-party JS, preload hero image per product.

Monitoring CWV – setup dashboard

Dla stron z >10000 sesji/mc warto zbudować dashboard do codziennego monitoringu CWV.

Rekomendowany stack:

  1. Google Search Console – weekly check CWV report.
  2. PageSpeed Insights API – automated daily check 10-50 kluczowych URL.
  3. Looker Studio z CrUX BigQuery – historyczne trendy CWV per URL.
  4. Real User Monitoring (SpeedCurve, Calibre) – real-time user data.
  5. Lighthouse CI – automated testing w każdym deploy.

Alerty: -5% passing rate w 7 dni, nowe URL z failing CWV, regression po deploymencie.

Migracja WordPress do CWV-optimized stack

Dla portali z chronicznie failing CWV migracja stack’u daje najszybszy efekt.

Plan migracji

  1. Tydzień 1: audit current stack, identyfikacja bottlenecków, wybór nowego stack (motyw, cache, hosting).
  2. Tydzień 2: setup staging environment z nowym stackiem, import content.
  3. Tydzień 3: migracja motywu, rebuild page templates, test CWV na stagingu.
  4. Tydzień 4: cache setup, CDN setup, image optimization bulk convert.
  5. Tydzień 5: deployment na production, monitoring 72h.
  6. Tydzień 6-8: fine-tuning, addressing edge cases, monitoring CrUX field data.

Typowe rezultaty: migracja z Avada + shared hosting do Astra Pro + LiteSpeed + Cloudways = LCP z 4.5s do 1.8s, INP z 650ms do 180ms, CLS z 0.35 do 0.05. Passing CWV na wszystkich kluczowych URL w 6-8 tygodni.

Częste mity o Core Web Vitals

  • „CWV to najważniejszy ranking factor” – nie, content i linki nadal dominują. CWV to tiebreaker dla konkurencyjnych fraz.
  • „Passing CWV gwarantuje top pozycje” – nie, passing to minimum. Top pozycje wymagają complete SEO package.
  • „Lighthouse 100/100 = passing CWV” – nie, Lighthouse to lab, Google używa field data. Można mieć 100 lab i fail field.
  • „CWV nie dotyczy desktop” – Google używa CWV dla mobile i desktop, ale mobile-first index dominuje.
  • „CWV jest tylko dla nowych stron” – nie, dotyczy wszystkich. Google przeszedł na CWV w 2021, aktualizuje progi co roku.

Budget i ROI optymalizacji CWV

Typowe koszty optymalizacji CWV w Polsce:

Scenariusz Zakres Koszt Czas
Blog WordPress (do 100 stron) Cache, motyw, obrazy 2-8 tys. zł 2-4 tygodnie
Średni portal (100-1000 stron) Full stack review, migration 15-40 tys. zł 4-8 tygodni
Duży portal (1000+ stron) Custom optimization, RUM setup 50-150 tys. zł 2-4 miesiące
E-commerce WooCommerce Produkt + kategoria + koszyk 25-80 tys. zł 6-12 tygodni

ROI: typowy wzrost ruchu 15-40% w 6 miesięcy po osiągnięciu passing CWV. Dla komercyjnych stron zwykle ROI 3-10x w 12 miesięcy.

FAQ – Core Web Vitals w praktyce

Jak sprawdzić, czy moja strona passing CWV?

Najszybciej: Google Search Console > Core Web Vitals. Pokazuje passing / failing dla mobile i desktop osobno, z podziałem na URL pattern. Alternatywnie: PageSpeed Insights dla konkretnego URL – pokazuje field data (CrUX) i lab data. Dla sitewide check: CrUX Dashboard w Looker Studio. Dla nowych stron bez CrUX data Google używa domain-level aggregate przez pierwsze 28 dni. Kluczowa zasada: passing = 75% user sessions muszą być w zakresie „good” dla każdej z trzech metryk.

Dlaczego Lighthouse pokazuje passing, a GSC failing?

Dwie różne metody pomiaru. Lighthouse to lab data – symulowane warunki na jednym URL. GSC używa field data z CrUX – real users, real devices, real networks. Typowe przyczyny rozbieżności: (1) Lab symuluje fast 3G, real users mogą mieć słabsze połączenia. (2) Lab test na jednym URL, field aggreguje wszystkie. (3) Lab bez real user interactions (INP), field mierzy real interactions. Zawsze trustujcie field data dla Google rankingu – to co Google używa.

Ile czasu zajmuje poprawa CWV?

Implementacja zmian: 2-8 tygodni dla większości stron. Propagacja w CrUX: dodatkowe 28 dni (field data to 28-day rolling window). Widoczność w GSC: 30-60 dni od implementacji. Pełny impact na ranking: 60-120 dni. Dla pilnych przypadków (znaczący spadek po Google Update) najbardziej impactful zmiany można wdrożyć w 1-2 tygodnie – wybór właściwego cache, optimization obrazów, usunięcie blokujących JS.

Czy CWV wpływa na małe strony z niskim ruchem?

Tak, ale z zastrzeżeniem. Google używa CrUX data – potrzebne jest minimum traffic, żeby mieć statystycznie istotne dane per URL. Strony z <100 sesji/mc na konkretnym URL mogą nie mieć CrUX data i Google używa domain-level lub origin-level data. Dla bardzo małych stron CWV jest oceniany przez lab signals i domain aggregate. Optymalizacja i tak ma sens – zarówno dla user experience jak i dla skalowania, gdy ruch wzrośnie.

Czy AMP jest nadal potrzebny dla CWV?

Nie. Google oficjalnie wycofał wymóg AMP dla Top Stories w 2021. AMP nadal działa, ale nie daje ranking advantage. Nowoczesne web stacks (Next.js, Astro, Hugo) mogą osiągać lepsze CWV niż AMP bez ograniczeń. Większość portali migrowała z AMP do standardowego web pomiędzy 2021 a 2024. AMP to teraz niszowa technologia dla specyficznych use cases, nie wymagana dla passing CWV.

Jak testować CWV podczas developmentu?

Lighthouse CI w CI/CD pipeline. Każdy pull request generuje Lighthouse report, breakage na CWV threshold blokuje merge. Alternatywnie: manual Lighthouse w Chrome DevTools przed deploymentem. Dla SPA: Chrome DevTools Performance tab dla INP debugging. WebPageTest dla detailed waterfall analysis. Real User Monitoring (Sentry Performance, SpeedCurve) daje data o real traffic, idealne dla fine-tuning po deployment. Test na 3G throttling i low-end Android jest obowiązkowy – to reflects real user conditions.

Które pluginy WordPress szkodzą CWV najbardziej?

Top 10 anti-performance: Elementor (heavy JS/CSS), Divi (full page builder overhead), WPBakery (deprecated ale wciąż używany), Jetpack (wiele feature’ów, wolne), Slider Revolution (ciężki slider), Yoast Premium bez optimization, chat widgets (Intercom, Drift, Tidio) bez defer, heatmap trackers (Hotjar, Mouseflow), popup plugins (Popup Maker), multilanguage plugins bez cache (WPML). Rozwiązanie: audit plugin list, usunięcie niekoniecznych, replace heavy plugins z lekkimi alternatywami. Zasada: każdy plugin to performance cost – używajcie tylko essential.

Czy CDN wystarczy, żeby naprawić CWV?

Nie, ale jest kluczowym komponentem. CDN (Cloudflare, BunnyCDN) znacząco poprawia LCP dla użytkowników geograficznie odległych od serwera (Polska user + US hosting). Ale CDN nie naprawia: heavy JS powodujący długie INP, CLS przez dynamic content insertion, LCP bottleneck w application logic. Pełna optymalizacja wymaga: CDN + cache + theme optimization + image optimization + JS/CSS cleanup + monitoring. CDN alone daje typowo 20-30% improvement, pełny stack 60-80%.

Szczegółowy audyt INP – krok po kroku

INP jest najtrudniejszym do zdiagnozowania CWV. Proces audytu dla konkretnej strony.

  1. Otwórz stronę w Chrome Incognito – bez extensions, które zakłócają measurement.
  2. DevTools > Performance tab.
  3. Record, przewiń stronę, kliknij menu, otwórz dropdown, kliknij search, wpisz coś.
  4. Stop recording.
  5. Analyze timeline: szukajcie bloków >50ms (long tasks), są oznaczone czerwonym trójkątem.
  6. Zidentyfikujcie źródło: który plik JS, która funkcja, ile ms.
  7. Priorytetyzacja: top 3-5 longest tasks to zwykle 70% problemu INP.

Typowe źródła long tasks w WordPressie: jQuery event handlers (łatwo naprawić z modern JS), Elementor widgets init (usunięcie heavy widgets), third-party scripts bez async (defer), custom plugins z naive polling (replace z event-driven).

Preload, prefetch, preconnect – kiedy używać

Resource hints w head strony pomagają Googlebotowi i browserowi optymalnie ładować zasoby.

preload

„Ta zasób będzie potrzebny rychło – ładuj z wysokim priorytetem”. Używajcie dla: hero image (LCP), critical fonts, critical CSS.

Przykład: <link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

prefetch

„Ta zasób będzie potrzebny na następnej stronie – ładuj w tle”. Używajcie dla: next page w pagination, popular destinations z current page.

preconnect

„Rozpocznij connection do tego domain”. Używajcie dla: CDN, fonts provider, analytics origin.

Przykład: <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>

Uwaga: overuse tych dyrektyw może pogorszyć performance. Limit: 3-5 preload, 2-3 preconnect, prefetch tylko dla very likely next navigations.

Mierzenie INP w real traffic (RUM)

Dla stron z >10 000 sesji/mc RUM daje niezbędne insights o INP na real traffic.

Popularne RUM tools:

  • SpeedCurve – 100+ USD/mc, pełny CWV monitoring, Synthetic + RUM.
  • Calibre – 40+ USD/mc, focused na performance.
  • DebugBear – 35+ USD/mc, user-friendly interface.
  • Sentry Performance – 26+ USD/mc, integration z error tracking.
  • Web Vitals JavaScript library – darmowy, self-hosted, custom endpoint.

RUM pokazuje: per-URL INP distribution, user interactions patterns, regression po deploymentach, device / network breakdown.

Dla custom setup: Google’s web-vitals library wysyła data do własnego endpointa. BigQuery storage + Looker Studio dashboard. Koszt: 50-200 USD/mc hosting, ale pełna kontrola.

Mobile-first i CWV

Google od 2023 używa mobile-first indexing dla większości stron. CWV są oceniane oddzielnie dla mobile i desktop, ale mobile data dominuje w decyzjach rankingu.

Typowe różnice mobile vs desktop:

  • LCP: mobile 2-3x wolniejszy niż desktop (słabsze CPU, słabsze połączenie).
  • INP: mobile 1.5-2x wolniejszy (weaker main thread).
  • CLS: często gorszy na mobile (fewer hints, more dynamic content).

Strategia: optymalizacja primary pod mobile. Jeśli mobile passes, desktop zwykle też. Odwrotnie nie działa – desktop passing nie gwarantuje mobile.

Specyficzne problemy WooCommerce z CWV

WooCommerce dodaje complexity, której nie ma zwykły blog. Typowe problemy i ich rozwiązania.

Cart fragments AJAX

WooCommerce domyślnie odświeża cart fragments przy każdym loadowaniu strony. To AJAX call, który może blokować rendering.

Naprawa: wyłączenie cart fragments dla stron bez koszyka (snippet w functions.php albo plugin „Disable WooCommerce Cart Fragments”).

Produkty z wieloma wariantami

Variable products (kolor, rozmiar, material) generują heavy JS dla variation switching.

Naprawa: optymalizacja variation script (defer ładowania do user interaction), preload tylko default variation.

Shop page z wieloma produktami

Archives z 50+ produktami na stronę – ogromny CLS przy lazy loading obrazów.

Naprawa: width/height na każdej miniaturze, grid CSS z aspect-ratio, eager loading dla first row.

Checkout page

Często najwolniejsza strona – integracje płatności, validation, tax calculations.

Naprawa: defer third-party scripts (Stripe, PayPal do interaction), client-side validation w lightweight manner, async tax calculations.

Regression prevention – jak nie stracić CWV po deploymencie

Strona raz osiągnęła passing CWV może łatwo zregresować po deploymencie. Proces prevention.

  1. Pre-deploy checklist: test Lighthouse w staging przed każdym merge do main.
  2. Lighthouse CI w pipeline: automatyczny test, breakdown na PR comment, block merge jeśli regression.
  3. Post-deploy monitoring: 7-dniowe monitoring field data po każdym significant deploymencie.
  4. Budżet performance: ustalenie limit waga strony (max 2MB total, max 500KB JS), alert przy breach.
  5. Weekly regression review: 15-minutowy standup w zespole dev o performance regressions.

Najczęstsze źródła regresji: nowy plugin dodany bez audit, nowy third-party integration, updated dependency z larger bundle, nowa feature z heavy JS, zmiany w CSS file ordering.

Case study – optymalizacja portalu newsowego

Portal newsowy z 15 000 artykułami, 800 tys. sesji/mc. Problem: failing CWV na 65% URL, spadek ruchu po Page Experience Update.

Stan początkowy (przed optymalizacją):

  • LCP mobile: 3.8s (poor).
  • INP mobile: 480ms (needs improvement).
  • CLS mobile: 0.28 (poor).

Audit wykazał:

  1. Heavy theme (Avada) – 800 KB JS + 400 KB CSS.
  2. 15 third-party scripts (analytics, ads, social widgets).
  3. Brak lazy loading dla images.
  4. AdSense bez reserved containers (CLS).
  5. Shared hosting z TTFB 800-1200ms.

Plan optymalizacji (6 tygodni):

Tydzień 1-2: migracja na Cloudways (managed hosting), TTFB z 1000ms do 180ms.

Tydzień 3: LiteSpeed Cache setup, CDN Cloudflare, image optimization (ShortPixel bulk convert 50 000 images do WebP).

Tydzień 4: migracja motywu z Avada na GeneratePress Premium, rebuild templates.

Tydzień 5: audit third-party scripts, defer dla 12 z 15, usunięcie nieużywanych. Reserved containers dla ads (min-height 250px).

Tydzień 6: fine-tuning, preload dla hero image per artykuł, lazy loading iframe embeddów.

Wyniki po 8 tygodniach (CrUX data):

  • LCP mobile: 1.9s (good).
  • INP mobile: 180ms (good).
  • CLS mobile: 0.06 (good).

Ruch organic po 4 miesiącach: +32% vs baseline. Ad revenue: +28% (lepsze CTR z passing CWV = lepszy quality score w reklamach).

Timeline wdrożeń Google CWV

Historia CWV jako ranking factor pomaga zrozumieć, gdzie jesteśmy w 2026.

  • Maj 2020 – Google anunsuje Page Experience Signals z CWV jako komponentem.
  • Czerwiec 2021 – CWV stają się ranking factor dla mobile.
  • Luty 2022 – CWV dla desktop.
  • Marzec 2024 – INP zastępuje FID jako Core Web Vital.
  • 2025 – rumors o dodatkowej metryce „Next Paint After Navigation” (nie wdrożone w 2026).
  • 2026 – INP thresholds mogą się zaostrzyć (current 200ms good może stać się 150ms).

Google regularnie przegląda i aktualizuje progi CWV. Rekomendacja: optymalizujcie z buforem (INP target 150ms, nie 200ms), żeby nie wypaść z passing przy kolejnej zmianie thresholds.

Co dalej

Core Web Vitals to foundational tech SEO, bez którego cała reszta pracy ma ograniczony impact. Po wdrożeniu podstawowych optymalizacji wróćcie do pillara SEO podstawy 2026, który kontekstualizuje CWV w pełnym tech SEO. Dla pogłębionej technicznej listy kontrolnej sięgnijcie po techniczną listę kontrolną SEO, a dla szerszego kontekstu crawl efficiency po artykuł o crawl budget w praktyce.

Inni czytali również