Dlaczego PageSpeed pokazuje 3 s LCP, choć strona ładuje się w 1,7 s

Largest Contentful Paint (LCP) to czas, po którym na ekranie pojawia się największy element strony. Google uznaje wynik do 2,5 s za dobry, więc 3,0 s na telefonie wyglądało na problem do naprawienia. Zanim zaczęliśmy cokolwiek naprawiać, sprawdziliśmy, co dokładnie mierzy PageSpeed. Okazało się, że większa część tych trzech sekund nie wynika ze strony.

Co pokazał PageSpeed

Wynik na telefonie: 94 punkty wydajności, FCP 1,2 s i LCP 3,0 s. Największym elementem był obraz w tle nagłówka, plik o wadze 17 KB.

Rozbicie LCP w raporcie było zaskakujące. Obraz zaczął się pobierać po 90 ms, pobrał się w 75 ms, a potem przez 1,1 s czekał na wyświetlenie. Serwer odpowiadał błyskawicznie, obraz był gotowy prawie od razu, a mimo to przeglądarka go nie pokazywała.

Jak Lighthouse liczy LCP

PageSpeed Insights korzysta z Lighthouse. Domyślnie Lighthouse nie spowalnia strony naprawdę. Ładuje ją szybko, zapisuje, co się działo, a potem na podstawie tego zapisu szacuje, ile trwałoby to samo na wolnym łączu 4G i czterokrotnie wolniejszym procesorze.

Żeby oszacować LCP, model bierze pod uwagę wszystko, co w szybkim ładowaniu wydarzyło się przed wyświetleniem największego elementu: pobrane pliki i uruchomione skrypty. Jeśli w szybkim ładowaniu pierwsze wyświetlenie przyszło późno, już po wykonaniu całego JavaScriptu, model zakłada, że obraz musiał czekać na cały ten kod. W naszym przypadku było to około 360 KB, łącznie z całym frameworkiem.

Kluczowe pytanie brzmiało więc: dlaczego w szybkim ładowaniu przeglądarka tak długo nic nie pokazywała?

Skąd opóźnione pierwsze wyświetlenie

W zapisach z Lighthouse strona była w pełni załadowana po 0,5–0,8 s, a pierwsza klatka pojawiała się na ekranie po 0,9–2,4 s. Główny wątek przeglądarki w tym czasie prawie nic nie robił. Klatki były gotowe, ale przeglądarka wyświetlała je mniej więcej raz na sekundę.

Ten sam objaw odtworzyliśmy poza Lighthouse, uruchamiając Chrome z dokładnie tymi flagami, których używa Lighthouse. Wyłączając je po kolei, doszliśmy do jednej:

--disable-features=RenderDocument

Z samą tą flagą pierwsze wyświetlenie naszej strony za każdym razem przychodziło po około 2,4 s. Bez niej, po 0,4–0,6 s. Podobny efekt zobaczyliśmy na innych stronach zbudowanych w Next.js, między innymi na react.dev i nextjs.org. Na prostej stronie bez JavaScriptu, takiej jak example.com, flaga nic nie zmieniała.

RenderDocument to sposób, w jaki współczesny Chrome tworzy nowy dokument przy każdym przejściu między stronami. Wyłączenie go przełącza przeglądarkę w starszy tryb, w którym nie pracuje żaden z Twoich użytkowników.

Nie wiemy, jak dokładnie PageSpeed uruchamia Chrome na swoich serwerach. Wiemy tylko, że jego raport pokazał ten sam objaw: 1,1 s oczekiwania na wyświetlenie obrazu, który był już pobrany.

Ile naprawdę trwa ładowanie

Lighthouse potrafi też naprawdę spowolnić łącze i procesor zamiast szacować. Przy tych samych ustawieniach, wolnym 4G i czterokrotnie wolniejszym procesorze, ta sama wersja naszej strony pokazuje główny obraz po 1,7–1,8 s. To wynik mieszczący się w granicy 2,5 s, którą Google uznaje za dobrą.

Pamiętaj też, że o ocenie Core Web Vitals w wyszukiwarce decydują dane od prawdziwych użytkowników Chrome, a nie wynik testu laboratoryjnego. PageSpeed pokazuje je w osobnej sekcji raportu, gdy strona ma wystarczający ruch.

Co z tym zrobić

Sprawdzaj dane od prawdziwych użytkowników. Jeśli PageSpeed je pokazuje, to one są ważniejsze niż wynik laboratoryjny.

Mierz z prawdziwym spowolnieniem. Lighthouse uruchomiony z wiersza poleceń może spowalniać stronę naprawdę zamiast symulować:

npx lighthouse https://twoja-strona.pl --throttling-method=devtools

Nie optymalizuj pod błąd pomiaru. Sprawdziliśmy między innymi wstawienie całego CSS bezpośrednio do HTML. Przy prawdziwym spowolnieniu tekst pojawiał się szybciej, ale wynik symulacji pogorszył się o 0,15 s, bo Next.js wysyła wtedy CSS dwa razy i strona staje się cięższa. Zmiana, która pomaga użytkownikom, może pogorszyć wynik, i odwrotnie.

Zmniejszaj to, co ładuje się przed pierwszym wyświetleniem. To pomaga w obu pomiarach. U nas oznaczało to przeniesienie kodu, który jest potrzebny dopiero później, na przykład przeciągania elementów i walidacji formularza, tak żeby ładował się dopiero wtedy, gdy jest używany.

Wyniki sprawdzaliśmy we wrześniu 2026 roku na Chrome 153, Lighthouse 12 i Lighthouse 13.5 w PageSpeed Insights. Przy nowszych wersjach mogą wyglądać inaczej.

Jeśli Twoja strona ma podobny problem albo chcesz, żeby była szybka od początku, zobacz, jak pracujemy nad stronami internetowymi.