Obraz LCP i zarezerwowane miejsce: test w przeglądarce
To materiał do artykułu. We wrześniu 2026 zrobiłem dwa małe eksperymenty na sztucznej stronie testowej, żeby pokazać dwa mechanizmy: późno odkryty obraz opóźnia LCP, a obraz bez wymiarów przesuwa układ. Niżej są wszystkie wyniki, warunki testu i skrypt, którym go powtórzysz.
Na co patrzyłem
W pierwszym eksperymencie obraz był w HTML od początku albo skrypt wstawiał jego adres dopiero po 650 ms. W obu wariantach obraz miał wymiary. W drugim eksperymencie ten sam obraz pojawiał się po 650 ms w obu wariantach, a różniła je tylko obecność atrybutów width i height. Opóźnienie 650 ms wybrałem sam, żeby zasymulować późno odkryty obraz, więc nie mówi nic o skali problemu na prawdziwej stronie.
Każdy wariant uruchomiłem pięć razy w dwóch widokach, 390 × 844 i 1280 × 900 px, co daje 40 prób. Strona testowa trafiała do przeglądarki bez serwera, a obraz PNG o wymiarach 800 × 400 px (15 918 bajtów, wzór pikseli zamiast zdjęcia) był osadzony bezpośrednio w HTML jako data:. Dzięki temu porównanie zależy tylko od zmienianego elementu, ale w teście nie ma sieci, transferu ani cache. Każda próba startowała w świeżym kontekście przeglądarki, a kolejność wariantów zmieniałem na przemian.
Po wczytaniu strony skrypt obserwował ją przez 1,1 s. LCP to ostatni wpis largest-contentful-paint, liczony od startu dokumentu w przeglądarce. CLS to największe okno sesji przesunięć, czyli przesunięcia oddalone od siebie o mniej niż sekundę w oknie do 5 s, bez tych tuż po działaniu użytkownika. Tak obie metryki definiuje web.dev (LCP, CLS).
Wyniki
| Eksperyment | Wariant | Widok | Próby | LCP: mediana (min–max) | CLS: mediana |
|---|---|---|---|---|---|
| Odkrycie obrazu | obraz po 650 ms | 390 px | 5 | 704 ms (700–720) | 0 |
| Odkrycie obrazu | obraz od razu | 390 px | 5 | 60 ms (56–60) | 0 |
| Odkrycie obrazu | obraz po 650 ms | 1280 px | 5 | 700 ms (696–700) | 0 |
| Odkrycie obrazu | obraz od razu | 1280 px | 5 | 64 ms (56–68) | 0 |
| Miejsce na obraz | bez wymiarów | 390 px | 5 | 708 ms (700–728) | 0,127 |
| Miejsce na obraz | z wymiarami | 390 px | 5 | 708 ms (696–720) | 0 |
| Miejsce na obraz | bez wymiarów | 1280 px | 5 | 712 ms (700–836) | 0,109 |
| Miejsce na obraz | z wymiarami | 1280 px | 5 | 708 ms (700–908) | 0 |
Obraz dostępny od razu dał LCP około 60 ms zamiast około 700 ms. Wymiary obrazu sprowadziły CLS do zera, ale LCP został przy 708 ms, bo obraz dalej czekał na ten sam timer. W tabeli są wszystkie ukończone próby, łącznie z wolniejszymi, a pełne wartości CLS znajdziesz w plikach JSON.
Czego te dane nie pokażą
- Pięć prób na wariant to demonstracja mechanizmu, więc z tych liczb nie wyliczysz procentu poprawy dla swojej strony.
- Test pomija sieć, kompresję, CDN, nagłówki cache, fonty, lazy loading,
fetchpriorityi preload. - Mierzyłem tylko LCP i CLS w Chromium bez dławienia procesora. INP, TBT, Lighthouse, Safari, Firefox, iOS i prawdziwe urządzenia zostały poza testem.
- To laboratorium, a nie cometweb.io ani ruch użytkowników, dlatego lokalnych czasów LCP nie porównuj z danymi CrUX czy RUM swojej strony.
Pliki
lcp-lab-results.json: wszystkie próby eksperymentu z odkryciem obrazu, z opisem środowiskacls-lab-results.json: wszystkie próby eksperymentu z miejscem na obraz, z każdym przesunięciemrun_lab.py.txt: skrypt, który buduje strony testowe i mierzy obie metrykilcp-early.html.txtilcp-delayed.html.txt: strony z pierwszego eksperymentucls-unreserved.html.txticls-reserved.html.txt: strony z drugiego eksperymentusources.json: dokumentacja, na której opiera się artykuł
Żeby powtórzyć test, zapisz skrypt jako lab/run_lab.py, zainstaluj Playwright z Chromium i Pillow, a potem uruchom go z --experiment lcp i drugi raz z --experiment cls. Ja używałem Chromium 144, Playwright 1.57, Pythona 3.13 i Pillow 12.3, a czasy u ciebie będą trochę inne.
Formularze do własnych pomiarów są w materiałach do artykułu.