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

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 VitalsCore Web Vitals to zestaw metryk Google oceniających realne doświadczenie użytkownika: LCP (szybkość ładowania), INP (responsywność) i CLS (stabilność wizualna). Wpływają na ranking i konwersję., jak je mierzyć i jak podchodzić do optymalizacji w praktyce.

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 żądania do otrzymania pierwszego bajtu odpowiedzi z serwera.)
• 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 osobny wątek przeglądarki, w którym możesz wykonywać kosztowne obliczenia bez blokowania głównego wątku odpowiedzialnego za interfejs. Komunikacja odbywa się przez wiadomości. 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 to dzielenie kodu aplikacji na mniejsze paczki ładowane na żądanie, zamiast jednego wielkiego pliku. Next.js robi to automatycznie per trasa, więc użytkownik pobiera tylko kod potrzebny dla strony, którą faktycznie odwiedza. — 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 wygenerowanym na serwerze a tym, co React próbuje wyrenderować na kliencie podczas hydratacji. Gdy drzewa się nie zgadzają, React zgłasza błąd, a w skrajnych przypadkach renderuje fragment od nowa 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 (Flash of Unstyled Text) to moment, w którym tekst najpierw wyświetla się w foncie systemowym, a po doczytaniu fontu webowego przeskakuje na docelowy krój. Widoczne mignięcie pogarsza odbiór strony.,
• 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.

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