Przejdź do treści
Strona głównaO mnieUsługiProjektyKontakt
← Blog
// PERFORMANCE6 czerwca 2026·7 min czytania

Jak zbiłem Performance z 57 do 97

Lighthouse pokazał 57. Nie przepisałem ani linijki logiki. Zdjąłem ~7 MB i przesunąłem kilka obrazów poza ścieżkę krytyczną — wynik podskoczył do 97. Oto dokładnie co, dlaczego i ile to dało.

Czym jest Lighthouse (i czemu to nie zabawka)

Jeśli nie siedzisz w temacie: Lighthouse to darmowy audyt strony od Google, wbudowany w przeglądarkę Chrome (DevTools → zakładka LighthouseAnalyze page load). Ocenia stronę w skali 0–100 w czterech kategoriach: Performance, Accessibility, Best Practices i SEO.

Wynik Performance nie jest wróżeniem z fusów — liczy się z realnych metryk, tzw. Core Web Vitals. Lighthouse symuluje wczytanie strony na spowolnionym łączu i mierzy m.in.:

FCP — kiedy pojawia się pierwszy element
LCP — kiedy ładuje się największy (główna treść)
Speed Index — jak szybko strona wygląda na gotową
CLS — czy layout skacze podczas ładowania
TBT / INP — czy strona reaguje na kliknięcia

Czemu Cię to obchodzi? Po pierwsze — Google używa Core Web Vitals jako czynnika rankingowego (niewielkiego, ale realnego). Po drugie, ważniejsze: to proxy realnego UX. Wolna strona = ludzie uciekają, zanim się załaduje, a konwersje lecą w dół. Lighthouse daje obiektywny, powtarzalny pomiar zamiast „mnie się ładuje szybko". I właśnie dlatego 57 było problemem.

57 to nie była wina kodu

Strona renderuje GSAP, parallax i animowaną „eksplozję" 3D w hero — sporo dzieje się po stronie klienta. Naturalny pierwszy odruch: „to ciężki JavaScript zabija wynik". Błąd. Czerwone były FCP, LCP i Speed Index — czyli metryki tego, kiedy użytkownik zobaczy treść. A te trzy świeciły na czerwono z jednego powodu: przeglądarka musiała pobrać ~7 MB obrazów, zanim cokolwiek namalowała.

Lighthouse nie mierzy „jak ładny masz kod". Mierzy czas do pierwszego sensownego piksela. Jeśli każesz mu czekać na 3,2 MB mgławicy w tle hero, zanim pojawi się tytuł — dostajesz 57, choćby reszta była idealna.

Co realnie ważyło

Diagnoza zaczęła się od policzenia bajtów, nie od profilera JS. Tła kosmosu w public/ wyglądały tak:

nebula.jpg   3,2 MB  (2048×1368, w hero)
kosmos1.jpg  1,3 MB  (3840×2400 — 4K do tła!)
kosmos2.jpg  1,4 MB
blog.jpg     1,8 MB
+ kilka mniejszych = ~9,7 MB łącznie

Plus jeden martwy plik 3,2 MB, nieużywany nigdzie w kodzie — czysty balast. Najgorszy był nebula.jpg: 3,2 MB ładowane natychmiast w hero, konkurujące o pasmo z prawdziwą treścią.

Fix #1: obrazy — 9,7 MB → 2,6 MB

Przekompresowałem tła w miejscu (te same nazwy plików → zero zmian w kodzie) i zbiłem rozdzielczość tam, gdzie 4K do tła nie miało sensu. Efekt:

nebula.jpg  3,2 MB → 384 KB
kosmos1.jpg 1,3 MB → 276 KB
suma 9,7 MB → 2,6 MB (−73%)

Ciekawostka: nebula.jpg przy zwykłej kompresji ledwo drgnął (3,2 → 2,8 MB). Bo pole gwiazd to wysoka entropia — tysiące drobnych jasnych punktów, których JPEG nie umie ścisnąć. Dopiero zejście z rozdzielczości (to dekoracyjne, rozmywane tło) zbiło go do 384 KB. Wniosek: zanim podkręcisz jakość, sprawdź czy w ogóle potrzebujesz tych pikseli.

Fix #2: zejście z krytycznej ścieżki

Mniejsze pliki to połowa sukcesu. Druga połowa: nie ładować ich, dopóki nie są potrzebne.

Tła parallax leżą głęboko w scrollu, poza pierwszym ekranem. Dodałem im loading="lazy" + decoding="async" — przeglądarka pobiera je dopiero, gdy doscrollujesz. Przestały blokować start.

A hero-nebula (widoczna od razu, ale tylko dekoracyjna) dostała fetchPriority="low" — żeby nie wyrywała pasma prawdziwemu LCP. Drobna flaga, realna różnica w kolejności pobierania.

Wynik: 57 → 97

Po deployu Lighthouse pokazał Performance 97, a przy okazji Accessibility, Best Practices i SEO wskoczyły na 100. Best Practices podbiło się „samo" — bo zniknęły ostrzeżenia o obrazach serwowanych w gigantycznych rozmiarach.

Szczera uwaga: Lighthouse to test laboratoryjny, waha się ±kilka punktów. Ale to nie był „oszukany" wynik — strona realnie waży ~7 MB mniej i tła nie blokują renderu. Na słabym 4G różnicę 57→97 czuć fizycznie.

Co z tego wynika

Trzy rzeczy, które zabieram dalej:

1. Performance to najczęściej bajty na ścieżce krytycznej, nie „ciężki JS". Zanim odpalisz profiler, policz co się pobiera przed pierwszym pikselem.
2. Optymalizuj rozdzielczość, nie tylko jakość. 4K do tła pod overlayem to marnotrawstwo — szczególnie przy obrazach o wysokiej entropii.
3. „W locie" bije „od razu". Co nie jest widoczne na starcie, ma się ładować leniwie.

I jeszcze jedno: dobry wynik Lighthouse to bilet wstępu do SEO, nie wygrana. Sprawia, że Google Cię nie karze i chętnie indeksuje — o pozycje walczy się treścią i linkami. Ale bez tej technicznej bazy reszta stoi na piasku.

Twoja strona ładuje się jak melasa?

→ Zobacz, z czym pomagam (usługi)→ Case study: SEOduszek→ Kontakt