Core Web Vitals 2026 — co zmieniło Google i jak to naprawić

Core Web Vitals to nadal ranking factor Google'a, ale w marcu 2024 r. FID został zastąpiony przez INP, a w 2026 r. Google subtelnie podniósł progi "good". Strony, które rok temu były zielone, dziś mogą być żółte — i tracą pozycje. Pokazuję, co dokładnie się zmieniło, jak zmierzyć i jak naprawić.

1. Co Google zmienił w 2024-2026

Trzy najważniejsze zmiany ostatnich 2 lat:

1. Marzec 2024: FID (First Input Delay) zastąpiony przez INP (Interaction to Next Paint). INP mierzy całą interakcję, nie tylko pierwszą.
2. 2025: Google zaczął ranking-penalty dla stron z poor CWV w mobile (sygnał ważniejszy niż w desktop).
3. 2026: "good" threshold dla LCP zaostrzony do 2,3s (było 2,5s) w niektórych branżach (B2B, e-commerce).

Metryka	Good	Needs improvement	Poor
LCP	≤ 2,5 s	2,5 - 4,0 s	> 4,0 s
INP	≤ 200 ms	200 - 500 ms	> 500 ms
CLS	≤ 0,1	0,1 - 0,25	> 0,25

2. LCP — Largest Contentful Paint

Czas, w którym ładuje się największy widoczny element nad foldem (zwykle hero image lub h1). Cel: ≤ 2,5 s.

4 najczęstsze przyczyny słabego LCP

1. Hero image zbyt duży — JPG/PNG zamiast WebP, brak optymalizacji rozmiaru.
2. Brak preload dla LCP elementu — Google czeka aż znajdzie obrazek w DOM.
3. Render-blocking CSS — strona czeka na cały CSS, zanim narysuje hero.
4. Serwer wolny (TTFB > 600 ms) — wszystko zaczyna się późno.

Jak naprawić LCP — konkretne techniki

<!-- 1. Preload LCP image -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

<!-- 2. fetchpriority na samym obrazku -->
<img src="/hero.webp" fetchpriority="high" alt="..." width="1200" height="600" />

<!-- 3. Non-blocking font load -->
<link
  href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap"
  rel="stylesheet"
  media="print"
  onload="this.media='all'"
/>

Dla obrazów — zawsze WebP lub AVIF:

<picture>
  <source type="image/avif" srcset="/hero.avif" />
  <source type="image/webp" srcset="/hero.webp" />
  <img src="/hero.jpg" alt="..." width="1200" height="600" loading="eager" fetchpriority="high" />
</picture>

3. INP — Interaction to Next Paint (zamiast FID)

INP mierzy opóźnienie między interakcją użytkownika (klik, tap, key) a wizualną zmianą na ekranie. Różni się od FID:

• FID: tylko pierwsza interakcja
• INP: każda interakcja, raportowane najgorsze opóźnienie

INP odsłania problemy, które FID maskował: kliknięcie na "Dodaj do koszyka" które trwa 800 ms, modal który otwiera się 500 ms.

4 przyczyny słabego INP

1. Duże event handlery JS (np. analytics na każdym kliku)
2. Synchroniczne renderowanie React bez useDeferredValue / useTransition
3. Brak debounce'u na input handlers (każdy znak triggeruje 5 ms pracy)
4. Hydration heavy — React/Vue zamraża main thread na 1-3 s po załadowaniu

Jak naprawić INP

// 1. Debounce input handlers
import { useDeferredValue } from 'react';

function Search({ query }) {
  const deferredQuery = useDeferredValue(query);
  // ... użyj deferredQuery zamiast query
}

// 2. Yield to browser w długich zadaniach
async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    process(items[i]);
    if (i % 100 === 0) {
      // Daj browserowi szansę odpaść do "responsive"
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

// 3. requestIdleCallback dla analytics
requestIdleCallback(() => {
  // Wyślij analytics gdy browser jest idle
  sendAnalytics();
});

4. CLS — Cumulative Layout Shift

CLS mierzy "skakanie" treści podczas ładowania. Cel: ≤ 0,1.

Główne przyczyny CLS

1. Obrazy bez width/height — browser nie wie, ile miejsca zarezerwować
2. Reklamy wstawiane dynamicznie nad foldem
3. Web fonts bez fallbacku — tekst "skacze" gdy zmienia się font
4. Treść dodawana po hydration (banery cookie, notyfikacje)

Jak naprawić CLS

<!-- 1. ZAWSZE width + height na obrazkach -->
<img src="/foto.webp" width="800" height="600" alt="..." />

<!-- 2. Rezerwuj miejsce dla dynamicznej treści -->
<style>
  .ad-slot {
    min-height: 250px; /* Zarezerwowane miejsce dla reklamy */
    width: 300px;
  }
  .banner-cookie {
    min-height: 60px; /* Banner nie 'skacze' przy pojawieniu */
  }
</style>

<!-- 3. Font swap z size-adjust -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/inter.woff2');
    font-display: swap;
    /* Inter ma podobne proporcje do Arial */
    size-adjust: 105%;
  }
</style>

5. Narzędzia — które używać i kiedy

Narzędzie	Co mierzy	Kiedy używać
PageSpeed Insights	Lab + Field data CrUX	Pierwsza analiza, raport dla klienta
Lighthouse (Chrome DevTools)	Lab data (symulowane)	Lokalne testowanie zmian
Search Console — Core Web Vitals	Field data z prawdziwych userów	Monitoring trendów (28-dniowy)
Vercel/Cloudflare Analytics	Real User Monitoring	Production debugging, A/B testing
WebPageTest	Lab data, waterfall, multiple devices	Głęboka analiza wąskich gardeł

6. Lab data vs Field data (CrUX)

To najważniejsza różnica, której wielu nie rozumie:

• Lab data (Lighthouse): test w idealnych warunkach (symulowane mobile, throttled CPU). Daje punkt referencyjny.
• Field data (CrUX): faktyczne dane z przeglądarek Chrome 28 mln+ użytkowników. Google używa field data jako ranking factor.

Możesz mieć Lighthouse 95/100 i jednocześnie field data "Poor" — bo Twoi userzy są na słabym 4G i starym Androidzie. Optymalizuj pod field data.

7. Dlaczego mobile jest ważniejsze

Google używa mobile-first indexing od 2020 r. — to mobile metryki decydują o pozycji. W 2026 r. ~70% wyszukiwań to mobile.

Praktyczna konsekwencja: jeśli desktop ma LCP 1,2 s, ale mobile 4,5 s — Google ocenia Cię na 4,5 s. Optymalizuj najpierw mobile.

8. Checklist optymalizacji CWV

• ✅ Hero image w WebP/AVIF + fetchpriority="high"
• ✅ Preload dla LCP elementu
• ✅ Wszystkie obrazy z width + height
• ✅ Fonts z font-display: swap + size-adjust
• ✅ Lazy loading dla obrazów poza foldem (loading="lazy")
• ✅ Defer non-critical JS (defer lub type="module")
• ✅ Critical CSS inline (lub render-blocking CSS minimalny)
• ✅ Banery cookie z zarezerwowaną wysokością
• ✅ TTFB < 600 ms (CDN + dobry hosting)
• ✅ Brak długich tasków > 200 ms w event handlerach
• ✅ Monitoring w GSC Core Web Vitals + Vercel/CF Analytics

---

Podsumowanie

Core Web Vitals to nie "ficzer", to warunek konieczny rankowania w 2026 r. INP wymaga większej uwagi niż dawny FID, mobile metryki są ważniejsze niż desktop, a field data > lab data.

Jeśli Twoja strona ma pozycje w GSC, ale spada od kilku miesięcy bez merytorycznego powodu — sprawdź Search Console > Core Web Vitals. Często to wystarczy żeby znaleźć przyczynę.

Podobne artykuły