Above the fold – co to jest i czemu bywa czarne?

Czym jest above the fold

Pułapka leniwego ładowania

Najczęstsza usterka pierwszego ekranu bierze się z dobrej intencji. Leniwe ładowanie obrazów oszczędza transfer, więc bywa włączane hurtowo, również dla zdjęcia, które użytkownik widzi w pierwszej sekundzie. Dokumentacja stawia sprawę jednoznacznie: „For images that are visible when the user first loads the page, and especially for LCP images, use the browser’s default eager loading so they can be available right away”, a leniwe ładowanie stosować „only for images outside the initial viewport”.2

Powód jest mechaniczny i wyjaśniony w tym samym miejscu: „The browser can’t lazy-load an image until it knows where the image should be on the page, which causes them to load more slowly”. Sens leniwego ładowania odwraca się więc o sto osiemdziesiąt stopni: zamiast oszczędzać to, co niewidoczne, opóźnia to, co najważniejsze.

Na własnych wdrożeniach złapaliśmy ostrzejszą odmianę tego problemu. WordPress dokleja do obrazów atrybut sizes="auto" razem z loading="lazy", a przy tle sekcji hero przeglądarka nie dostaje sygnału, na który czeka, i nie pobiera obrazu wcale. Pierwszy ekran zostaje pusty albo czarny, mimo że plik jest poprawny i leży na serwerze. Poprawkę mamy wdrożoną: sprawdzenie ośmiu podstron 20 sierpnia 2026 pokazało na każdej wstępne pobieranie obrazu hero i atrybut eager zamiast lazy.3

Element, który spowalnia, nie musi być obrazem

Poprawa obrazów rozwiązuje tylko część problemu, bo wskaźnik nie mierzy wyłącznie zdjęć. Lista elementów branych pod uwagę obejmuje obrazy, wideo, tła wstawiane funkcją url(), ale też „block-level elements containing text nodes”, czyli zwykły tekst.1 Największym elementem pierwszego ekranu bywa więc nagłówek, nie fotografia.

Dokładnie tak wyszło u nas. W pomiarze z 20 sierpnia 2026 elementem decydującym o wyniku na stronie głównej okazał się nagłówek z gradientem, czyli tekst czekający na pobranie kroju pisma. Czas wyniósł od 984 do 2088 milisekund w czterech kolejnych przebiegach, podczas gdy strony usług mieściły się w 292–380 milisekundach.3 Najwolniejszy pierwszy ekran w całym serwisie miała strona, na którą trafia najwięcej osób. Żadna poprawka przy obrazach by tego nie ruszyła.

Co się w tym ekranie mieści

Drugie pytanie o pierwszy ekran dotyczy nie szybkości, tylko zawartości. Zmierzyliśmy to na czternastu własnych podstronach w oknie o wysokości ekranu telefonu: nagłówek główny pojawiał się wszędzie w pierwszym ekranie, na wysokości 0,5–0,8 jego wysokości. Pierwszy nagłówek sekcji, czyli początek treści właściwej, leżał już jednak po 1,4–2,3 ekranu przewijania na stronach usług.3

To typowy układ: hasło i grafika zajmują cały pierwszy ekran, a konkret zaczyna się dopiero za nim. Nie zawsze jest to błąd, ale lepiej podejmować tę decyzję świadomie, zwłaszcza że na telefonie w pierwszym ekranie mieści się kilkakrotnie mniej niż na monitorze, więc hierarchię trzeba ustalać osobno dla obu urządzeń.

Pierwszy ekran, hosting i SXO

Czas dotarcia pierwszego ekranu zależy w dużej mierze od jakości hostingu, a jego zawartość rozstrzyga, czy dobrze zaprojektowany landing page dostanie szansę pokazać resztę treści. Obie te rzeczy składają się na SXO, a mierzalny wycinek całości opisuje page experience.

Najczęstsze pytania

Czy każdy obraz w pierwszym ekranie powinien mieć eager?
Tak, każdy widoczny bez przewijania. Leniwe ładowanie zostawia się dla obrazów poza pierwszym ekranem, zgodnie z zaleceniem dokumentacji.

Czy element mierzony jako największy to zawsze zdjęcie?
Nie. Liczą się też bloki zawierające tekst. Na naszej stronie głównej decydował nagłówek czekający na krój pisma, nie obraz.

Czy above the fold wygląda tak samo na komputerze i telefonie?
Nie. Na telefonie mieści się kilkakrotnie mniej treści, więc kolejność elementów trzeba ustalić osobno dla obu urządzeń.

Jak sprawdzić, czy pierwszy ekran ładuje się poprawnie?
Zmierzyć kilka razy, nie raz. Nasza strona główna dała w czterech kolejnych przebiegach wyniki od 984 do 2088 milisekund. Pojedynczy odczyt nie rozstrzygnąłby niczego.

Źródła

1. web.dev (Google), Largest Contentful Paint (LCP): „A good LCP value is 2.5 seconds or less”; lista elementów branych pod uwagę obejmuje między innymi elementy <img>, <video>, elementy z obrazem tła wstawianym funkcją url() oraz „block-level elements containing text nodes or other inline-level text element children”. Zobacz dokumentację → (odczyt 2026-08-20).

2. web.dev (Google), Browser-level image lazy loading for the web: „For images that are visible when the user first loads the page, and especially for LCP images, use the browser’s default eager loading so they can be available right away”; „Use loading=lazy only for images outside the initial viewport. The browser can’t lazy-load an image until it knows where the image should be on the page, which causes them to load more slowly”. Zobacz dokumentację → (odczyt 2026-08-20).

3. Pomiary własne essaseo.pl z 2026-08-20. Kontrola ładowania obrazów na ośmiu podstronach: na każdej wstępne pobieranie obrazu hero i atrybut eager. Pomiar Largest Contentful Paint w przeglądarce bez interfejsu, przy emulacji telefonu 412×915 i procesorze spowolnionym czterokrotnie: strona główna 984, 1052, 1104 i 2088 ms w czterech przebiegach, element decydujący to nagłówek z gradientem; strony usług 292–380 ms. Pomiar geometrii na czternastu podstronach: nagłówek główny na wysokości 0,5–0,8 ekranu, pierwszy nagłówek sekcji na stronach usług po 1,4–2,3 ekranu.