Czy LCP jest ważniejsze niż FCP?

Tak, z perspektywy SEO. FCP (First Contentful Paint) mówi, kiedy pojawia się cokolwiek — może to być pusty header bez treści. LCP mówi, kiedy strona faktycznie zaczyna być przydatna dla użytkownika. Google bierze pod uwagę LCP, nie FCP, jako sygnał rankingowy.

Czy próg 2,5 s dotyczy każdego urządzenia?

Tak, ale Google patrzy osobno na mobile i desktop. Mobile bywa wolniejszy z natury (3G/4G, słabsze procesory), więc dla niego optymalizacja jest trudniejsza. Próg jest jednak ten sam, niezależnie od urządzenia.

Jak mierzyć LCP w produkcji?

PageSpeed Insights pokazuje dane lab + field (z CrUX). Lab to symulacja w kontrolowanych warunkach, field to realni użytkownicy — patrz na field. Dodatkowo wstaw web-vitals.js i wysyłaj metryki do Analytics, żeby śledzić własną kohortę i widzieć trendy w czasie rzeczywistym.

Czy fetchpriority="high" naprawi wolny LCP?

Pomoże, jeśli problem jest w priorytecie ładowania — przeglądarka domyślnie traktuje wszystkie obrazki tak samo. Dla hero image dodaj fetchpriority="high" + ewentualnie preload — przeglądarka zacznie pobierać natychmiast, nie po parsowaniu CSS. Nie naprawi to wolnego TTFB ani dużego rozmiaru pliku.

LCP (Largest Contentful Paint)

LCP (Largest Contentful Paint) to czas, w którym największy widoczny element strony renderuje się w viewporcie. Jedna z trzech metryk Core Web Vitals i bezpośredni sygnał rankingowy Google od czerwca 2021 roku w ramach Page Experience Update.

Co liczy się jako „element największy"

Najczęściej: hero image, blok nagłówka, video poster, duży tekst above the fold, baner promocyjny. Google patrzy na pierwszą warstwę viewportu — to, co użytkownik widzi bez scrollowania. Element może się zmieniać w trakcie ładowania (najpierw jest tekstem placeholderem, potem zastąpionym przez ładujący się obrazek) — LCP raportuje ostatnią wersję.

Progi

Dobry: ≤ 2,5 s.
Wymaga poprawy: 2,5–4 s.
Słaby: > 4 s.
Google ocenia po 75 percentylu z danych CrUX — czyli LCP, którego doświadcza 75% Twoich realnych użytkowników. Lab testy (Lighthouse, PSI lab) służą do debugowania, field data do oceny realnego stanu.

Co najczęściej psuje LCP

Niezoptymalizowany hero image (3 MB JPG zamiast 200 KB WebP). Brak preload dla kluczowego zasobu — przeglądarka odkrywa go dopiero po wczytaniu CSS. Wolny TTFB — backend zwraca HTML w 1,5 sekundy, więc LCP startuje już z opóźnieniem. Blokujące fonty — tekst czeka na font, zanim się wyrenderuje. Lazy loading powyżej fold — atrybut loading=lazy na obrazku above-the-fold opóźnia LCP zamiast go przyspieszać.

Jak poprawić

Optymalizuj obrazki (WebP/AVIF, responsywne srcset, sensowne wymiary). Dodaj <link rel="preload"> na hero image. Wytnij critical CSS i inline'uj go w head. Użyj font-display: swap dla fontów. Przyspiesz TTFB (CDN, cache, lepszy hosting, ISR w Next.js).