W skrócie: Core Web Vitals to trzy wskaźniki Google mierzące doświadczenie użytkownika. Są to LCP (wczytanie głównej treści, cel < 2,5 s), INP (reakcja na interakcje, cel < 200 ms) i CLS (stabilność układu, cel < 0,1). Wpływają na pozycje w wyszukiwarce, a każda sekunda opóźnienia mierzalnie obniża konwersję. Szybkość to funkcja sprzedaży, nie kosmetyka.
Spis treści
Krótka odpowiedź
Core Web Vitals to trzy mierniki, którymi Google ocenia, jak strona czuje się dla użytkownika: LCP (jak szybko widać główną treść; cel < 2,5 s), INP (jak szybko strona reaguje na kliknięcia; cel < 200 ms) i CLS (czy układ nie skacze; cel < 0,1). Słabe wyniki kosztują podwójnie: pozycje w wyszukiwarce i porzucenia już po wejściu.
Szybkość to pieniądze, dosłownie
Badania branżowe od lat pokazują tę samą zależność: wydłużenie ładowania o sekundę obniża konwersję o kilka–kilkanaście procent; znaczna część użytkowników mobilnych porzuca strony ładujące się dłużej niż ~3 sekundy. Mechanizm jest prozaiczny: czekanie boli, a konkurencja jest o jedno kliknięcie wstecz.
Działa też próg psychologiczny zaufania: strona, która zacina się i skacze, zostawia wrażenie, że „tu nikt nie dba o szczegóły". To fatalny komunikat, gdy prosisz o dane karty albo zapytanie ofertowe.
Trzy wskaźniki po ludzku
LCP (Largest Contentful Paint): czas do wyświetlenia największego elementu w oknie (zwykle zdjęcie hero albo nagłówek). To moment, w którym użytkownik czuje „strona jest". Najczęstsi winowajcy: ciężkie obrazy, wolny serwer, blokujące render skrypty i fonty.
INP (Interaction to Next Paint): opóźnienie między interakcją (klik, wpisanie znaku) a reakcją ekranu. Mierzy, jak bardzo strona się zacina. Winowajca niemal zawsze jeden: za dużo JavaScriptu wykonującego się na głównym wątku.
CLS (Cumulative Layout Shift): suma przeskoków układu. Znasz to: celujesz w przycisk, a treść zjeżdża, bo doładował się banner. Winowajcy: obrazy bez zadeklarowanych wymiarów, wstrzykiwane reklamy i komunikaty, fonty podmieniające się z przeskokiem.
Co realnie poprawia wyniki
- Obrazy: formaty AVIF/WebP, rozmiary dopasowane do ekranu (
srcset), lazy-loading poniżej pierwszego ekranu, zawsze z atrybutami wymiarów (to leczy też CLS). - JavaScript: mniej. Audyt skryptów firm trzecich (czaty, piksele, mapy – każdy kosztuje), ładowanie odroczone, architektura serwująca HTML zamiast renderowania wszystkiego w przeglądarce.
- Fonty: self-hosting,
font-display: swap, ograniczenie liczby odmian. - Serwer i CDN: szybki hosting, cache, serwowanie z lokalizacji bliskiej użytkownikowi.
- Architektura: najwięcej daje decyzja fundamentalna: strony statyczne lub prerenderowane (np. Astro) startują z wynikami, o które klasyczne CMS-y muszą walczyć wtyczkami. Ta strona jest tego przykładem, z zielonymi Core Web Vitals z projektu, nie z łatania.
Od czego zacząć
Zmierz (PageSpeed Insights + Search Console), napraw w kolejności wpływu (zwykle: obrazy → skrypty zewnętrzne → fonty → serwer), zmierz ponownie. A przy budowie nowej strony postaw wymóg w briefie: „komplet zielonych Core Web Vitals na mobile" wraz z zapisem o tym w umowie. Tańsze niż naprawianie po fakcie.
Budujemy strony, w których wydajność jest częścią projektu od pierwszego dnia. Zobacz, jak pracujemy.