Core Web Vitals i obrazki — jak zoptymalizować LCP w 2026?
Od maja 2021 roku Google oficjalnie uwzględnia Core Web Vitals w algorytmie rankingowym. W praktyce oznacza to, że wolna strona — szczególnie z wolnym LCP — może tracić pozycje na rzecz szybszych konkurentów. I tu właśnie pojawia się jeden z największych winowajców: obrazki w złych formatach i nieodpowiednich rozmiarach. Dowiedz się, jak to naprawić.
Co to są Core Web Vitals?
Core Web Vitals to zestaw trzech metryk wydajności strony, które Google uznaje za kluczowe wskaźniki doświadczenia użytkownika (User Experience). Wszystkie trzy są mierzone w warunkach rzeczywistych (field data) z Chrome UX Report i wpływają na ranking wyszukiwarki:
Spośród tych trzech metryk obrazki mają bezpośredni wpływ na LCP i CLS. INP związany jest głównie z JavaScript. Skupmy się więc na tym, jak właściwa optymalizacja obrazków może zadecydować o sukcesie lub porażce Twojej strony w wynikach wyszukiwania.
Jak obrazki wpływają na LCP?
LCP (Largest Contentful Paint) mierzy, kiedy na ekranie pojawia się największy element. W ponad 70% przypadków tym elementem jest obrazek — najczęściej główny baner strony, zdjęcie produktu lub hero image bloga. Czas do załadowania tego obrazka to w dużej mierze Twój wynik LCP.
Ścieżka krytyczna LCP wygląda następująco: przeglądarka pobiera HTML → parsuje go → odkrywa URL obrazka LCP → wysyła request → pobiera plik → renderuje go. Każdy etap może być bottleneckiem. Optymalizacja formatu obrazka zmniejsza czas pobierania — który jest zazwyczaj dominującym elementem całego LCP.
Konkretna matematyka: obrazek JPEG 800×600 px wagi 300 KB przy połączeniu 10 Mbit/s zajmie ~240 ms do pobrania. Ten sam obrazek w WebP waży ~200 KB (160 ms), a w AVIF ~150 KB (120 ms). To oszczędność 80–120 ms tylko na pobraniu jednego pliku. Przy słabszych połączeniach mobilnych różnice są wielokrotnie większe.
Pamiętaj: LCP jest mierzony z danych rzeczywistych użytkowników (głównie na urządzeniach mobilnych z wolniejszym łączem). Test PageSpeed Insights w laboratorium może pokazywać dobry wynik, gdy dane polowe (CrUX) są słabe. Search Console pokaże Ci realne dane.
Progi LCP według Google
Google podzielił wyniki LCP na trzy kategorie. Dla Twojej pozycji w rankingu liczy się, jaki procent użytkowników uzyskuje wynik w każdej kategorii — cel to minimum 75% sesji z LCP "Dobry":
| Kategoria | Czas LCP | Wpływ na ranking | Ocena |
|---|---|---|---|
| Dobry | < 2,5 sekundy | Pozytywny sygnał rankingowy | Zielony |
| Wymaga poprawy | 2,5 — 4 sekundy | Neutralny, brak premii | Pomarańczowy |
| Słaby | > 4 sekundy | Negatywny sygnał rankingowy | Czerwony |
Co ważne, Google liczy wynik CWV na poziomie całej witryny — jeśli jedna kluczowa podstrona (np. strona główna lub kategoria produktów) ma słabe LCP, wpływa to na ocenę całej domeny. Warto więc priorytetyzować optymalizację stron o największym ruchu.
Jak sprawdzić LCP swojej strony?
Masz kilka narzędzi do dyspozycji — polecamy używać co najmniej dwóch, bo każde pokazuje nieco inną perspektywę:
Aby sprawdzić, czy problematyczne są właśnie obrazki (a nie serwer, czcionki lub CSS), użyj naszego skanera:
5 sposobów na poprawę LCP przez obrazki
Oto pięć konkretnych technik, z których każda samodzielnie może zmniejszyć LCP o dziesiątki lub setki milisekund. Stosowane razem mogą przesunąć stronę z czerwonego w zielony zakres.
-
Konwersja do WebP lub AVIFNajszybszy i najważniejszy krok. Zamiana JPEG na WebP zmniejsza rozmiar pliku o 25–35%, na AVIF nawet o 40–55%. Dla obrazka LCP wagi 500 KB konwersja do WebP daje ~160–175 KB oszczędności — co przy połączeniu 5 Mbit/s to 250–280 ms mniej oczekiwania. Na WordPressie wystarczy wtyczka ShortPixel lub Imagify.
-
Odpowiednie rozmiary z srcsetJeśli serwujesz obraz 1920×600 px na telefonie z ekranem 390 px, pobierasz 5× więcej danych niż potrzeba. Atrybut
srcsetpozwala zdefiniować kilka wersji obrazka, a przeglądarka wybierze najodpowiedniejszy rozmiar. WordPress generuje srcset automatycznie dla standardowych rozmiarów miniatur. -
Preload hero image (LCP element)Przeglądarka odkrywa obrazek LCP dopiero gdy parsuje HTML — a to może nastąpić dopiero po setkach ms. Dodanie tagu
<link rel="preload">w<head>każe przeglądarce pobrać obrazek jak najwcześniej, równolegle z parsowaniem strony. To jedna z najskuteczniejszych technik poprawy LCP. -
Lazy loading tylko poza foldem
loading="lazy"jest świetny dla obrazków poniżej linii scrollu — ale absolutnie nie dla obrazka LCP. Jeśli dodasz lazy loading do hero image, przeglądarka celowo opóźni jego pobranie, co wprost pogorszy LCP. Dla elementu LCP użyj zamiast tegofetchpriority="high", który nadaje mu priorytet pobierania. -
CDN dla obrazkówSieć dostarczania treści (CDN) serwuje obrazki z serwera najbliższego użytkownikowi — zmniejszając opóźnienie sieciowe (latency). Cloudflare, Cloudflare Images, Imgix czy BunnyCDN potrafią też automatycznie konwertować obrazki do WebP/AVIF i serwować odpowiedni rozmiar. Popularne hostingi WordPress (Kinsta, WP Engine) często mają CDN w pakiecie.
WebP i AVIF a wyniki PageSpeed — konkretne liczby
Dane z realnych wdrożeń pokazują, jak dużą poprawę może dać sama konwersja formatów:
| Typ strony | LCP przed (JPEG) | LCP po (WebP) | LCP po (AVIF) |
|---|---|---|---|
| Strona główna bloga | 3,2 s | 2,1 s | 1,8 s |
| Strona produktu e-commerce | 4,5 s | 2,9 s | 2,4 s |
| Strona kategorii (20 produktów) | 5,1 s | 3,3 s | 2,6 s |
| Strona portfolio z galerią | 6,2 s | 3,8 s | 2,9 s |
Wyniki są szacunkowe i zależą od infrastruktury serwera, lokalizacji użytkowników i złożoności strony. Niemniej ilustrują skalę możliwej poprawy. W przypadku stron z ciężkimi galeriami lub wiele obrazków na stronie głównej, konwersja do WebP/AVIF jest często najbardziej efektywną kosztowo optymalizacją — prosta do wdrożenia, a efekty widoczne od razu.
Bonus: Konwersja do WebP/AVIF poprawia też CLS — jeśli jednocześnie dodasz atrybuty width i height do obrazków, przeglądarka zarezerwuje odpowiednie miejsce w layoutcie i elementy nie będą się "przesuwać" podczas ładowania strony.
Preload hero image — przykładowy kod
Jeśli wiesz z góry, który obrazek jest elementem LCP (np. baner na stronie głównej), dodaj jego preload do <head>. To jeden z najszybszych sposobów na redukcję LCP o 200–500 ms:
<!-- W <head> strony, jak najwcześniej -->
<link
rel="preload"
as="image"
href="/hero.webp"
type="image/webp"
fetchpriority="high">
<!-- Jeśli serwujesz też AVIF, dodaj warunkowy preload -->
<link
rel="preload"
as="image"
href="/hero.avif"
type="image/avif"
fetchpriority="high">
<picture>
<source srcset="/hero.avif" type="image/avif">
<source srcset="/hero.webp" type="image/webp">
<img
src="/hero.jpg"
alt="Główny baner strony"
width="1920"
height="600"
fetchpriority="high"
decoding="async">
<!-- NIE dodawaj loading="lazy" do elementu LCP! -->
</picture>
Jak naprawić LCP na WordPress — krok po kroku
Na WordPressie kilka kroków może znacząco poprawić LCP. Zacznij od największych problemów — formatu i rozmiaru obrazka LCP:
Darmowa instalacja, bulk optymalizacja całej biblioteki mediów, wyniki w PageSpeed Insights od razu.
Jak monitorować Core Web Vitals na bieżąco?
Optymalizacja to nie jednorazowe działanie — strona się zmienia, pojawiają się nowe treści, aktualizacje motywu i wtyczek. Regularne monitorowanie CWV pozwala wcześnie wykryć regresje:
- Google Search Console — bezpłatne, pokazuje dane rzeczywiste dla całej witryny z podziałem na mobile/desktop. Alerty e-mail przy pogorszeniu wyników. Zakładka "Core Web Vitals" pokazuje konkretne URLe z problemami.
- PageSpeed Insights API — można zautomatyzować codzienne sprawdzanie kluczowych podstron i zapisywać historię wyników w arkuszu Google Sheets lub bazie danych.
- WebPageTest.org — zaawansowane testy z filmami ładowania strony, waterfall requestów i porównaniem przed/po zmianach. Bezpłatny dla podstawowego użycia.
- WebP Check — szybki skaner do sprawdzenia, czy nowe obrazki pojawiające się na stronie są w WebP/AVIF. Idealny do szybkiego audytu po większej aktualizacji treści.
Uwaga: Google używa danych z Chrome UX Report (CrUX) sprzed 28 dni — efekty optymalizacji w Search Console będą widoczne dopiero po ok. miesiącu. W PageSpeed Insights możesz sprawdzić dane laboratoryjne (Lighthouse) natychmiast po wdrożeniu zmian.
Najczęściej zadawane pytania
LCP (Largest Contentful Paint) to metryka Core Web Vitals mierząca czas do wyrenderowania największego widocznego elementu na stronie — najczęściej jest nim główny obrazek, baner lub blok tekstu. Google uznaje LCP poniżej 2,5 sekundy za dobry wynik, 2,5–4 s za wymagający poprawy, a powyżej 4 s za słaby.
Najskuteczniejsze metody poprawy LCP to: konwersja obrazków do WebP lub AVIF (zmniejsza rozmiar o 25–55%), dodanie preload dla obrazka LCP, usunięcie lazy loading z elementu LCP i dodanie fetchpriority="high", optymalizacja serwera (TTFB poniżej 800 ms) oraz użycie CDN dla statycznych zasobów.
Tak — konwersja do WebP lub AVIF bezpośrednio redukuje rozmiar pliku obrazka LCP, co skraca czas jego pobierania i renderowania. Strony, które przeszły z JPEG na WebP, notują typowo 0,3–0,8 sekundy poprawę LCP. Przy konwersji do AVIF oszczędności mogą być jeszcze większe.
Najlepsze narzędzia: Google PageSpeed Insights (pagespeed.web.dev) pokazuje dane laboratoryjne i rzeczywiste, Google Search Console (sekcja Core Web Vitals) pokazuje dane polowe dla całej witryny, Chrome DevTools (Lighthouse) do testowania lokalnie. WebP Check sprawdza szybko czy problematyczne są formaty obrazków.
INP (Interaction to Next Paint) zastąpił FID jako metrykę interaktywności w Core Web Vitals od marca 2024. Mierzy czas od interakcji użytkownika (kliknięcie, dotyk) do momentu, gdy przeglądarka wyświetli aktualizację. Dobry INP to poniżej 200 ms. Obrazki nie wpływają bezpośrednio na INP — tu kluczowa jest optymalizacja JavaScript.