Core Web Vitals — jak przyspieszyć stronę i poprawić pozycję w Google

To ważne nie tylko z perspektywy SEO, ale po prostu jakości produktu, która wiąże się bezpośrednio z wynikami biznesowymi. Szybsza i stabilniejsza strona daje lepszą konwersję, mniejszą frustrację użytkowników i mniej problemów na słabszych urządzeniach lub urządzeniach mobilnych.

W tym artykule wyjaśnię, czym są Core Web Vitals, jak je mierzyć i jak podchodzić do optymalizacji w praktyce.

Czym są Core Web Vitals i dlaczego wpływają na SEO?

Core Web Vitals to zestaw trzech metryk, które Google uznał za kluczowe dla doświadczenia użytkownika, a każda z nich mierzy inny aspekt interakcji ze stroną:

• LCP (Largest Contentful Paint), czyli jak szybko ładuje się główna treść strony,

• INP (Interaction to Next Paint), odpowiada jak responsywna jest strona na interakcje użytkownika,

• CLS (Cumulative Layout Shift), mówi jak stabilny jest układ strony podczas ładowania.

Te trzy metryki razem odpowiadają na bardzo praktyczne pytania: czy użytkownik szybko widzi główną treść, czy interfejs reaguje na kliknięcia i czy layout pozostaje stabilny.

Jak Google ocenia Core Web Vitals: pass i fail

Warto tutaj wyróżnić, że Google nie ocenia Twojej strony po jednym ładowaniu ani po średniej. Każda metryka jest oceniana na 75. percentylu wszystkich realnych odsłon z ostatnich 28 dni. Oznacza to, że żeby zaliczyć daną metrykę, 75% Twoich użytkowników musi mieścić się w progu „good", a o wyniku decydują te 25% najwolniejszych odsłon.

Z tego wynikają trzy praktyczne konsekwencje:

• Mobile i desktop są oceniane osobno. Strona może mieć zielony desktop i czerwony mobile — i to mobile zwykle decyduje o sygnale, bo Google indeksuje mobile-first.
• Cała strona zalicza CWV tylko wtedy, gdy wszystkie trzy metryki są w „good" na p75. Jedna czerwona metryka psuje cały URL.
• Średnia kłamie. Jeśli optymalizujesz pod średni czas, możesz „poprawić" wynik, nie ruszając tych najwolniejszych odsłon, które realnie decydują o ocenie.

Dlatego dane z jednego uruchomienia Lighthouse mówią Ci, czy problem istnieje, ale dopiero rozkład odsłon na p75 mówi, czy Google uzna stronę za szybką.

LCP (Largest Contentful Paint): jak poprawić czas ładowania?

LCP mierzy czas, po którym największy widoczny element strony zostaje wyrenderowany, czyli może to być główny obrazek, nagłówek hero, blok tekstu lub jakieś wideo. Google oczekuje, że LCP powinien nastąpić w ciągu 2,5 sekundy od rozpoczęcia ładowania - jest to aktualny standard, który może się też zmienić w przyszłości.

Co wpływa na LCP strony?

• Czas odpowiedzi serwera (TTFB)
• Blokujący JavaScript i CSS
• Czas ładowania zasobów (obrazy, fonty)
• Client-side rendering

Cztery fazy LCP przed optymalizacją

Większość poradników każe „zoptymalizować obrazek hero" i na tym kończy. Problem w tym, że LCP to suma czterech następujących po sobie faz — i dopóki nie wiesz, która z nich zjada czas, strzelasz na ślepo:

1. TTFB — czas do pierwszego bajtu odpowiedzi serwera. Jeśli to jest wąskie gardło, kompresja obrazka nic nie da; szukaj w CDN, cache'u i renderowaniu po stronie serwera.
2. Resource load delay — odstęp między TTFB a momentem, w którym przeglądarka zaczyna pobierać element LCP. Duża wartość zwykle znaczy, że zasób jest odkrywany za późno (np. obraz wstawiany przez JS albo CSS) — to przypadek dla preload.
3. Resource load time — ile trwa samo pobranie elementu LCP. Tu pomaga właściwy format (WebP/AVIF), rozmiar i kompresja.
4. Element render delay — czas między pobraniem zasobu a jego wyrenderowaniem. Najczęstszy winowajca to render-blocking CSS/JS albo czekanie na hydration.

Idealnie pierwsze dwie fazy (TTFB + load delay) powinny zająć mniej niż ~40% całego LCP. Jeśli zajmują więcej, problem leży po stronie serwera i kolejności ładowania, a nie samego obrazka. Ten rozkład odczytasz w PageSpeed Insights (sekcja „LCP image element" → „Phases") albo w panelu Performance w Chrome DevTools.

Jak poprawić LCP w praktyce?

1. Optymalizuj obrazy, ponieważ jest to najczęstsza przyczyna słabego LCP, której zmiana jest najłatwiejsza technicznie do wdrożenia (choć może być też przy tym dość czasochłonna). Używaj nowoczesnych formatów, takich jak WebP lub AVIF, odpowiednich rozmiarów i lazy loadingu dla obrazów poniżej fold.

// Next.js — automatyczna optymalizacja z priorytetem dla hero image
import Image from 'next/image'
;<Image
  src="/hero.jpg"
  alt="Hero image"
  width={1200}
  height={600}
  priority // wyłącza lazy loading, ładuje natychmiast
/>

priority ma sens tylko dla zasobu, który faktycznie jest kandydatem na LCP, a jeśli oznaczysz w ten sposób pół strony, rozmyjesz priorytety ładowania zamiast je poprawić.

2. Użyj Server-Side Rendering lub Static Generation — strona renderowana na serwerze jest gotowa do wyświetlenia od razu, bez czekania na JavaScript. Next.js jest tu świetnym wyborem pod SEO.

3. Preloaduj krytyczne zasoby, czyli fonty, główne obrazy i style powinny ładować się jak najwcześniej.

<link
  rel="preload"
  href="/fonts/inter.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>
<!-- Dla prostego obrazu (nie-responsywnego): -->
<link rel="preload" href="/hero.webp" as="image" />
 
<!-- Dla obrazu responsywnego z srcset: -->
<link
  rel="preload"
  as="image"
  imagesrcset="/hero-480.webp 480w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  imagesizes="(max-width: 600px) 480px, (max-width: 1000px) 800px, 1200px"
/>

4. Zminimalizuj blokujący CSS i JS — krytyczne zasoby powinny dojść szybko, a cała reszta nie powinna blokować renderowania ponad potrzebę.

W praktyce najczęstszym winowajcą słabego LCP są nieskompresowane obrazy hero, wolny TTFB i zbyt ciężki start aplikacji po stronie klienta. Często poprawa nie wymaga magii, tylko uporządkowania kolejności ładowania.

INP (Interaction to Next Paint): jak poprawić interaktywność?

INP zastąpił wcześniejszą metrykę FID (First Input Delay) w marcu 2024 roku. Mierzy czas od interakcji użytkownika (kliknięcie, tap, naciśnięcie klawisza) do momentu, gdy przeglądarka wyrenderuje wizualną odpowiedź.

Dobry wynik INP to wynik poniżej 200 milisekund, a wszystko powyżej 500ms jest uznawane za słabe.

Co wpływa na INP strony?

1. Ciężki JavaScript blokujący główny wątek.
2. Długie zadania (long tasks) powyżej 50ms.
3. Zbyt wiele event listenerów.
4. Nieoptymalny kod w handlerach zdarzeń.

Jak poprawić INP w praktyce?

1. Rozbij długie zadania w sytuacji, kiedy JavaScript wykonuje się dłużej niż 50ms blokując w ten sposób główny wątek. Poza tym, podziel pracę na mniejsze fragmenty, przenoś cięższe rzeczy do Web Workera albo odraczaj to, co nie jest krytyczne dla interakcji.

// Zamiast jednej długiej operacji blokującej UI
async function processLargeArray(items) {
  const chunk = 100
 
  for (let index = 0; index < items.length; index += chunk) {
    const end = Math.min(index + chunk, items.length)
    for (let i = index; i < end; i++) {
      // przetwarzaj element
    }
 
    // Oddaj sterowanie przeglądarce między porcjami
    if ('scheduler' in globalThis && 'yield' in scheduler) {
      await scheduler.yield() // Chrome 115+, preferowane dla INP
    } else {
      await new Promise((resolve) => setTimeout(resolve, 0)) // fallback
    }
  }
}

2. Używaj code splitting, czyli innymi słowy, nie ładuj całej aplikacji na raz. Next.js robi to automatycznie dla każdej strony.

3. Unikaj hydration mismatch — w aplikacjach SSR różnice między serwerem a klientem wymuszają ponowne renderowanie.

4. Debounce i throttle — dla często wywoływanych handlerów (scroll, resize, input) ogranicz częstotliwość wykonywania, ale nie opóźniaj informacji zwrotnej tam, gdzie użytkownik oczekuje natychmiastowej reakcji po kliknięciu.

// Debounce dla wyszukiwarki
const handleSearch = debounce((query) => {
  fetchResults(query)
}, 300)

INP najczęściej daje się we znaki w aplikacjach z ciężkim JavaScriptem, dużą ilością hydration, złożonym stanem albo handlerami, które robią zbyt wiele rzeczy naraz. Warto też dodać, że jest to metryka bardzo "frontendowa" i zwykle nie naprawisz jej samym CDN-em.

CLS (Cumulative Layout Shift): jak ograniczyć przesunięcia layoutu?

CLS mierzy sumę wszystkich nieoczekiwanych przesunięć layoutu podczas całego życia strony, a każdy element, który "skacze" po załadowaniu — przesuwając treść, którą użytkownik już widzi — pogarsza ten wynik.

Dobry CLS to poniżej 0,1. Wynik powyżej 0,25 jest problematyczny.

Co powoduje przesunięcia layoutu i wysoki CLS?

W grę wchodzi kilka rzeczy:

• Obrazy bez określonych wymiarów,
• Reklamy i embedy ładowane dynamicznie,
• Fonty powodujące FOUT,
• Treść wstrzykiwana dynamicznie nad istniejącą zawartość.

Jak poprawić CLS w praktyce?

1. Zawsze określaj wymiary obrazów i wideo

// Źle — brak wymiarów
<img src="/photo.jpg" alt="Zdjęcie" />
 
// Dobrze — zarezerwowane miejsce
<img src="/photo.jpg" alt="Zdjęcie" width={800} height={600} />
 
// Jeszcze lepiej — Next.js Image
<Image src="/photo.jpg" alt="Zdjęcie" width={800} height={600} />

Jeśli nie możesz podać stałych wymiarów, użyj przynajmniej aspect-ratio, by w ten sposób zarezerwować miejsce zanim zasób się załaduje. Nie jest to rozwiązanie optymalne, ale zawsze to będzie lepsze niż nic.

2. Rezerwuj miejsce na dynamiczną treść — jeśli ładujesz reklamy, embedy czy dane z API, określ minimalną wysokość kontenera.

.ad-container {
  min-height: 250px; /* typowy rozmiar reklamy */
}

3. Używaj font-display: swap z dopasowanym fallbackiem — sam swap nie wystarczy, jeśli fallback font ma inne metryki niż docelowy. Użyj size-adjust, ascent-override i descent-override, żeby dopasować proporcje i niemal wyeliminować layout shift przy zamianie fontów.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
}
 
/* Fallback z dopasowanymi metrykami — minimalizuje CLS przy FOUT */
@font-face {
  font-family: 'Inter-fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
}

Dokładne wartości size-adjust i override'ów zależą od konkretnych fontów — możesz je wyliczyć narzędziem Automatic font matching lub Font Style Matcher.

4. Unikaj wstrzykiwania treści nad widocznym obszarem — jeśli musisz dodać element dynamicznie, rób to poniżej aktualnego viewportu lub używaj animacji transform zamiast przesuwania layoutu przez top, margin czy zmianę wysokości.

W Next.js komponenty next/image i next/font rozwiązują większość problemów z CLS automatycznie. To jeden z powodów, dla których framework tak dobrze radzi sobie z Core Web Vitals.

CLS dostał też nowe uzasadnienie poza klasycznym UX. W eksperymentalnym audycie Przeglądanie Agentowe w Lighthouse stabilność układu jest jednym z sygnałów gotowości strony dla agentów AI. Jeśli element przesuwa się między momentem rozpoznania a kliknięciem, agent może trafić w zły przycisk albo źle zinterpretować interfejs. Ta sama poprawka — rezerwacja miejsca na obrazy, fonty i dynamiczne bloki — pomaga więc ludziom, Core Web Vitals i agentom.

Jak mierzyć Core Web Vitals na stronie?

Masz kilka narzędzi do wyboru, a każde z nich oferuje inną perspektywę.

Google Search Console, czyli dane z realnych użytkowników (field data), to najważniejsze źródło z perspektywy SEO i jakości doświadczenia. Must-have i to bez względu na wybór kolejnych z nich.

PageSpeed Insights, który łączy dane laboratoryjne i terenowe. Bardzo dobre do szybkiej diagnozy i rekomendacji.

Lighthouse (w Chrome DevTools) — dane laboratoryjne, czyli lab data, świetne do debugowania, ale nie zastępują danych z prawdziwych użytkowników.

Lighthouse zaczyna też wykraczać poza same Core Web Vitals. Kategoria Przeglądanie Agentowe nie daje wyniku 0–100 i nie jest rankingiem SEO, ale warto ją obserwować przy audytach technicznych, bo łączy stabilność layoutu, dostępność interfejsu i llms.txt w jednym raporcie.

Web Vitals Extension, czyli rozszerzenie Chrome pokazujące metryki w czasie rzeczywistym podczas przeglądania.

web-vitals library, czyli biblioteka JavaScript do zbierania metryk i wysyłania do własnej analityki.

import { onLCP, onINP, onCLS } from 'web-vitals'
 
onLCP(console.log)
onINP(console.log)
onCLS(console.log)

Najważniejsze rozróżnienie wygląda w ten sposób: lab data pomaga znaleźć problem, a field data pokazuje jego wpływ na użytkowników. Zacznij swoją pracę od Search Console, a potem użyj PageSpeed Insights do diagnozy, a Lighthouse do testowania hipotez i lokalnych poprawek.

RUM w Next.js i wysyłka Core Web Vitals do GA4

Jeśli samo Search Console to dla Ciebie za mało, możesz dołożyć Real User Monitoring i wysyłać Core Web Vitals z aplikacji Next.js do GA4. Największy ma to sens wtedy, gdy chcesz zobaczyć metryki per strona, urządzenie albo typ połączenia, zamiast czekać wyłącznie na zagregowane dane z 28-dniowego okna.

Najprostszy setup wygląda tak:

// components/WebVitals.tsx
'use client'
 
import { useEffect } from 'react'
import { onCLS, onINP, onLCP } from 'web-vitals'
 
function sendToGA4(name: string, value: number, rating?: string) {
  if (!window.gtag) return
 
  window.gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_rating: rating,
    non_interaction: true,
  })
}
 
export function WebVitals() {
  useEffect(() => {
    onLCP((metric) => sendToGA4('LCP', metric.value, metric.rating))
    onINP((metric) => sendToGA4('INP', metric.value, metric.rating))
    onCLS((metric) => sendToGA4('CLS', metric.value, metric.rating))
  }, [])
 
  return null
}

Takie podejście daje Ci tani punkt wejścia do RUM, ale warto znać jego granice:

• GA4 nadaje się do trendów, segmentacji i prostych eksploracji, nie do pełnej observability.
• Jeśli chcesz raportować dodatkowy kontekst, np. page_path, device_type albo connection_type, zarejestruj te parametry jako custom dimensions.
• Przy bardziej krytycznych aplikacjach lepsze będą dedykowane narzędzia typu Vercel Analytics, Sentry Performance albo SpeedCurve.

Jak znaleźć konkretny problem z Core Web Vitals?

Najczęstszy błąd to wszelkie próby optymalizacji na czuja. Zanim cokolwiek zmienisz, ustal dokładnie, który element i które ładowanie wpływają najbardziej na wynik.

Który element jest moim LCP? Otwórz Chrome DevTools → zakładka Performance → włącz nagrywanie z odświeżeniem strony. Na ścieżce „Timings" znajdziesz znacznik LCP — kliknięcie w niego podświetli w drzewie DOM konkretny element, który Google liczy jako największy. Często okazuje się, że to nie ten obrazek, który podejrzewałeś, tylko np. blok tekstu albo tło sekcji. Szybszy skrót: w konsoli odpalisz to jednym wywołaniem:

// Wypisuje element LCP w konsoli — uruchom po załadowaniu strony
new PerformanceObserver((list) => {
  const last = list.getEntries().at(-1)
  console.log(
    'LCP element:',
    last.element,
    '→',
    Math.round(last.startTime),
    'ms',
  )
}).observe({ type: 'largest-contentful-paint', buffered: true })

Skąd bierze się mój layout shift? W panelu Performance włącz „Layout Shift Regions" (Experience track) — DevTools podświetli na niebiesko każdy przesuwający się element wraz z jego udziałem w CLS. Dzięki temu nie zgadujesz, czy to font, reklama, czy późno ładowany baner.

Co blokuje główny wątek przy INP? W panelu Performance szukaj długich zadań (long tasks) — DevTools oznacza je czerwonym trójkątem w rogu. Nagraj interakcję (np. kliknięcie menu), znajdź najdłuższe zadanie między kliknięciem a kolejnym paintem i to ono jest Twoim INP.

Reguła jest prosta: najpierw zidentyfikuj winowajcę w field data (Search Console / CrUX), potem odtwórz go w lab data (DevTools) i dopiero wtedy zmieniaj kod. Optymalizacja bez tego kroku to zgadywanie.

Praktyczny workflow optymalizacji Core Web Vitals

Po latach pracy z wydajnością stron wypracowałem prosty proces:

1. Zmierz baseline — zapisz aktualne wyniki wszystkich trzech metryk, najlepiej osobno dla mobile i desktop. Z doświadczenia mogę powiedzieć, że zazwyczaj wyniki dla desktop są znacznie lepsze, a mobile ma problemy z wydajnością.

2. Zidentyfikuj najsłabsze ogniwo — zwykle jedna metryka jest znacznie gorsza od pozostałych i zacznij pracę właśnie od niej. Tutaj zysk będzie największy.

3. Wprowadź jedną zmianę naraz — inaczej nie będziesz wiedział, co tak naprawdę pomogło.

4. Testuj na throttled connection — w DevTools ustaw "Slow 3G" lub "Fast 3G", ponieważ Twoje łącze światłowodowe nie odzwierciedla doświadczeń większości użytkowników.

5. Poczekaj na dane terenowe — Search Console bazuje na 28-dniowym oknie danych i nie oczekuj, że poprawki z dziś będą jutro od razu widoczne jako "good URLs".

Najczęstsze problemy pomijane przy optymalizacji Core Web Vitals

Kilka mniej oczywistych punktów, które potrafią zauważalnie ruszyć wynik na p75, ale rzadko trafiają do poradników:

• bfcache (back/forward cache). Gdy przeglądarka może przywrócić stronę z pamięci przy cofnięciu, ładowanie jest natychmiastowe, a takie odsłony wpadają do CrUX z niemal zerowym LCP. Niepotrzebny nagłówek Cache-Control: no-store albo nieposprzątany handler unload blokują bfcache i po cichu pogarszają Twój rozkład. W DevTools sprawdzisz to w Application → Back/forward cache.
• INP mierzy najgorszą interakcję. W odróżnieniu od dawnego FID, INP bierze pod uwagę praktycznie najwolniejszą interakcję w całej sesji, czyli jedno ciężkie kliknięcie w menu czy filtr potrafi zepsuć całą metrykę, bez względu na zachowanie reszty strony.
• Animacje na width, height, top czy margin generują CLS i obciążają główny wątek. Animuj wyłącznie przez transform i opacity, właśnie te właściwości nie wywołują reflow.
• Third-party skrypty to częsty, ukryty winowajca INP i LCP. Czat, widżety, piksele marketingowe i testy A/B działają na Twoim głównym wątku. Ładuj je z async/defer, opóźniaj do pierwszej interakcji albo przenoś do Web Workera (np. Partytown).
• Soft navigations w SPA. W aplikacjach jednostronicowych przejścia bez pełnego przeładowania długo nie były mierzone tak jak klasyczne wejścia; Chrome dopiero domyka ten temat. Jeśli ruch trzymasz w obrębie jednej aplikacji, nie zakładaj, że każde przejście jest „darmowe" dla CWV.

Czy Core Web Vitals naprawdę wpływają na pozycję w Google?

Tak, ale to jeden z bardzo wielu czynników składającym się na pozycję strony w wynikach wyszukiwania. Google wielokrotnie podkreślało, że treść i trafność odpowiedzi są ważniejsze, a strona z idealnym CWV i treścią niskiej jakości, nie wyprzedzi wartościowego materiału tylko dlatego, że jest szybsza. To logiczne, bo dlaczego dla użytkownika miałoby być ważniejsze wczytanie szybciej treści, która jest nieprzydatna, myląca albo niskiej jakości? Jeśli strony mają porównywalną jakość treści, szybsza strona ma przewagę — nikt nie lubi czekać na ładowanie czy klikać w przycisk, który reaguje zbyt wolno. Żeby przełożyć te metryki na konkretne liczby dla interesariuszy, warto sięgnąć po artykuł o tym, ile naprawdę kosztuje sekunda opóźnienia ładowania strony — tam znajdziesz formuły i benchmarki do kalkulacji ROI z optymalizacji.

Twoja strona ma problemy z Core Web Vitals? Skontaktuj się ze mną — pomogę zdiagnozować przyczyny i wdrożyć optymalizacje, które przyniosą realne efekty.