Lighthouse na 16 portfolio programistów: immersyjne kontra minimalistyczne

W mobilnym Lighthouse 10 zmierzonych przeze mnie portfolio immersyjnych (z WebGL) miało medianę wydajności 35,5, a 6 minimalistycznych 74,5. Tylko jedna z 16 stron dostała 90 lub więcej i tylko jedna miała dobre LCP w laboratorium. Niżej metoda, wyniki i to, czego wynik Lighthouse nie powie Ci o stronie 3D.

W skrócie

• Skąd ta przepaść: mediana strony 3D ważyła około 12 MB i blokowała główny wątek przez około 2,2 s; mediana minimalistycznej: 0,9 MB i 0,23 s.
• Na szczycie prawie pusto: żadna strona immersyjna nie przekroczyła 64, a jedyna minimalistyczna z wynikiem 90+ używała fontów systemowych.
• Czytaj ostrożnie: pomiary laboratoryjne, po trzy na stronę, z desktopową kartą graficzną, więc strony 3D wypadają tu najpewniej lepiej niż na prawdziwym telefonie. Nie wymieniam z nazwy żadnej strony z niskim wynikiem.

Po co mierzyć cudze portfolio?

Moje stare portfolio było lotem przez Układ Słoneczny w three.js i w mobilnym Lighthouse dostawało 34 punkty.

Stara strona

Zanim je przebudowałem (całą historię opisałem w studium przypadku), chciałem wiedzieć, czy to norma w tym gatunku, czy mój problem. Dlatego 5 października 2026 zmierzyłem w ten sam sposób 16 znanych portfolio.

Nie podaję nazw stron z niskim wynikiem. Three.js uczyłem się z kursu prowadzonego przez jedną z osób z grupy immersyjnej, a te strony należą do najbardziej pomysłowych rzeczy w sieci. Wynik 30 na emulowanym telefonie mówi coś o ładowaniu. O warsztacie nie mówi nic.

Jak mierzyłem?

1. 01 Wybór 16 stron 10 immersyjnych (8 portfolio, 2 studia), 6 minimalistycznych
2. 02 Lighthouse 3 razy Profil mobilny, symulowane dławienie, pomiar za pomiarem
3. 03 Mediany Najpierw dla każdej strony, potem dla każdej grupy
4. 04 Test na telefonie Playwright przy 390 px: bramki, reduced motion, zoom

Ustawienie	Wartość
Narzędzie	Lighthouse 13.5.0 CLI, Chromium 153 w trybie headless
Urządzenie	domyślny profil mobilny: Moto G Power, 412 × 823 px, gęstość pikseli 1,75
Dławienie	symulowane: 150 ms opóźnienia, 1,6 Mb/s pobierania, procesor spowolniony 4×
Data	5 października 2026, z Polski

Grupa immersyjna to znane portfolio w three.js, niedawni zwycięzcy Site of the Day w Awwwards i FWA oraz dwie strony studiów jako sufit warsztatu. Grupa minimalistyczna to znane portfolio inżynierów i design engineerów, część z bardzo dopracowanymi mikrointerakcjami.

Dwa zastrzeżenia, zanim padnie jakakolwiek liczba. Komputer dzielił pracę z innymi zadaniami: benchmark procesora w Lighthouse (benchmarkIndex) wahał się w pierwszym pomiarze każdej strony od 841 do 2381. Trzy pomiary to wygładzają, a liczba bajtów od tego nie zależy.

Poza tym dokumentacja Lighthouse sama przyznaje, że duża część wahań wyniku nie bierze się z Lighthouse. Radzi traktować wydajność strony jak rozkład wyników, a nie jedną liczbę. Patrz na mediany, nie na miejsca po przecinku.

Jakie były wyniki?

Telefon, mediana z 3 pomiarów	Immersyjne (10)	Minimalistyczne (6)
Wynik wydajności	35,5	74,5
Najwyższy / najniższy wynik	64 / 26	95 / 65
Strony na zielono (90+) / pomarańczowo (50-89) / czerwono (poniżej 50)	0 / 1 / 9	1 / 5 / 0
Waga strony	około 12 MB	około 0,9 MB
JavaScript	około 750 KB	około 265 KB
Całkowity czas blokowania	około 2,2 s	około 0,23 s
Największe malowanie treści (LCP)	około 20 s	około 4,0 s
LCP do 2,5 s	1 z 10	0 z 6
Przesunięcia układu (CLS)	najwyżej 0,004	0

Przepaść robią waga i czas blokowania; na przesunięciach układu nikt nie traci, bo pełnoekranowy canvas się nie rusza. Od Lighthouse 10 całkowity czas blokowania to 30% wyniku, a LCP 25%. Strona, która blokuje się na sekundy i maluje późno, nie dostanie dobrego wyniku, niezależnie od tego, jak wygląda.

Na komputerze to inna historia. W pojedynczym pomiarze desktopowym jedna ze stron studiów dostała 90, a na telefonie ta sama strona miała 38. Cały problem siedzi w tej różnicy.

Dlaczego strony immersyjne były wolne?

Wracały trzy wzorce:

1. Brak wczesnego tekstu do namalowania. Na liście kandydatów na LCP z web.dev (obrazy, <image> w SVG, wideo, obrazy tła z CSS, tekst w elementach blokowych) nie ma <canvas>. Kiedy strona to canvas plus ekran ładowania, LCP trafia na pierwszy tekst, jaki się pojawi, często napis samego loadera. Dwie strony pokazywały na telefonie 0 i 1 znak tekstu w DOM.
2. Dużo JavaScriptu wykonywanego na starcie. Z czterech stron immersyjnych, które rozłożyłem na części, trzy miały 10-23 s pracy głównego wątku przy 4-krotnym spowolnieniu procesora, a jedna znacznie więcej. Dwie strony minimalistyczne: 1,4-1,7 s. Większość tego czasu to wykonywanie skryptów.
3. Ciężkie media w trakcie ładowania. Wielomegabajtowe wideo z autoodtwarzaniem i tekstury pobierane, zanim strona skończyła się ładować.

Jedyna strona immersyjna z dobrym LCP (1,1 s) zrobiła jedną rzecz inaczej: jej bio było w HTML renderowanym na serwerze, a WebGL leżał na nim jako warstwa. Nadal traciła punkty przez 15,3 MB wideo ładowanego od razu i 2,2 s blokowania. Tekst na początku naprawił malowanie. Wagi nie naprawił.

Czy minimalizm oznacza szybkość?

Nie. Jedyna strona z wynikiem 90+, leerob.com (95), używała fontów systemowych, czyli 0 bajtów fontów webowych, około 240 KB JavaScriptu i żadnych skryptów zewnętrznych. Dwie inne strony minimalistyczne ładowały ponad 1 MB fontów każda, w 9 plikach, i obie przekroczyły próg LCP, głównie przez nie.

Fonty to część ładowania, a nie ozdoba. To jeden z powodów, dla których ta strona ma jeden zmienny font o wadze około 50 KB.

Czego Lighthouse nie mierzy?

• Karty graficznej. Lighthouse dławi sieć i procesor; jego dokumentacja dławienia w ogóle nie wspomina o GPU. Moje pomiary korzystały z desktopowej karty NVIDIA RTX 2060, więc na prawdziwym telefonie spodziewałbym się po stronach 3D gorszych wyników, nie lepszych.
• Prawdziwych telefonów i prawdziwych ludzi. web.dev tłumaczy, że dane laboratoryjne pochodzą z jednego urządzenia podłączonego do jednej sieci, a dane terenowe obejmują ogromną różnorodność sieci i urządzeń. Żadna z tych liczb nie pochodzi z terenu. Bez interakcji użytkownika Lighthouse nie zmierzy też INP; w laboratorium zastępuje je całkowity czas blokowania.
• Tego, co za bramką. Trzy z dziesięciu stron immersyjnych stawiają przed treścią przycisk startu albo zachętę „tap to explore”. Lighthouse mierzy bramkę, a nie doświadczenie.
• Dostępności poza automatem. Wynik dostępności to średnia ważona testów typu zaliczony albo niezaliczony. Jedna ze stron studiów rysuje wszystko w WebGL, na telefonie ma 0 znaków tekstu w DOM i dostała 100: testy prawie nie miały czego oblać. Pięć z dziesięciu stron immersyjnych ma tu 100.
• Warsztatu. Nie ma testu na „pamiętam tę stronę po tygodniu”.

Osobny test w Playwright na ekranie telefonu o szerokości 390 px (emulacja w Chromium, nie prawdziwy iOS) pokazał trzy rzeczy, których wyniki nie widzą:

• Wszystkie dziesięć stron immersyjnych coś na telefonie wyświetla; jedna nadal ostrzega, że najlepiej oglądać ją na komputerze.
• Przy emulowanym ograniczeniu ruchu żadna z dziesięciu się nie zmieniła: każda tworzyła kontekst WebGL i utrzymywała tę samą liczbę klatek. Jak zrobić to porządnie, opisałem w tekście o reduced motion i przycisku pauzy.
• 4 z 16 stron (3 immersyjne, 1 minimalistyczna) wyłączały powiększanie gestem w tagu viewport. To oblewa regułę axe „Zooming and scaling must not be disabled”, która istnieje dla osób słabowidzących, polegających na powiększeniu.

Gdzie w tym wszystkim moja stara strona?

Moje stare kosmiczne portfolio dostało 34 punkty na telefonie, w tej samej wersji Lighthouse, tego samego dnia: tuż poniżej mediany stron immersyjnych. Z 13,8 MB przed przyciskiem startu było też cięższe niż mediana tej grupy. Nie było wśród tych 16 stron, a jego pomiar szedł bez karty graficznej, więc porównanie nie jest idealne. Ale pasowałoby tu bez trudu. Co je spowalniało, opisałem w tekście Dlaczego moje portfolio w three.js było wolne na telefonie.

Co z tym robi ta strona?

• Najpierw tekst. H1 to element LCP: renderowany na serwerze, gotowy przy pierwszym malowaniu, nigdy nie wjeżdża animacją.
• Budżet przed kodem. Lighthouse na telefonie co najmniej 90 na każdej podstronie, LCP poniżej 2,5 s, poniżej 150 KB JavaScriptu i 100 KB fontów.
• 3D jako opcjonalna warstwa, nigdy na ścieżce krytycznej: w nagłówku nie ma WebGL, a shadery na innych podstronach czekają na pierwszy ruch czytelnika.

To nie jest uczciwe porównanie: w moim nagłówku nie ma WebGL. Taki kompromis wybrałem.

Ograniczenia

• Tylko laboratorium: jedna maszyna, jeden dzień, współdzielony komputer, trzy pomiary na stronę. Brak danych terenowych dla którejkolwiek z tych stron.
• 16 stron to próbka, a nie spis, i wybrałem ją sam.
• Nic tu nie działało na fizycznym iPhonie ani Androidzie, a właśnie tam te strony są naprawdę oceniane.
• Desktop to jeden pomiar i tylko dla części stron.
• Moją stronę główną mierzyłem na lokalnym buildzie. Jej mediana LCP (2,3-2,6 s w trzech językach) krąży wokół mojego budżetu 2,5 s, a wersji produkcyjnej nie mierzyłem ponownie od 7 października.

Jeśli chcesz zobaczyć, co buduję w takich budżetach, przejrzyj moje projekty.

Źródła

1. Lighthouse performance scoring (Chrome for Developers) (otwiera się w nowej karcie) (dostęp: 8 października 2026)
2. Lighthouse throttling (GoogleChrome/lighthouse docs) (otwiera się w nowej karcie) (dostęp: 8 października 2026)
3. Lighthouse config constants: mobile screen emulation (GoogleChrome/lighthouse) (otwiera się w nowej karcie) (dostęp: 6 października 2026)
4. Largest Contentful Paint (LCP), web.dev (otwiera się w nowej karcie) (dostęp: 8 października 2026)
5. Web Vitals (web.dev) (otwiera się w nowej karcie) (dostęp: 6 października 2026)
6. Why lab and field data can be different (web.dev) (otwiera się w nowej karcie) (dostęp: 8 października 2026)
7. Lighthouse accessibility scoring (Chrome for Developers) (otwiera się w nowej karcie) (dostęp: 6 października 2026)
8. meta-viewport: Zooming and scaling must not be disabled (Deque, axe rules) (otwiera się w nowej karcie) (dostęp: 8 października 2026)
9. Solar System Scope, tekstury planet (CC BY 4.0) użyte w starym kosmicznym portfolio (otwiera się w nowej karcie) (dostęp: 8 października 2026)