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

Google od wielu lat podkreśla, że wydajność i doświadczenie użytkownika mają znaczenie i Core Web VitalsCore Web Vitals to zestaw metryk Google oceniających szybkość, responsywność i stabilność wizualną strony. są częścią sygnałów page experience, ale najważniejsze jest to, że wreszcie mierzą coś bardzo konkretnego: czy strona szybko pokazuje treść, czy reaguje na interakcje i czy nie "skacze" podczas ładowania.

To ważne nie tylko z perspektywy SEOSEO, czyli Search Engine Optimization, to optymalizacja strony pod widoczność w wynikach wyszukiwania., ale po prostu jakości produktu. Szybsza i stabilniejsza strona daje lepszą konwersję, mniejszą frustrację i mniej problemów na słabszych urządzeniach.

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

Krótka odpowiedź: LCPLCP, czyli Largest Contentful Paint, mierzy czas wyrenderowania największego widocznego elementu na ekranie. < 2,5 s (czas ładowania głównej treści), INPINP, czyli Interaction to Next Paint, mierzy jak szybko interfejs reaguje po interakcji użytkownika. < 200 ms (responsywność interakcji), CLSCLS, czyli Cumulative Layout Shift, mierzy nieoczekiwane przesunięcia elementów podczas ładowania strony. < 0,1 (stabilność layoutu). Najczęstsze spotykane problemy to: nieskompresowane obrazy hero (LCP), bardzo ciężki JavaScript (INP), obrazy bez wymiarów (CLS). Mierz to przede wszystkim w Google Search Console, a jeśli chcesz zejść poziom niżej w projektach Next.js, dołóż Real User Monitoring przez GA4 albo inne narzędzie RUM.

Czym są Core Web Vitals?

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) — jak szybko ładuje się główna treść strony,

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

CLS (Cumulative Layout Shift) — 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.

LCP — Largest Contentful Paint

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?

• Czas odpowiedzi serwera (TTFBTTFB, czyli Time to First Byte, mierzy czas od wysłania żądania do odebrania pierwszego bajtu odpowiedzi.)
• Blokujący JavaScript i CSS
• Czas ładowania zasobów (obrazy, fonty)
• Client-side rendering

Jak poprawić LCP?

1. Optymalizuj obrazy — to najczęstsza przyczyna słabego LCP. Używaj nowoczesnych formatów (WebP, 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. Jeśli oznaczysz w ten sposób pół strony, rozmyjesz priorytety ładowania zamiast je poprawić.

2. Użyj Server-Side RenderingServer-Side Rendering oznacza generowanie HTML na serwerze przed wysłaniem odpowiedzi do przeglądarki. 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 — 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

INP zastąpił wcześniejszą metrykę FIDFID, czyli First Input Delay, mierzył opóźnienie między pierwszą interakcją użytkownika a rozpoczęciem jej obsługi przez przeglądarkę. (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 poniżej 200 milisekund. Wszystko powyżej 500ms jest uznawane za słabe.

Co wpływa na INP?

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

Jak poprawić INP?

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. Dziel pracę na mniejsze fragmenty, przenoś cięższe rzeczy do Web WorkeraWeb Worker to mechanizm uruchamiania JavaScriptu w osobnym wątku, poza głównym wątkiem odpowiedzialnym za interfejs. 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 splittingCode splitting polega na dzieleniu kodu aplikacji na mniejsze paczki ładowane tylko tam, gdzie są potrzebne. — nie ładuj całej aplikacji na raz. Next.js robi to automatycznie dla każdej strony.

3. Unikaj hydration mismatchHydration mismatch to rozjazd między HTML-em wygenerowanym na serwerze, a tym, co React próbuje odtworzyć po stronie klienta. — 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 naraz. Warto też dodać, że jest to metryka bardzo "frontendowa" i zwykle nie naprawisz jej samym CDN-em.

CLS — Cumulative Layout Shift

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?

W grę wchodzi kilka rzeczy:

• Obrazy bez określonych wymiarów,
• Reklamy i embedy ładowane dynamicznie,
• Fonty powodujące FOUTFOUT, czyli Flash of Unstyled Text, oznacza chwilowe wyświetlenie tekstu w foncie zapasowym zanim załaduje się docelowy font.,
• Treść wstrzykiwana dynamicznie nad istniejącą zawartość.

Jak poprawić CLS?

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. 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.

Jak mierzyć Core Web Vitals?

Masz kilka narzędzi do wyboru, każde z inną perspektywą:

Google Search Console — dane z realnych użytkowników (field dataField data to dane zbierane od prawdziwych użytkowników w realnych warunkach korzystania ze strony.), to najważniejsze źródło z perspektywy SEO i jakości doświadczenia.

PageSpeed Insights — łączy dane laboratoryjne i terenowe i jest to wartościowe dobre do szybkiej diagnozy i rekomendacji.

Lighthouse (w Chrome DevTools) — dane laboratoryjne, czyli lab dataLab data to dane z testów symulowanych w kontrolowanych warunkach, a nie z rzeczywistych wizyt użytkowników.. Świetne do debugowania, ale nie zastępują danych z prawdziwych użytkowników.

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

web-vitals library — 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 tak, że lab data pomaga znaleźć problem, field data mówi, czy użytkownicy naprawdę go odczuwają. Zacznij swoją pracę od Search Console, potem użyj PageSpeed Insights do diagnozy, a Lighthouse do testowania hipotez i lokalnych poprawek.

RUM w Next.js i wysyłka 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. To ma 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.

Praktyczny workflow optymalizacji

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 danyc i nie oczekuj, że poprawki z dziś będą jutro od razu widoczne jako "good URLs".

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

Tak, ale to jeden z wielu czynników składającym się na pozycję strony. Google wielokrotnie podkreślało, że treść i trafność odpowiedzi są ważniejsze, a strona z idealnym CWV i słabą treś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? Oczywiście przy porównywalnej jakości treści, szybsza strona ma przewagę — nikt nie lubi czekać na ładowanie czy klikać w przycisk, który nie reaguje.

FAQ

Co to są Core Web Vitals i dlaczego mają znaczenie?

Core Web Vitals to trzy metryki Google mierzące jakość doświadczenia użytkownika: LCP (czas ładowania głównej treści), INP (responsywność na interakcje) i CLS (stabilność layoutu). Mają znaczenie z dwóch powodów, po pierwsze, są oficjalnym sygnałem rankingowym Google (Page Experience), a po drugie mierzą coś realnego — szybkość, responsywność i stabilność strony. Słabe wyniki CWV często korelują z niższą konwersją i wyższym bounce rate, niezależnie od SEO.

Jak poprawić LCP (Largest Contentful Paint)?

LCP dotyczy czasu renderowania największego widocznego elementu i jest to zazwyczaj hero image lub nagłówek strony. Najskuteczniejsz to (1) optymalizacja obrazu hero — WebP/AVIF, prawidłowy rozmiar, priority w next/image; (2) preload krytycznych zasobów — <link rel="preload">; (3) szybki TTFB serwera — CDN, SSG/ISR zamiast SSR gdzie to możliwe; (4) eliminacja render-blocking CSS i JS. Pamiętaj: nieskompresowany obraz hero to najczęstsza przyczyna złego LCP.

Co to jest INP i jak go poprawić?

INP (Interaction to Next Paint) zastąpił FID w marcu 2024. Mierzy czas od interakcji użytkownika (kliknięcie, tap) do widocznej odpowiedzi przeglądarki. Cel: poniżej 200ms. Głównymi przyczynami słabego INP są: długie zadania JavaScript (powyżej 50ms) blokujące główny wątek, hydration w aplikacjach SSR oraz ciężkie handlery zdarzeń. Rozwiązaniami są code splitting, Web Workers dla ciężkich obliczeń, debounce oraz lazy loading komponentów.

Jak naprawić CLS (Cumulative Layout Shift)?

CLS mierzy niespodziewane przesunięcia elementów podczas ładowania. Cel: poniżej 0,1. Główne przyczyny: obrazy bez wymiarów (width i height), dynamicznie ładowane reklamy i embedy bez zarezerwowanego miejsca, fonty powodujące FOUT. Rozwiązania: zawsze podawaj wymiary obrazów, rezerwuj miejsce na dynamiczną treść przez min-height, używaj font-display: swap z podobnym fallback fontem. Next.js next/image i next/font rozwiązują większość problemów automatycznie.

Jakie narzędzia do mierzenia Core Web Vitals?

Kluczowym rozróżnieniem jest field data (dane z realnych użytkowników) kontra lab data (symulacja). Google Search Console — field data z 28-dniowego okna, najważniejsze dla SEO. PageSpeed Insights — łączy field data z lab data i daje rekomendacje. Lighthouse w Chrome DevTools — lab data, świetne do debugowania lokalnie, a web-vitals library do zbierania metryki w swojej analityce. Zaczynaj od Search Console, a Lighthouse używaj do testowania swoich hipotez.

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

Tak, ale są jednym z wielu czynników, ponieważ Google wyraźnie podkreśla, że treść i trafność odpowiedzi na zapytanie są ważniejsze — strona z idealnym CWV i słabą treścią nie wyprzedzi wartościowego artykułu. CWV mają znaczenie przy porównywalnej jakości treści i częściej wpływają na doświadczenie użytkownika niż bezpośrednio na rankingi. Praktycznie: poprawa CWV często przekłada się na lepszą konwersję, niezależnie od efektu SEO.

Jak Next.js pomaga z Core Web Vitals?

Next.js ma wbudowane optymalizacje dla wszystkich trzech metryk: next/image automatycznie konwertuje do WebP/AVIF, implementuje lazy loading i rezerwuje miejsce (eliminuje LCP i CLS problemy). next/font eliminuje FOUT i CLS z fontów, a automatyczny code splitting redukuje JS blokujący główny wątek (INP). Pozostaje jeszcze SSG i ISR, które dają szybki TTFB. Migracja na Next.js z klasycznego Reacta regularnie przekłada się na wyraźny skok z żółtych do zielonych wyników PageSpeed. W wypadku technical SEO Next.js > React i tyle.

Źródła i dokumentacja

• web.dev: Defining Core Web Vitals thresholds
• web.dev: Web Vitals
• web.dev: Core Web Vitals workflows with Google tools
• Next.js: Image Optimization

Podsumowanie

Core Web Vitals to nie kolejna moda w SEO, ale bardzo użyteczny skrót myślowy dla jakości interfejsu na Twojej stronie:

• LCP pokazuje, czy główna treść pojawia się odpowiednio szybko,
• INP sprawdza, czy interakcje są responsywne,
• CLS pilnuje, żeby layout nie zachowywał się chaotycznie.

Najlepsze efekty pojawiają się wtedy, gdy patrzysz na te metryki nie jak na „SEO checklistę”, tylko jak na wspólny język między frontendem, designem, backendem i biznesem. Szybsza i stabilniejsza strona może pomóc w rankingach, ale przede wszystkim przekłada się na wyższą konwersję i lepsze doświadczenie użytkownika — bo o to w tym wszystkim chodzi. Patrzmy na szeroko pojęty interes użytkownika i bądźmy czujni na to czego może oczekiwać od strony - i od treści, i od rozwiązań technicznych.

Jeśli chcesz szybko sprawdzić, jak Twoja strona wypada w tych kategoriach, skorzystaj na początek z narzędzia PageSpeed Insights.

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