Core Web Vitals to trzy metryki — LCP (Largest Contentful Paint), INP (Interaction to Next Paint) i CLS (Cumulative Layout Shift) — które mierzą odpowiednio: szybkość ładowania głównej treści strony, czas reakcji na interakcję użytkownika i stabilność wizualną (czy elementy strony „skaczą” podczas ładowania). Google potwierdza, że Core Web Vitals są czynnikiem rankingowym — nie dominującym (jakość treści nadal jest ważniejsza), ale przy dwóch stronach o porównywalnej treści, szybsza wygrywa.
Dlaczego to jest artykuł dla twórcy treści, a nie dla programisty? Bo większość problemów z Core Web Vitals na stronach contentowych wynika z decyzji edytorskich, nie z kodu: nieskompresowane zdjęcia o wadze 3 MB, osadzone filmy YouTube ładujące się przy wejściu, nieoptymalizowane infografiki, dwadzieścia fontów z Google Fonts. Programista może zoptymalizować infrastrukturę — ale jeśli Ty wrzucasz 5-megabajtowy obraz hero na każdy artykuł, żadna optymalizacja kodu tego nie naprawi.
Trzy metryki — co mierzą i jakie wartości są dobre
| Metryka | Co mierzy | Dobra | Wymaga poprawy | Słaba |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Czas ładowania największego elementu widocznego na ekranie (zwykle obraz hero lub nagłówek H1) | ≤2,5 sek. | 2,5–4 sek. | >4 sek. |
| INP (Interaction to Next Paint) | Czas reakcji strony na kliknięcie/dotknięcie użytkownika | ≤200 ms | 200–500 ms | >500 ms |
| CLS (Cumulative Layout Shift) | Ile elementów strony „przeskoczyło” w trakcie ładowania | ≤0,1 | 0,1–0,25 | >0,25 |
Według danych z 2025 roku, tylko 47–54% stron internetowych spełnia wszystkie trzy progi Core Web Vitals. To oznacza, że jeśli Twoja strona je spełnia — masz przewagę nad połową konkurencji, zanim jeszcze zacznie się porównywanie treści.
LCP — dlaczego Twój obraz hero to najczęstszy problem
LCP mierzy czas, po którym użytkownik widzi główną treść strony. W artykułach blogowych tym elementem jest zwykle obraz hero (główne zdjęcie artykułu) lub nagłówek H1 z otaczającym tekstem.
Najczęstszy scenariusz problemu: wrzucasz zdjęcie 4000×3000 pikseli, 2,5 MB, w formacie PNG, jako obraz hero. Przeglądarka musi pobrać 2,5 MB danych, zanim wyświetli artykuł. Na wolniejszym łączu mobilnym — 5–8 sekund. LCP: powyżej 4 sekund. Google ocenia: „słaba”.
Co twórca treści może z tym zrobić
Kompresuj obrazy przed uploadem. Nie polegaj na automatycznej kompresji CMS — sam skompresuj każdy obraz. Narzędzia: Squoosh (darmowe, online), TinyPNG, ImageOptim (macOS). Cel: obraz hero poniżej 200 KB, ideał to 50–100 KB.
Używaj formatu WebP lub AVIF. WebP jest o 25–35% lżejszy niż JPEG przy tej samej jakości. AVIF jest jeszcze lżejszy, ale wsparcie przeglądarek jest węższe. Jeśli Twój CMS obsługuje WebP (WordPress z wtyczkami, Astro natywnie) — konwertuj wszystkie obrazy.
Dostosuj wymiary do wyświetlania. Jeśli obraz hero na stronie ma 800×450 pikseli — nie uploaduj obrazu 4000×3000. Przeskaluj do 1600×900 (2× dla ekranów retina) przed uploadem. Mniejsze wymiary = mniejszy plik = szybsze ładowanie.
Ustaw atrybut loading="eager" na obrazie hero. Lazy loading (ładowanie leniwe) jest świetne dla obrazów poniżej widoku ekranu — ale obraz hero musi ładować się natychmiast. Upewnij się, że Twój CMS nie nakłada lazy loading na obraz widoczny od razu.
Rozważ rezygnację z obrazu hero. Kontrowersyjne, ale warte rozważenia: czy Twój artykuł naprawdę potrzebuje dekoracyjnego obrazu stockowego na górze? Jeśli obraz nie niesie wartości informacyjnej — usunięcie go drastycznie poprawia LCP. Niektóre z najlepiej rankujących stron contentowych nie mają obrazów hero.
CLS — niestabilność wizualna i jej edytorskie przyczyny
CLS mierzy, jak bardzo elementy strony „przesuwają się” podczas ładowania. Efekt, który wszyscy znamy: zaczynasz czytać artykuł, nagle ładuje się reklama i tekst skacze o 200 pikseli w dół. Albo: klikasz link, ale w ostatniej chwili ładuje się obraz i klikasz w coś innego. To CLS.
Edytorskie przyczyny wysokiego CLS
Obrazy bez zdefiniowanych wymiarów. Jeśli w HTML obraz nie ma atrybutów width i height, przeglądarka nie wie, ile miejsca zarezerwować — wyświetla tekst, potem ładuje obraz i przesuwa tekst w dół. Rozwiązanie: zawsze definiuj wymiary obrazów (albo używaj CSS aspect-ratio).
Osadzenia zewnętrzne bez kontenera. Osadzasz wideo z YouTube, tweet z X, mapę Google — a te elementy ładują się asynchronicznie i przesuwają treść. Rozwiązanie: umieszczaj osadzenia w kontenerze o zdefiniowanej wysokości (np. min-height: 400px), żeby przeglądarka zarezerwowała miejsce.
Czcionki ładowane z opóźnieniem. Strona ładuje tekst w czcionce systemowej, potem po 1–2 sekundach podmienia na czcionkę z Google Fonts — tekst zmienia rozmiar i wszystko skacze. Rozwiązanie: używaj font-display: swap i ustaw czcionki zastępcze o podobnych proporcjach (skonsultuj z programistą — ale bądź świadomy, że każda kolejna czcionka dodana do strony ma koszt).
Dynamicznie ładowane elementy (cookie baner, pop-up). Baner zgody na cookies, który pojawia się po 2 sekundach i przesuwa treść, to klasyczne źródło CLS. Rozwiązanie: baner powinien być nakładką (overlay), nie elementem wstawionym w treść strony.
INP — responsywność i interakcje
INP (od marca 2024 zastąpił FID) mierzy czas reakcji strony na interakcje użytkownika: kliknięcia, dotknięcia, pisanie w polach. Dla stron contentowych (artykuły, blogi) INP jest zwykle najmniej problematyczny — bo użytkownik głównie czyta, nie klika.
Kiedy INP staje się problemem na stronach contentowych: strona ma rozbudowane menu JavaScript, animowane spisy treści, interaktywne kalkulatory, osadzone aplikacje, formularze z walidacją w czasie rzeczywistym — i te skrypty blokują główny wątek przeglądarki.
Twoja rola jako twórcy treści: minimalizuj liczbę osadzeń i interaktywnych elementów na stronie. Każdy osadzony widget (kalkulator, ankieta, mapa interaktywna) dodaje JavaScript, który spowalnia reakcję strony. Nie oznacza to, że nie możesz ich używać — ale bądź świadomy kosztu i używaj ich celowo, nie „bo fajnie wygląda”.
Jak sprawdzić Core Web Vitals swojej strony
Trzy narzędzia, w kolejności od najprostszego:
Google PageSpeed Insights (pagespeed.web.dev). Wpisujesz URL, dostajesz wyniki CWV na mobile i desktop + listę rekomendacji. Dane pochodzą z dwóch źródeł: laboratoryjnych (symulacja) i terenowych (rzeczywiste dane od użytkowników Chrome). Dane terenowe są ważniejsze — to na nich Google bazuje w rankingu.
Google Search Console (sekcja „Podstawowe wskaźniki internetowe”). Zbiorczy raport dla całej witryny: ile URL-i ma dobre, wymagające poprawy i słabe CWV. Najważniejszy raport do monitorowania — pokazuje problem systemowy (np. „67% stron mobilnych ma zły LCP”), nie tylko jednostkowe.
Chrome DevTools (zakładka Performance / Lighthouse). Dla bardziej zaawansowanych: pozwala zidentyfikować dokładnie, który element powoduje problem (np. który obraz blokuje LCP). Użyteczne przy diagnozowaniu konkretnych stron.
Praktyczna checklist CWV dla twórcy treści
Nie musisz rozumieć CDN, prefetch ani service workers. Oto lista działań, które masz pod kontrolą jako osoba publikująca treść:
Przed publikacją każdego artykułu:
- Obraz hero: format WebP, waga <200 KB, wymiary dopasowane do wyświetlania
- Pozostałe obrazy: format WebP, waga <150 KB każdy, lazy loading włączony
- Alt texty: opisowe, z frazą kluczową gdzie naturalnie
- Osadzenia (YouTube, Twitter): sprawdzone, że nie przesuwają treści
- Liczba osadzonych elementów: ≤3 na artykuł (każdy dodatkowy spowalnia stronę)
- Czcionki: nie dodawaj nowych czcionek do artykułu (jeśli CMS to umożliwia — nie korzystaj)
Raz na kwartał:
- Sprawdź zbiorczy raport CWV w Google Search Console
- Jeśli >20% URL-i ma zły LCP → skonsultuj z programistą (problem systemowy)
- Jeśli konkretne artykuły mają zły CLS → sprawdź osadzenia i obrazy bez wymiarów
- Przetestuj 5 najważniejszych stron w PageSpeed Insights na mobile
Obrazy — największy wpływ twórcy treści na szybkość strony
Obrazy odpowiadają za 50–70% wagi stron contentowych. Optymalizacja obrazów to jednorazowa inwestycja w nawyk, która daje trwałe efekty.
| Co robić | Dlaczego | Jak |
|---|---|---|
| Konwertuj do WebP | 25–35% mniejszy plik niż JPEG | Squoosh, CMS plugin, skrypt buildowy |
| Kompresuj do 80% jakości | Różnica wizualna niedostrzegalna, rozmiar spada o 40–60% | Squoosh (quality slider), TinyPNG |
| Dopasuj wymiary | Obraz 4000px na kontener 800px to marnotrawstwo | Przeskaluj przed uploadem |
| Ustaw lazy loading | Obrazy poza ekranem ładują się dopiero gdy użytkownik do nich przewinie | loading="lazy" w HTML |
| Definiuj wymiary | Zapobiega CLS | Atrybuty width i height |
Używaj <picture> z srcset | Serwuj mniejsze obrazy na mobilkach | Automatyczne w Astro, Next.js; wymagają konfiguracji w WordPress |
Kiedy szybkość strony NIE jest Twoim problemem
Perspektywa: Core Web Vitals są czynnikiem rankingowym, ale jednym z setek. Jeśli Twoja treść jest kiepska, żadna szybkość jej nie uratuje. Jeśli Twoja treść jest świetna, a strona ładuje się 3,5 sekundy zamiast 2 — nadal możesz rankować dobrze.
CWV mają największy wpływ, gdy: (a) konkurujesz z artykułami o porównywalnej jakości i (b) Twoja strona jest wyraźnie wolniejsza niż konkurencja. Jeśli Twoja strona jest porównywalnie szybka — różnica nie przekłada się na pozycje.
Praktyczna implikacja: nie spędzaj 20 godzin na optymalizacji CWV kosztem pisania kolejnego artykułu. Najpierw zoptymalizuj obrazy (1 godzina, 80% efektu), potem skonsultuj resztę z programistą. Twój czas jest lepiej spożytkowany na treści niż na debugowanie JavaScriptu.
FAQ
Czy wolna strona oznacza, że nie wejdę do top 10?
Nie — jakość treści jest nadal ważniejszym czynnikiem niż szybkość. Istnieją strony z kiepskim LCP (3–4 sek.), które rankują w top 5, bo ich treść jest nieporównywalnie lepsza od konkurencji. Ale przy równej jakości — szybsza strona wygrywa. Traktuj CWV jako czynnik przełamujący remis, nie decydujący o wszystkim.
Jak bardzo optymalizacja CWV wpływa na konwersje?
Badania wskazują, że poprawa CWV z „wymagających poprawy” do „dobrych” koreluje z ok. 25% wzrostem współczynnika konwersji. To nie tylko efekt SEO — to efekt UX: szybsza strona = mniej użytkowników, którzy się niecierpliwią i wychodzą.
Czy lazy loading szkodzi SEO?
Nie — Google potwierdza, że prawidłowo wdrożony lazy loading (z atrybutem loading="lazy" na natywnych elementach <img>) nie powoduje problemów z indeksowaniem. Google renderuje strony i widzi obrazy z lazy loading. Ale: nie stosuj lazy loading na obrazie LCP (hero) — to opóźni ładowanie najważniejszego elementu.
Czy powinienem usuwać obrazy ze starych artykułów, żeby przyspieszyć stronę?
Nie usuwaj — zoptymalizuj. Przejdź przez stare artykuły, skompresuj i skonwertuj obrazy do WebP, dopasuj wymiary. To daje ten sam efekt na szybkość bez utraty wartości wizualnej. Usuwaj tylko obrazy czysto dekoracyjne, które nie wnoszą informacji (stockowe zdjęcia kwiatów w artykule o SEO).
Jak często sprawdzać Core Web Vitals?
Zbiorczy raport w GSC: raz na kwartał. PageSpeed Insights dla nowych artykułów: przy publikacji kluczowych treści (strona filarowa, landing page). Nie testuj każdego artykułu — jeśli szablon strony jest zoptymalizowany, CWV będą spójne na wszystkich stronach z tego szablonu.
