PageSpeed Insights przeszedł na Lighthouse 13.6.0 i od teraz inaczej symuluje ładowanie strony. Google zapowiada, że symulowane FCP i LCP będą dokładniejsze i „zazwyczaj dadzą wyższe wyniki”. To oznacza, że część stron zobaczy skok oceny wydajności, choć ich właściciele nie zmienili ani jednej linijki kodu.
Dla zespołów SEO i developerów to ważny sygnał: wykres wyników laboratoryjnych w raportach klientów może w tym tygodniu podskoczyć, a ten skok nie musi mieć nic wspólnego z ostatnimi optymalizacjami. Wyjaśniamy, co dokładnie zmieniło się w silniku symulacji, kogo zmiana dotyczy najbardziej i jak nie dać się złapać na fałszywym sukcesie.
Kontekst: jak PageSpeed Insights liczy wynik laboratoryjny
Wynik wydajności w PageSpeed Insights (PSI) pochodzi z dwóch zupełnie różnych źródeł. Pierwsze to dane terenowe, czyli rzeczywiste wizyty użytkowników Chrome z ostatnich 28 dni, zbierane w raporcie CrUX (Chrome User Experience Report). Drugie to test laboratoryjny wykonywany przez Lighthouse, który generuje znaną wszystkim ocenę w skali 0–100 i listę rekomendacji.
Kluczowe jest to, jak Lighthouse udaje wolne łącze. Domyślnie narzędzie nie dławi sieci w czasie rzeczywistym. Ładuje stronę z pełną prędkością, zapisuje wszystkie żądania i zadania przeglądarki, a następnie silnik o nazwie Lantern szacuje, jak ta sama strona ładowałaby się na wolniejszym połączeniu i słabszym procesorze. Dokumentacja throttlingu Lighthouse wprost wskazuje, że ten tryb symulowany odpowiada konfiguracji używanej w PageSpeed Insights.
Symulacja ma jedną dużą zaletę: jest szybka i względnie powtarzalna. Ma też wadę: jej wynik zależy od modelu, a nie od pomiaru. Gdy Google poprawia model, zmieniają się wyniki, nawet jeśli strona pozostaje identyczna. Dokładnie to wydarzyło się teraz.
Jeśli chcesz uporządkować sobie różnice między narzędziami laboratoryjnymi a danymi terenowymi, zebraliśmy je w przeglądzie narzędzi do diagnostyki wydajności.
Kluczowe fakty: co przynosi Lighthouse 13.6.0
Wersja 13.6.0 trafiła do repozytorium GoogleChrome/lighthouse na GitHubie 27 października 2026 roku. W notatkach do wydania zespół napisał, że spodziewa się jej w narzędziach deweloperskich Chrome 159 oraz w PageSpeed Insights „w ciągu tygodnia”. Termin dotrzymano: Barry Pollard, Web Performance Developer Advocate w zespole Chrome, ogłosił w serwisie Bluesky, że PSI działa już na Lighthouse 13.6.0. Jak podaje Search Engine Journal (autor: Matt G. Southern), Chrome 159 jest obecnie w kanałach Dev i Canary, a harmonogram wydań przewiduje jego stabilną wersję na 8 grudnia.
| Element | Lighthouse 13.5 | Lighthouse 13.6.0 |
|---|---|---|
| Wykrywanie zasobów blokujących renderowanie | Na podstawie priorytetu pobierania (fetch priority) każdego żądania | Na podstawie flagi renderBlocking raportowanej przez Chrome; priorytet tylko jako rezerwa, gdy flagi brak |
| Szacowanie LCP, gdy elementem LCP jest tekst w tej samej klatce co FCP | Zbiór żądań mógł obejmować wszystko, co pobrano przed LCP | Te same żądania i zadania, których silnik używa do obliczenia FCP |
| Protokół HTTP/3 | Traktowany mniej precyzyjnie | Traktowany jako multipleksowany |
| Szacowanie RTT i przepustowości originu | Starsza logika | Poprawione, razem z obsługą przekierowań |
| Audyt ARD dla agentów AI | Szukał plików ai-catalog | Zgodny z ARD v0.91: najpierw linia Agentmap, link rel=”ard” lub nagłówek Link oraz /.well-known/ard.json |
| CLI | Jeden URL na uruchomienie | Audyt wielu adresów jednocześnie lub z pliku (–url-file) |
Zmiana nr 1: Chrome sam mówi, co blokuje renderowanie
Do tej pory Lantern zgadywał, czy dany zasób blokuje renderowanie, patrząc na jego priorytet pobierania. To przybliżenie bywało mylące: zasób o wysokim priorytecie nie zawsze wstrzymuje pierwsze malowanie, a zasób o niższym priorytecie czasem je wstrzymuje. W wersji 13.6 silnik korzysta z informacji renderBlocking, którą przeglądarka przekazuje przez protokół DevTools dla każdego żądania. Priorytet pozostał tylko jako plan awaryjny, gdy tej informacji brakuje.
W praktyce oznacza to, że symulacja przestaje „karać” stronę za zasoby, które realnie nie opóźniają renderowania. Stąd bierze się zapowiadany przez Google wzrost wyników FCP.
Zmiana nr 2: tekstowe LCP liczone jak FCP
Druga poprawka dotyczy sytuacji, w której największym elementem w widoku jest tekst, a ten tekst pojawia się w tej samej klatce co pierwsza treść strony. Wtedy FCP i LCP to w rzeczywistości ten sam moment. Mimo to stary model potrafił wyliczyć LCP znacznie później niż FCP, bo do obliczeń wciągał wszystkie żądania wykonane przed LCP, także te, które nie miały żadnego wpływu na wyświetlenie tekstu.
Problem szczegółowo opisał na GitHubie Ivan Akulov, pokazując stronę testową zbudowaną we Framerze. Jedyną treścią nad linią załamania był tekst, a jeden element pełnił rolę zarówno FCP, jak i LCP. Lighthouse raportował LCP dużo później niż FCP. Co gorsza, dodanie preloadu modułów JavaScript poprawiało realną interaktywność strony, ale pogarszało symulowane LCP. Optymalizacja, która pomagała użytkownikom, w raporcie wyglądała jak regres. Według relacji SEJ Pollard podziękował Akulovowi, pisząc, że to jego zgłoszenie „zapoczątkowało część tych usprawnień”. Zespół Lighthouse zamknął zgłoszenie jako zrealizowane w ramach aktualizacji Lantern w wersji 13.6.
Zmiana nr 3: dokładniejszy model sieci
Notatki do wydania wymieniają też aktualizację biblioteki trace_engine do wersji 0.0.66 i 0.0.67. Za tym technicznym opisem kryje się kilka poprawek modelu sieci: HTTP/3 jest traktowany jako protokół multipleksowany, Lantern poprawnie uwzględnia nadmiarowe bajty pobrane przez HTTP/2, żądania bez połączenia nie są już liczone jako aktywne połączenia, a szacowanie opóźnień (RTT) i przepustowości dla poszczególnych originów oraz obsługa przekierowań zostały poprawione. Naprawiono również rozbicie symulowanego LCP na fazy oraz obsługę nawigacji w trybie trace.
Kogo zmiana dotknie najbardziej
Google nie podało liczb, o ile przeciętnie wzrosną wyniki. Pollard wskazał jednak wyraźnie grupę najbardziej narażoną na zmianę: strony „mocno zależne od JavaScriptu”. Jeden z developerów pochwalił się w mediach społecznościowych dużą poprawą wyników aplikacji SPA, powołując się na przykład react.dev. Pollard doprecyzował, że zmiana nie jest specyficzna dla SPA, ale „z większym prawdopodobieństwem wpłynie na witryny ciężkie od JavaScriptu”.
Na liście potencjalnych „wygranych” znajdą się więc przede wszystkim:
- sklepy i serwisy oparte na frameworkach JavaScript (React, Next.js, Vue, Nuxt), w których dużo modułów ładuje się na starcie,
- strony z kreatorów typu Framer czy Webflow, gdzie nad linią załamania dominuje tekst, a pod spodem pracuje ciężki bundle,
- landing page z dużym nagłówkiem tekstowym jako elementem LCP,
- witryny serwowane przez HTTP/3, którym dotąd szkodził uproszczony model połączeń.
Klasyczne strony WordPressa z obrazem jako elementem LCP mogą odczuć zmianę słabiej, bo poprawka dotycząca LCP obejmuje konkretnie przypadek tekstowy. Zmiana w wykrywaniu zasobów blokujących renderowanie dotyczy jednak wszystkich, więc niewielkie przesunięcia FCP są możliwe praktycznie wszędzie.
Warto pamiętać też o drugiej stronie medalu. Na GitHubie wciąż otwarte jest zgłoszenie, które opisuje sytuację odwrotną: symulowane LCP w Lantern wychodzi wyższe niż zmierzone na dużych serwisach JavaScript i SPA. Wersja 13.6 nie zamyka więc tematu rozjazdu między symulacją a rzeczywistością.
Co to znaczy dla SEO i AIO
Ranking się nie zmienia, raporty tak
Najważniejsza rzecz na początek: ta aktualizacja dotyczy wyłącznie testu laboratoryjnego. Ani Google, ani Search Engine Journal nie wspominają o jakimkolwiek wpływie na dane terenowe CrUX. Sygnały Core Web Vitals, które Google wykorzystuje w ocenie strony, opierają się na doświadczeniach prawdziwych użytkowników, a nie na wyniku Lighthouse. Wyższa ocena w PSI nie przełoży się więc na pozycje, a żadna strona nie straci ruchu dlatego, że silnik symulacji stał się dokładniejszy.
Różnicę między metrykami laboratoryjnymi a terenowymi omawiamy szerzej w tekście o tym, co naprawdę wpływa na LCP, INP i CLS.
Ryzyko numer jeden: fałszywe przypisanie sukcesu
Dużo większy problem dotyczy komunikacji. Agencja, która w zeszłym tygodniu wdrożyła optymalizację JavaScriptu, a w tym tygodniu zobaczy skok wyniku PSI o kilkanaście punktów, będzie miała pokusę, by przypisać cały wzrost swojej pracy. Część tego wzrostu może jednak pochodzić z samej zmiany wersji Lighthouse. SEJ zwraca uwagę, że wykresy śledzące wyniki laboratoryjne w czasie mogą pokazać skokową zmianę dokładnie w momencie przejścia na 13.6.
Dotyczy to także narzędzi monitorujących, które korzystają z API PageSpeed Insights. Jeśli Twój dashboard odpytuje PSI co dzień, na osi czasu pojawi się sztuczny próg. Dobrą praktyką jest dodanie adnotacji z datą przełączenia, żeby za trzy miesiące nikt nie analizował „tajemniczego skoku” z początku listopada.
Mniej kar za dobre optymalizacje
Pozytywny aspekt jest równie istotny. Przykład z Framerem pokazał, że stary model potrafił karać rozsądne decyzje, takie jak preload kluczowych modułów. Developerzy, którzy optymalizowali pod wynik Lighthouse, a nie pod użytkownika, czasem cofali dobre zmiany tylko dlatego, że raport robił się czerwony. Dokładniejsza symulacja zmniejsza ten konflikt interesów. Rekomendacje z PSI powinny teraz rzadziej stać w sprzeczności z tym, co widać w danych terenowych.
Wątek AIO: audyt ARD dogania specyfikację
Dla czytelników zainteresowanych optymalizacją pod agentów AI ciekawa jest jeszcze jedna zmiana. Wprowadzony w Lighthouse 13.5 audyt ARD (Agent Resource Discovery), który sprawdza, czy strona udostępnia agentom AI katalog swoich usług, został dostosowany do specyfikacji ARD v0.91. Lighthouse najpierw szuka linii Agentmap, linku rel=”ard” lub nagłówka Link oraz pliku /.well-known/ard.json, a dopiero potem starszych nazw ai-catalog. Plik ard.json zastępuje ai-catalog.json.
Przy premierze tego audytu we wrześniu pisaliśmy, że nowy audyt ARD rozjeżdża się ze specyfikacją. Wersja 13.6 w dużej mierze ten rozjazd usuwa. Jeśli wdrożyłeś plik ai-catalog.json pod wcześniejszą wersję audytu, to dobry moment, by sprawdzić, czy nie warto przejść na ard.json.
Bonus dla audytorów: wiele adresów w jednym poleceniu
W wersji CLI Lighthouse 13.6 pozwala przekazać kilka adresów URL jako argumenty lub wczytać je z pliku przez flagę –url-file. Domyślne nazwy plików raportu zawierają teraz ścieżkę URL, więc przy audycie kilkudziesięciu podstron nie trzeba ręcznie pilnować nazewnictwa. Dla zespołów, które dotąd pisały własne skrypty pętli, to drobna, ale realna oszczędność czasu.
Reakcje branży
Pierwsze reakcje w środowisku web performance są przeważnie pozytywne, choć ostrożne. Ivan Akulov, którego zgłoszenie stało się jednym z impulsów do zmian, od miesięcy pokazywał przypadki, w których Lighthouse dawał wyniki sprzeczne z intuicją i z danymi realnych użytkowników. Jego przykład z preloadem modułów, który pomagał użytkownikom i jednocześnie szkodził wynikowi, był często cytowany jako dowód na to, że ślepa optymalizacja pod ocenę PSI może prowadzić na manowce.
Developerzy pracujący z aplikacjami SPA zaczęli w mediach społecznościowych publikować porównania przed i po aktualizacji, wskazując na wyraźne wzrosty. Barry Pollard studził jednak entuzjazm, podkreślając, że nie chodzi o specjalne traktowanie SPA, tylko o dokładniejszy model, który akurat najbardziej pomaga stronom z dużą ilością JavaScriptu.
Search Engine Journal w swojej analizie stawia na pragmatyzm i formułuje trzy zalecenia: sprawdzać, czy porównywane raporty pochodzą z tej samej wersji Lighthouse, porównywać dane terenowe przed przypisaniem wyższego wyniku laboratoryjnego pracy nad stroną oraz pamiętać, że w przypadku niedawno optymalizowanych stron część poprawy może wynikać z nowej wersji narzędzia.
Co dalej: plan działania na najbliższe tygodnie
Aktualizacja jest już aktywna w PageSpeed Insights, a 8 grudnia, wraz ze stabilnym Chrome 159, trafi do wbudowanego w przeglądarkę panelu Lighthouse. Do tego czasu wyniki z PSI i z lokalnego DevTools w stabilnym Chrome mogą się różnić, bo będą pochodzić z różnych wersji silnika. To kolejny powód, by przy każdym porównaniu sprawdzać numer wersji w stopce raportu.
Proponujemy prosty plan na najbliższe dni:
- Zrób nowy pomiar bazowy. Przetestuj najważniejsze szablony (strona główna, kategoria, produkt, artykuł) w PSI i zapisz wyniki jako nowy punkt odniesienia z adnotacją „Lighthouse 13.6.0”.
- Oznacz datę w dashboardach. W Looker Studio, Grafanie czy własnym monitoringu dodaj adnotację z dniem przełączenia PSI, żeby skok wyniku nie był później błędnie interpretowany.
- Weryfikuj sukcesy danymi CrUX. Jeśli raportujesz klientowi poprawę wydajności, pokaż zmianę w danych terenowych, a nie tylko w ocenie laboratoryjnej.
- Przejrzyj odłożone optymalizacje. Jeśli kiedyś wycofałeś preload albo inną zmianę, bo pogarszała symulowane LCP, przetestuj ją ponownie na nowej wersji.
- Zaktualizuj wdrożenie ARD. Jeśli eksperymentujesz z katalogiem usług dla agentów AI, przejdź na ard.json i sprawdź wynik audytu.
- Obserwuj otwarte zgłoszenia. Problem zawyżonego symulowanego LCP na dużych witrynach JavaScript wciąż czeka na rozwiązanie, więc kolejne wersje Lantern mogą znów przesunąć wyniki.
Szerszy kontekst jest prosty: Lighthouse pozostaje narzędziem diagnostycznym, a nie wyrocznią. Każda kolejna wersja silnika symulacji zbliża test laboratoryjny do rzeczywistości, ale nigdy go z nią nie zrówna. Zespoły, które traktują ocenę PSI jako jeden z wielu sygnałów, a nie jako cel sam w sobie, przejdą przez tę zmianę bez zamieszania. Ci, którzy sprzedają klientom „setkę w PageSpeed”, powinni przygotować się na trudne pytania, gdy wyniki zaczną rosnąć same, bez żadnej pracy.
FAQ
Czy Lighthouse 13.6 wpływa na pozycje w Google?
Nie. Zmiana dotyczy wyłącznie symulowanego testu laboratoryjnego w PageSpeed Insights i Lighthouse. Sygnały Core Web Vitals wykorzystywane przez Google pochodzą z danych terenowych CrUX, czyli z wizyt prawdziwych użytkowników, a te nie zmieniają się z powodu nowej wersji narzędzia.
Dlaczego mój wynik w PageSpeed Insights wzrósł, choć nic nie zmieniałem?
PSI przeszedł na Lighthouse 13.6.0, w którym silnik Lantern dokładniej wykrywa zasoby blokujące renderowanie i inaczej liczy LCP, gdy elementem LCP jest tekst. Google zapowiada, że symulowane FCP i LCP będą zazwyczaj wyższe, zwłaszcza na stronach z dużą ilością JavaScriptu.
Jak sprawdzić, z której wersji Lighthouse pochodzi raport?
Numer wersji widać w stopce raportu PageSpeed Insights oraz w raporcie Lighthouse w DevTools. Porównuj tylko raporty z tej samej wersji. Do 8 grudnia, gdy stabilny Chrome 159 dostanie Lighthouse 13.6, wyniki z PSI i lokalnego DevTools mogą się różnić.
Czy aktualizacja dotyczy tylko aplikacji SPA?
Nie. Według Barry’ego Pollarda z zespołu Chrome zmiana nie jest specyficzna dla SPA, ale najsilniej odczują ją witryny mocno zależne od JavaScriptu. Poprawka wykrywania zasobów blokujących renderowanie dotyczy wszystkich stron, więc niewielkie przesunięcia FCP są możliwe wszędzie.
Co zmieniło się w audycie ARD dla agentów AI?
Audyt został dostosowany do specyfikacji ARD v0.91. Lighthouse szuka teraz linii Agentmap, linku rel=”ard” lub nagłówka Link oraz pliku /.well-known/ard.json, a starsze nazwy ai-catalog sprawdza dopiero później. Plik ard.json zastępuje ai-catalog.json.