Narzędzie Google Lighthouse

TL;DR — Lighthouse to darmowe narzędzie Google, które ocenia stronę internetową w skali od 0 do 100 pod kątem takich rzeczy jak szybkość i dostępność. Uruchamia stronę w spowolnionym „laboratorium” — udawanym wolnym telefonie na wolnej sieci — więc wynik jest często niższy niż to, jak Twoja strona się wydaje. To świetna lista zadań do poprawy, ale wysoki wynik nie przesuwa Cię w górę w rankingu Google.

Czym jest Lighthouse

Google Lighthouse to darmowe narzędzie open-source od zespołu stojącego za Chrome. Wskazujesz mu adres URL, uruchamia serię kontroli strony i daje raport z ocenami w czterech obszarach: Wydajność (jak szybko ładuje się strona), Dostępność (czy osoby z niepełnosprawnościami mogą z niej korzystać), Najlepsze praktyki (ogólna higiena internetowa) i SEO (podstawowe kontrole przyjazności dla wyszukiwarek).

Każdy wynik waha się od 0 do 100, z kolorowymi pasmami, abyś od razu wiedział, jak Ci poszło:

• 0–49 to czerwony — słabo
• 50–89 to pomarańczowy — wymaga poprawy
• 90–100 to zielony — dobrze

Jedna rzecz, którą należy zrozumieć najpierw

Lighthouse testuje Twoją stronę w sztucznych, spowolnionych warunkach — mniej więcej średniej klasy telefon na wolnym połączeniu 4G. Robi to celowo, aby wykryć problemy, które odczuliby prawdziwi użytkownicy na wolniejszych urządzeniach.

Dlatego możesz uruchomić Lighthouse na stronie, która ładuje się natychmiast na Twoim szybkim laptopie, i nadal zobaczyć wynik Wydajności 55. Nie widzisz tego, czego Ty doświadczasz — widzisz to, czego doświadczyłby budżetowy telefon na przeciętnej sieci. Przydatna informacja, ale nie to samo.

Lighthouse to nie PageSpeed Insights (dokładnie)

Prawdopodobnie widziałeś Lighthouse, nie wiedząc o tym. Gdy uruchamiasz stronę przez PageSpeed Insights (narzędzie internetowe na pagespeed.web.dev), wyniki „laboratoryjne”, które Ci pokazuje, to Lighthouse. PageSpeed Insights po prostu opakowuje Lighthouse i dodaje drugi zestaw liczb od prawdziwych użytkowników (zwanych danymi terenowymi lub raportem Chrome UX Report). Więcej o tym rozróżnieniu w wersji zaawansowanej.

Wielki mit do obalenia

Doskonały wynik Lighthouse nie oznacza najwyższych pozycji. Lighthouse to przydatne narzędzie do znajdowania rzeczy do poprawy, ale sam wynik nie jest tym, czego Google używa do rankingu. Liczby wydajności, które Google faktycznie bierze pod uwagę przy rankingu, pochodzą od prawdziwych użytkowników, a nie z laboratorium Lighthouse. Dążenie do 100 jest świetne dla Twoich odwiedzających — po prostu nie oczekuj, że to będzie kod na skróty do rankingu.

Chcesz poznać wagi metryk, dlaczego wyniki skaczą między uruchomieniami i dokładnie jak Lighthouse ma się do Core Web Vitals? Przełącz się na zakładkę Zaawansowane.

TL;DR — Lighthouse to narzędzie open-source, automatyczne, które audytuje stronę w warunkach laboratoryjnych (symulowane Slow 4G + 4× ograniczenie CPU) i ocenia Wydajność, Dostępność, Najlepsze praktyki i SEO — PWA zostało usunięte w Lighthouse 12. Wynik Wydajności to ważona średnia pięciu metryk laboratoryjnych: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Pasma: 0–49 czerwony, 50–89 pomarańczowy, 90–100 zielony. To dane laboratoryjne, więc nie są sygnałem rankingowym Core Web Vitals, nie mogą mierzyć INP tak, jak robi to pole (używa TBT jako proxy) i różnią się między uruchomieniami. Zasila laboratoryjną połowę PageSpeed Insights; PSI dodaje dane terenowe CrUX na wierzch. 100 nie kupuje pozycji w rankingu.

Czym Lighthouse naprawdę jest

Własny opis Google jest najczystszą definicją: “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” Mechanika jest równie prosta — “give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.”

Ocenia dziś cztery kategorie: Wydajność, Dostępność, Najlepsze praktyki i SEO. Jeśli czytałeś starsze przewodniki, które mówią o pięciu, są nieaktualne — kategoria PWA została usunięta w Lighthouse 12 (około 2024), zgodnie ze zaktualizowanymi kryteriami instalowalności Chrome. Więc jeśli wpis na blogu nadal cytuje wynik PWA, to znak, że pochodzi sprzed obecnej wersji.

Kluczowe jest jedno słowo: laboratorium. Lighthouse ładuje Twoją stronę w kontrolowanym, symulowanym środowisku, a nie od prawdziwych odwiedzających. Ten jeden fakt wyjaśnia prawie całe zamieszanie, jakie ludzie mają z tym narzędziem.

Jak działa Lighthouse — warunki laboratoryjne

Domyślnie Lighthouse używa symulowanego ograniczania przepustowości i robi to agresywnie. Wartości domyślne emulują mniej więcej średniej klasy urządzenie mobilne przy połączeniu Slow 4G:

• Sieć: preset mobilny Slow 4G — około 150 ms opóźnienia i 1,6 Mb/s w dół / 750 Kb/s w górę. Google opisuje to jako emulację “the ~85th percentile mobile connection speed even when run on much faster fiber connections.”
• CPU: stały mnożnik 4× CPU, symulujący procesor telefonu ze średniej półki na Twoim szybszym sprzęcie stacjonarnym.

To jest celowe. Lighthouse nie próbuje Ci powiedzieć “tak szybka jest Twoja strona dla wszystkich”. To test wytrzymałościowy strony wobec grupy wolniejszej niż przeciętna, aby ujawnić problemy, które ukrywa Twój szybki laptop. Dlatego strona, która dla Ciebie wydaje się błyskawiczna, może uzyskać wynik 60 — Ty masz wydajnego MacBooka na światłowodzie; test to budżetowy Android na przeciętnej sieci.

Jedna ważna różnica, którą warto zapamiętać: symulowane ograniczanie przepustowości (domyślne) to nie to samo co DevTools / stosowane ograniczanie. Symulowane ograniczanie modeluje, jak strona załadowałaby się w tych warunkach, na podstawie wstępnej obserwacji bez ograniczeń — Google zauważa, że to podejście jest “both very fast and deterministic.” Ograniczanie w stylu DevTools faktycznie spowalnia żądania, co według Google “not a sufficient model of a slow connection.” Do powtarzalnych pomiarów preferowany jest domyślny tryb symulowany.

Wynik Performance — jak jest obliczany

Wynik Performance to “a weighted average of the metric scores.” Te wagi zostały ustalone w Lighthouse 10 i pozostają aktualną opublikowaną tabelą. Lighthouse 13 (wdrożony w 2026) mówi to wprost: skonsolidował zestaw audytów wydajnościowych niepunktowanych we wspólne “Insights” używane również przez panel Performance w DevTools, ale stwierdza, że w tej wersji “no changes to the performance scoring” — punktacja opiera się na metrykach poniżej, a nie na nazwach audytów, a te się nie zmieniły. Na wynik składa się pięć metryk:

Kilka rzeczy, które warto tu zinternalizować:

• TBT ma największą wagę (30%). To laboratoryjny odpowiednik responsywności. First Input Delay (FID) zostało usunięte, podobnie jak starsze metryki, takie jak Time to Interactive i First Meaningful Paint — zostały wycofane.
• Speed Index to metryka Lighthouse, a nie Core Web Vital. Nadal liczy się w 10% wyniku Performance Lighthouse, mimo że nie jest jedną z istotnych dla rankingu CWV Google.
• Każda metryka jest oceniana według krzywej, a nie stałego progu. Lighthouse bierze surową wartość (zwykle w milisekundach) i mapuje ją na rozkład log-normalny zbudowany na podstawie rzeczywistych danych z HTTP Archive. Punkty kontrolne Google: 25. percentyl tych danych daje wynik 50, a 8. percentyl daje 90. Tak więc wynik 90+ oznacza, że jesteś mniej więcej w górnych ~8% stron pod względem tej metryki — dlatego ostatnie kilka punktów jest tak trudne do zdobycia.
• Tylko wyniki metryk zmieniają liczbę. Sekcje Opportunities i Diagnostics w raporcie to wskazówki — mówią Ci, co naprawić — ale nie zmieniają bezpośrednio wyniku Performance. Ich naprawa poprawia metryki, a metryki zmieniają wynik.

Dlaczego Twój wynik zmienia się między uruchomieniami

To skarga, którą słyszę najczęściej: „Uruchomiłem to dwa razy i dostałem 84, a potem 91 — czy to zepsute?” Nie. Google jest jednoznaczne: „A lot of the variability in your overall Performance score and metric values is not due to Lighthouse.” (tłumaczenie) „Duża część zmienności w Twoim ogólnym wyniku Performance i wartościach metryk nie wynika z Lighthouse.” Gdy liczba skacze, zwykle winne są zmieniające się warunki bazowe:

• Testy A/B lub różne reklamy serwowane przy każdym załadowaniu
• Zmiany trasowania internetowego — zarówno w Twojej sieci lokalnej, jak i na dłuższej ścieżce między regionami, którą pokonuje żądanie
• Sam serwer WWW odpowiadający z niestałą prędkością
• Testowanie na różnym sprzęcie (szybki komputer stacjonarny vs. zmęczony laptop) — ograniczanie CPU jest względne do maszyny hostującej, więc mnożnik „4×” znaczy co innego na szybkiej maszynie niż na wolnej
• Rozszerzenia przeglądarki, które wstrzykują JavaScript lub dodatkowe żądania sieciowe
• Oprogramowanie antywirusowe lub inne procesy w tle konkurujące o zasoby

Na przykład: uruchom ten sam URL dwa razy, a jedno przejście przypadkiem załaduje cięższą kreację reklamową lub trafi na wolniejszą odpowiedź serwera — audyty z tego przejścia odzwierciedlają to jedno załadowanie, a nie wadę, którą wprowadziłeś. Traktuj to jako pojedynczą próbkę, a nie werdykt.

Właściwy model myślowy, wprost z dokumentacji, to traktowanie wydajności jako rozkładu wyników, a nie pojedynczej liczby. Uruchom to kilka razy — najlepiej w oknie incognito z wyłączonymi rozszerzeniami, na dopasowanym sprzęcie i warunkach sieciowych — i patrz na zakres lub medianę, a nie na jeden wynik. Gdy później będziesz porównywać uruchomienia, zanotuj wersję Lighthouse, tryb uruchomienia i metodę ograniczania przepustowości obok wyniku; wynik z innej wersji lub konfiguracji nie jest porównaniem jeden do jednego, nawet jeśli liczba wygląda podobnie.

Jak odpowiedzialnie uruchamiać Lighthouse

Używaj Lighthouse jako kontrolowanej diagnostyki, a nie werdyktu jednym kliknięciem:

1. Testuj dokładnie wdrożony URL, a nie inny szablon ani nieopublikowaną lokalną kompilację.
2. Dopasuj profil urządzenia, metodę ograniczania przepustowości, wersję Lighthouse, stan pamięci podręcznej, uwierzytelnianie, stan zgody i geografię testu dla każdego porównania.
3. Rozpoczynaj każde uruchomienie od świeżej nawigacji. Zmiana rozmiaru już załadowanej strony desktopowej do widoku mobilnego nie odtwarza mobilnej nawigacji, sekwencji żądań ani odpowiedzi serwera.
4. Uruchom co najmniej trzy razy. Podawaj medianę jako główny wynik i zachowaj poszczególne uruchomienia, zakres, znaczniki czasu, ostrzeżenia i ślady, aby wartość odstająca była widoczna, a nie po cichu odrzucona.
5. Porównuj przed i po w tych samych warunkach. Jeśli usługa testowa działa z innego regionu, zanotuj to: dodatkowa odległość sieciowa lub inny brzeg CDN może zmienić czasy serwera i ładowania bez zmiany kodu.
6. Sprawdź CrUX osobno, zanim wyciągniesz wniosek o prawdziwych użytkownikach. Lepsza mediana laboratoryjna wspiera „ta zmiana poprawiła ten kontrolowany test”, a nie „użytkownicy przechodzą teraz Core Web Vitals”.

Dowody wspierają różne wnioski:

To jest zgodne z własnym modelem rozkładu Lighthouse dla zmienności wyników i utrzymuje rozróżnienie laboratorium/teren. Evidence for this claim Lighthouse performance scores are weighted from lab metrics; 90–100 is good, 50–89 needs improvement, and 0–49 is poor. Scope: Current published Lighthouse performance-scoring model; metric weights can change by Lighthouse version. Confidence: high · Verified: 2026-07-14 Chrome Developers: Performance scoring

Lighthouse a PageSpeed Insights — rozróżnienie, które ma znaczenie

Te są ciągle mylone, więc bądź precyzyjny:

• Lighthouse to silnik. Generuje dane laboratoryjne — wyniki Performance, Accessibility, Best Practices i SEO.
• PageSpeed Insights to interfejs webowy, który uruchamia Lighthouse oraz dodaje dane terenowe z Chrome UX Report (CrUX) — prawdziwe Core Web Vitals od anonimowych rzeczywistych użytkowników, wyświetlane, gdy dla danego adresu URL lub origin jest wystarczająco dużo danych.

Więc w PSI patrzysz na dwa różne zestawy danych obok siebie. Sekcja „field data” na górze (rzeczywiści użytkownicy, z CrUX) jest oddzielona od sekcji danych laboratoryjnych Lighthouse poniżej — i często się ze sobą nie zgadzają. Gdy ktoś mówi „mój wynik PageSpeed Insights”, prawie zawsze ma na myśli wynik wydajności Lighthouse, a nie dane terenowe.

Lighthouse a Core Web Vitals — jak się mają do siebie

Lighthouse mierzy niektóre Core Web Vitals w laboratorium: raportuje LCP i CLS jako metryki laboratoryjne. Ale jest twardy limit:

Lighthouse nie może zmierzyć INP tak, jak robi to pole. Interakcja do następnego malowania wymaga rzeczywistych interakcji użytkownika, aby ją zmierzyć — w laboratorium nie ma prawdziwego użytkownika klikającego. Dlatego Lighthouse używa Total Blocking Time jako laboratoryjnego proxy dla responsywności. TBT koreluje z INP, ale pozytywny wynik TBT nie gwarantuje pozytywnego INP dla rzeczywistych użytkowników. Są powiązane, ale to nie to samo.

To jest sedno różnicy między laboratorium a polem. Dane terenowe — z CrUX, widoczne w Search Console i na górze PageSpeed Insights — odzwierciedlają rzeczywistych użytkowników i zasilają sygnały page experience Google. Dane laboratoryjne Lighthouse służą do debugowania i wychwytywania regresji przed wdrożeniem. Zalecenia Google to „priorytetowo traktuj dane terenowe, aby zrozumieć doświadczenia rzeczywistych użytkowników” i używaj „danych laboratoryjnych do debugowania, testowania funkcji przed wdrożeniem.”

Gdzie to uruchomić

Ten sam silnik, różne powierzchnie:

• Chrome DevTools — wbudowany w przeglądarkę (panel Lighthouse). Najlepszy dla stron za logowaniem, ponieważ możesz audytować uwierzytelnione strony.
• PageSpeed Insights — interfejs webowy bez instalacji na pagespeed.web.dev; uruchamia Lighthouse i dodaje dane terenowe CrUX.
• CLI — npm install -g lighthouse, następnie lighthouse <url>; można skryptować.
• Moduł Node — importuj go programowo do własnych narzędzi i CI.
• Lighthouse CI — oficjalna konfiguracja do wychwytywania regresji wydajności przy każdym wdrożeniu. Przepływ pracy to collect → assert → upload: collect uruchamia Lighthouse wielokrotnie dla danego adresu URL (domyślnie trzy razy) i bierze medianę raportu, a nie ufa jednemu przejściu; assert sprawdza ten raport względem skonfigurowanych progów — ustaw na warn lub error dla każdej kategorii lub metryki; upload przechowuje raport, abyś mógł śledzić trendy w kolejnych buildach. Traktuj progi jako politykę regresji swojego zespołu, a nie werdykt dotyczący danych terenowych ani gwarancję pozycji — wychwytują „to się pogorszyło”, a nie potwierdzają „to jest szybkie dla użytkowników”.
• Rozszerzenie Chrome — istnieje, ale DevTools to zalecana ścieżka w przeglądarce.

Przepływy pracy CLI i Node wymagają lokalnej instalacji Chrome do sterowania.

Mity, które warto obalić

• „Wynik 100 w Lighthouse = najwyższe pozycje.” Nie. Wynik wydajności to dane laboratoryjne; nie jest sygnałem rankingowym. Sygnały page experience Google używają danych terenowych Core Web Vitals (CrUX), a nawet to jest jeden lekki sygnał pośród wielu — trafność i jakość treści dominują. Celuj w wysoki wynik, bo to dobre dla użytkowników, a nie dlatego, że to dźwignia rankingowa.
• „Lighthouse = dane terenowe / to, czego doświadczają prawdziwi użytkownicy.” Nie. To ograniczone warunki laboratoryjne, gorsze niż to, co widzi większość prawdziwych użytkowników. Prawdziwi użytkownicy mają ciepłe pamięci podręczne, bfcache i różne urządzenia. Lighthouse to test warunków skrajnych w stylu najgorszego przypadku, a nie odczyt przeciętnego użytkownika.
• „PageSpeed Insights to Lighthouse.” Częściowo. PSI uruchamia Lighthouse dla sekcji laboratoryjnej i dodaje CrUX dla sekcji terenowej. Liczby terenowe — te powiązane z page experience — pochodzą z CrUX, a nie z Lighthouse.
• „Kategoria PWA nadal się liczy.” Nie. PWA została usunięta jako punktowana kategoria w Lighthouse 12.

Podsumowanie

Lighthouse to jedno z najbardziej przydatnych darmowych narzędzi w technicznym SEO i wydajności webowej — szybki, powtarzalny sposób na znalezienie tego, co spowalnia stronę, oraz na ochronę przed regresjami w CI. Trzymaj je jednak na właściwej wysokości: to diagnostyka laboratoryjna, a nie werdykt o doświadczeniach prawdziwych użytkowników ani wynik rankingowy. Używaj go do znajdowania i naprawiania; używaj danych terenowych (CrUX, Core Web Vitals w Search Console), aby ocenić, czy prawdziwi użytkownicy faktycznie mają dobre doświadczenia.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Lighthouse = open-source’owe, zautomatyzowane narzędzie audytowe (lab) od zespołu Chrome. Podaj mu URL; audytuje stronę i ocenia Wydajność, Dostępność, Najlepsze praktyki, SEO. PWA zostało usunięte w Lighthouse 12 (~2024).
• Lab, nie pole. Ładuje stronę przy symulowanym ograniczaniu przepustowości — mniej więcej Slow 4G + 4× CPU — celowo, aby uwidocznić, czego doświadczają wolniejsze urządzenia/sieci. Dlatego „szybka” strona może mieć niski wynik.
• Wynik wydajności = średnia ważona pięciu metryk lab: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. FID i First Meaningful Paint zniknęły.
• Zakresy: 0–49 czerwony (słaby), 50–89 pomarańczowy (wymaga poprawy), 90–100 zielony (dobry). Wyniki metryk są mapowane na krzywą log-normalną HTTP Archive, więc najwyższe punkty są najtrudniejsze. Opportunities/Diagnostics wskazują poprawki, ale nie zmieniają bezpośrednio wyniku.
• Wyniki różnią się między uruchomieniami — reklamy, testy A/B, rozszerzenia, warunki sieciowe/serwerowe oraz obciążenie maszyny (ograniczanie CPU jest względne do hosta). Traktuj to jako rozkład, nie pojedynczą liczbę; uruchamiaj w trybie incognito z wyłączonymi rozszerzeniami i zapisuj wersję Lighthouse oraz ustawienia, których używasz.
• Lighthouse CI automatyzuje to: zbiera wiele uruchomień (domyślnie trzy), bierze medianę i egzekwuje progi Twojego zespołu — polityka łapania regresji, a nie werdykt z danych terenowych.
• Lighthouse ≠ PageSpeed Insights: PSI uruchamia Lighthouse (lab) oraz dodaje dane terenowe CrUX (prawdziwi użytkownicy). Często się różnią.
• Lighthouse mierzy LCP/CLS w labie, ale nie może zmierzyć INP tak, jak robi to pole — używa TBT jako proxy. Dane terenowe (CrUX) odzwierciedlają prawdziwych użytkowników i zasilają sygnały doświadczenia strony.
• To nie jest sygnał rankingowy. Wynik 100 nie oznacza najwyższych pozycji, a niski wynik lab nie oznacza złego doświadczenia prawdziwych użytkowników. Używaj Lighthouse do debugowania; używaj danych terenowych do oceny.

Oficjalna dokumentacja

Dokumentacja głównego źródła od zespołu Google Chrome.

• Przegląd Lighthouse — czym jest Lighthouse, kategorie audytów i każdy sposób uruchomienia (DevTools, CLI, Node, PageSpeed Insights, rozszerzenie, Lighthouse CI).
• Ocena wydajności Lighthouse — wagi metryk, zakresy kolorów 0–49 / 50–89 / 90–100 oraz krzywa oceny log-normalnej.
• Audyty PWA Lighthouse — zawiera notę o wycofaniu usuniętej kategorii PWA.
• Ograniczanie przepustowości Lighthouse (GitHub) — symulowane vs. stosowane ograniczanie, preset Slow 4G i mnożnik 4× CPU.
• Dziennik zmian Lighthouse (GitHub) — zmiany w v12: usunięcie PWA, usunięcie First Meaningful Paint, podniesienie INP.
• Kalkulator wyników Lighthouse — wprowadź wartości metryk i zobacz wynik wydajności; przydatny do ustalania celów.

Lab vs. pole (web.dev)

• Metryki wydajności skoncentrowane na użytkowniku — dlaczego testowanie lab „niekoniecznie odzwierciedla, jak faktyczni użytkownicy doświadczają Twojej witryny”.

Cytaty ze źródła

Oświadczenia na piśmie z dokumentacji Lighthouse Google. Każdy link to link bezpośredni, który przeskakuje do cytowanego fragmentu na stronie źródłowej.

Czym jest Lighthouse i jak działa

• “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” — developer.chrome.com, Lighthouse overview. Przejdź do cytatu
• “Give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” — developer.chrome.com, Lighthouse overview. Przejdź do cytatu

Jak działa wynik wydajności

• “The Performance score is a weighted average of the metric scores.” — developer.chrome.com, Lighthouse performance scoring. Przejdź do cytatu
• “Once Lighthouse has gathered the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution.” — developer.chrome.com, Lighthouse performance scoring. Przejdź do cytatu
• O przedziałach wyników: “0 to 49 (red): Poor” — z 50–89 pomarańczowym (wymaga poprawy) i 90–100 zielonym (dobrze). Przejdź do cytatu

Dlaczego wyniki się różnią

• “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse. When your Performance score fluctuates it’s usually because of changes in underlying conditions.” — developer.chrome.com, Lighthouse performance scoring. Przejdź do cytatu

Laboratorium a pole

• “While testing in the lab is a reasonable proxy for performance, it isn’t necessarily reflective of how actual users experience your site.” — web.dev, User-centric performance metrics. Przejdź do cytatu

Uzyskanie wiarygodnego odczytu Lighthouse — lista kontrolna

Zanim zaczniesz działać na podstawie wyniku Lighthouse, upewnij się, że liczba coś znaczy:

• Uruchom go w oknie incognito z wyłączonymi rozszerzeniami (rozszerzenia wstrzykują JS i fałszują wynik).
• Uruchom go kilka razy i obserwuj zakres — traktuj go jako rozkład, a nie pojedynczą liczbę.
• Upewnij się, że porównujesz ten sam format urządzenia za każdym razem (mobile vs. desktop — ograniczanie przepustowości różni się).
• Wiedz, który zestaw danych czytasz: lab (Lighthouse) vs. field (CrUX) w PageSpeed Insights. Nie mieszaj ich.
• W przypadku pytań o ranking/doświadczenie strony patrz na dane terenowe (Core Web Vitals w Search Console / CrUX), a nie na wynik laboratoryjny Lighthouse.
• Pamiętaj, że Lighthouse nie może zmierzyć INP tak jak dane terenowe — TBT to przybliżenie, a nie gwarancja.
• Poprawiaj na podstawie list Opportunities/Diagnostics, ale weryfikuj zmianę, obserwując ruch metriki (tylko metryki zmieniają wynik).
• Do powtarzalnych pomiarów w automatyzacji używaj Lighthouse CI z budżetami, zamiast oceniać pojedyncze uruchomienia.
• Kontroluj, co strona pokazuje przy ładowaniu: banery cookie/zgody, stan logowania i pamięć podręczną (zimną vs. ciepłą) — wszystko to zmienia uruchamiane audyty — wybierz jeden stan i bądź w nim konsekwentny.
• Uważaj na niedeterministyczne treści — testy A/B, rotujące reklamy i inne skrypty firm trzecich mogą serwować inną treść przy każdym uruchomieniu i zmieniać wynik niezależnie od tego, co zmieniłeś.
• Pozwól stronie faktycznie dokończyć ładowanie przed uruchomieniem audytu (lub użyj trybu, który na to czeka) — przedwczesne przerwanie uruchomienia błędnie odczytuje stronę.
• Zapisz wersję Lighthouse i ustawienia uruchomienia (tryb, metoda ograniczania przepustowości, urządzenie) wraz z wynikiem — „taki sam” wynik z innej wersji lub konfiguracji nie jest faktycznie porównywalny.
• Zignoruj każdy przewodnik, który nadal ocenia kategorię PWA — została ona usunięta w Lighthouse 12.

Wynik wydajności Lighthouse — ściąga

Pięć metryk i ich wagi (wagi Lighthouse 10)

Wycofane / usunięte: FID, Time to Interactive, First Meaningful Paint.

Kolorowe pasma wyników

Odwzorowane na log-normalną krzywą HTTP Archive: ~25. percentyl → 50, ~8. percentyl → 90. Ostatnie kilka punktów jest najtrudniejsze do zdobycia.

Domyślne warunki laboratoryjne

• Sieć: mobile Slow 4G (~150 ms opóźnienia, ~1,6 Mbps w dół / 750 Kbps w górę)
• CPU: stały mnożnik 4× (średniej klasy mobile na sprzęcie desktopowym)
• Ograniczanie przepustowości: symulowane domyślnie (szybkie, deterministyczne), nie DevTools/zastosowane

Lighthouse vs. PageSpeed Insights

Szybkie fakty

• Kategorie obecnie: Performance, Accessibility, Best Practices, SEO (PWA usunięte w Lighthouse 12).
• To nie jest sygnał rankingowy. 100 ≠ najwyższe pozycje.
• Nie może zmierzyć INP tak jak dane terenowe — używa TBT jako przybliżenia.
• Wyniki różnią się między uruchomieniami — to normalne.

Sposoby uruchamiania Lighthouse (i powiązanych narzędzi)

• Chrome DevTools — panel Lighthouse — wbudowany w Chrome; najlepszy do audytowania stron za logowaniem.
• PageSpeed Insights (pagespeed.web.dev) — bez instalacji; uruchamia Lighthouse i dodaje dane terenowe CrUX.
• Lighthouse CLI — npm install -g lighthouse, następnie lighthouse <url>; skryptowalny, wymaga lokalnego Chrome.
• Moduł Node Lighthouse — wbuduj go programowo do własnych narzędzi.
• Lighthouse CI (@lhci/cli) — uruchamiaj Lighthouse przy każdym wdrożeniu, ustaw budżety i powoduj niepowodzenie kompilacji przy regresjach. Właściwe narzędzie, aby wynik nie spadał po cichu.
• Kalkulator wyników Lighthouse (scorecalc) — wprowadź wartości metryk, aby zobaczyć wynik Performance i wyznaczyć realistyczne cele.
• Rozszerzenie Chrome — dostępne, ale DevTools to zalecana trasa w przeglądarce.

Aby uzyskać dane rzeczywistych użytkowników (terenowe) do pary z tymi narzędziami laboratoryjnymi, sprawdź raport Core Web Vitals w Google Search Console oraz sekcję terenową CrUX w PageSpeed Insights.

Nawyki Lighthouse, które tworzą fałszywą pewność

• Dążenie do 100 jako celu biznesowego. Doskonały wynik laboratoryjny nie jest wzmocnieniem pozycji i może odwracać uwagę od terenowych Core Web Vitals i rzeczywistych wyników użytkowników. Użyj raportu, aby znaleźć wąskie gardła, a następnie zweryfikuj, czy użytkownicy odnieśli korzyści.
• Traktowanie jednego uruchomienia jako werdyktu. Lighthouse to symulowany test i naturalnie się zmienia. Uruchom go kilka razy w tych samych warunkach i szukaj spójnego wzorca, zamiast reagować na jeden wynik.
• Nazywanie laboratoryjnego TBT tym samym co terenowy INP. TBT to użyteczny laboratoryjny wskaźnik blokowania głównego wątku; INP mierzy rzeczywiste interakcje w terenie. Dobry TBT to dowód, nie dowód, że INP jest dobry.
• Naprawianie każdego audytu w podanej kolejności. Szacunki możliwości nakładają się, a niektóre audyty mają niewielki wpływ na rzeczywiste wąskie gardło strony. Zacznij od śladu, największych ważonych metryk i zasobów za nie odpowiedzialnych.
• Porównywanie wyników mobilnych i desktopowych bezpośrednio. Ich profile emulacji i rozkłady wyników różnią się. Porównuj podobne z podobnym.

Zmiany wyników Lighthouse między uruchomieniami

Objaw: Ta sama strona zmienia pasma kolorów bez wdrożenia.

Prawdopodobna przyczyna: Zmienna odpowiedź serwera, skrypty stron trzecich, obciążenie współdzielonej maszyny lub różne ustawienia testu zmieniły syntetyczne uruchomienie.

Poprawka i potwierdzenie: Dopasuj URL, profil urządzenia, ograniczanie przepustowości, stan pamięci podręcznej i lokalizację testu; uruchom kilka testów; następnie porównaj medianę śladu i czasy metryk.

Terenowe Core Web Vitals przechodzą, ale Lighthouse jest czerwony

Objaw: Dane terenowe PSI przechodzą, podczas gdy wynik Performance Lighthouse jest słaby.

Prawdopodobna przyczyna: Obie sekcje mierzą różne populacje: CrUX podsumowuje rzeczywistych użytkowników w czasie, podczas gdy Lighthouse uruchamia jedno symulowane ładowanie strony.

Poprawka i potwierdzenie: Traktuj ocenę terenową jako wynik użytkownika i użyj śladu laboratoryjnego, aby odtworzyć i zdiagnozować scenariusz wolnego urządzenia. Potwierdź każdą poprawkę zarówno w powtarzanych uruchomieniach laboratoryjnych, jak i w następnym oknie raportowania danych terenowych.

Lighthouse nie może zmierzyć INP

Objaw: Raport pokazuje TBT, ale brak laboratoryjnej wartości INP.

Prawdopodobna przyczyna: INP wymaga rzeczywistych interakcji podczas wizyty na stronie; uruchomienie Lighthouse tylko z nawigacją nie ma reprezentatywnej historii interakcji.

Poprawka i potwierdzenie: Użyj TBT i śladu, aby znaleźć długie zadania w laboratorium, a następnie zmierz INP za pomocą danych terenowych lub nagrania skoncentrowanego na interakcjach.

Audyt utrzymuje się po oczywistej poprawce

Objaw: Lighthouse nadal flaguje zasób po jego optymalizacji lub usunięciu.

Prawdopodobna przyczyna: Zbuforowana odpowiedź, inny szablon, kopia strony trzeciej lub inne żądanie w łańcuchu nadal wyzwala audyt.

Poprawka i potwierdzenie: Przetestuj dokładny wdrożony URL z zimną pamięcią podręczną, otwórz listę zasobów dotkniętych audytem i przypisz każde wymienione żądanie do jego właściciela.

Sprawdź się: Google Lighthouse

Pięć szybkich pytań o dane i wyniki Lighthouse. Wybierz odpowiedź na każde, a następnie sprawdź.

Zasoby warte Twojego czasu

Oficjalne

• Przegląd Lighthouse — definitywne co/jak/gdzie uruchomić.
• Ocena wydajności Lighthouse — wagi, przedziały i krzywa punktacji.
• Dokumentacja throttlingu Lighthouse (GitHub) — szczegóły warunków laboratoryjnych.
• Kalkulator punktacji Lighthouse — odwróć inżynierię celów metryk dla wyniku.
• Metryki wydajności skoncentrowane na użytkowniku — argument laboratorium vs. prawdziwi użytkownicy, od Google.

Gdzie pasuje Lighthouse

• Połącz wynik laboratoryjny z danymi terenowymi: raport Core Web Vitals w Google Search Console i sekcja CrUX w PageSpeed Insights. Laboratorium znajduje problemy; dane terenowe mówią, czy odczuwają je prawdziwi użytkownicy.

Z branży

• Różnice między danymi terenowymi a laboratoryjnymi (web.dev) — własne zestawienie Google, kiedy ufać danym laboratoryjnym vs. terenowym i dlaczego się różnią.
• Core Web Vitals (web.dev) — kanoniczne źródło na temat tego, które metryki CWV Lighthouse może i nie może mierzyć, w tym luka INP.
• Largest Contentful Paint (web.dev) — dogłębna analiza progów LCP i dlaczego odczyty laboratoryjne i terenowe często się różnią.
• Lighthouse CI na GitHub — oficjalne repozytorium i przewodnik konfiguracji integracji Lighthouse z automatycznymi potokami CI/CD.
• HTTP Archive Web Almanac — rozdział o wydajności — coroczne dane o rzeczywistych wynikach Lighthouse i wskaźnikach zdawalności Core Web Vitals na milionach stron; przydatne do porównywania swoich wyników z siecią.
• web.dev — Mierz wydajność strony — zalecany przez Google punkt wyjścia do łączenia wyników Lighthouse z narzędziami danych terenowych.

Liczby, które warto cytować

• Wagi wyniku wydajności (Lighthouse 10): TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Źródło
• Przedziały wyników: 0–49 czerwony (słaby), 50–89 pomarańczowy (wymaga poprawy), 90–100 zielony (dobry). Wynik 90 odpowiada mniej więcej 8. percentylowi danych HTTP Archive; wynik 50 — 25. percentylowi. Źródło
• Domyślny throttling: mobilny Slow 4G (~150 ms opóźnienia, ~1,6 Mbps w dół) plus 4× mnożnik CPU — emulujący mniej więcej ~85. percentyl połączenia mobilnego. Źródło
• Kategorie: cztery obecnie (Performance, Accessibility, Best Practices, SEO) — PWA usunięte w Lighthouse 12 (~2024). Źródło

Dziennik zmian