Lighthouse 13.6 w PageSpeed Insights: wyniki rosną bez zmian na stronie

Wyniki wydajności w PageSpeed Insights mogą od kilku dni rosnąć na stronach, na których nikt niczego nie zmienił. Narzędzie Google działa już na Lighthouse 13.6.0, a nowa wersja inaczej symuluje ładowanie strony, przez co szacowane FCP i LCP wychodzą zwykle lepiej niż wcześniej. Najmocniej odczują to serwisy oparte na JavaScripcie, a każdy, kto raportuje klientom „poprawę po optymalizacji”, powinien teraz najpierw sprawdzić numer wersji w stopce raportu.

Kontekst: co się stało i skąd o tym wiemy

Lighthouse 13.6.0 został opublikowany 27 października 2026 roku. W notatkach do wydania zespół Lighthouse zapowiedział, że wersja trafi do PageSpeed Insights „w ciągu tygodnia”, a do narzędzi deweloperskich Chrome razem z Chrome 159. Pierwsza część zapowiedzi właśnie się spełniła: jak podaje serwis Search Engine Journal, Barry Pollard, Web Performance Developer Advocate w zespole Chrome, potwierdził na Bluesky, że PageSpeed Insights korzysta już z nowej wersji.

Pollard opisał zmianę wprost: symulowane First Contentful Paint (FCP) i symulowane Largest Contentful Paint (LCP) mają być teraz dokładniejsze niż wcześniej i w praktyce przekładają się zazwyczaj na wyższe wyniki. To ważne zastrzeżenie, bo oznacza, że ta sama strona, zbadana dzień przed aktualizacją i dzień po niej, może dostać inną ocenę, mimo że jej kod, serwer i zasoby pozostały identyczne.

Nie jest to pierwsza w tym roku zmiana w Lighthouse, która dotyka branży SEO. We wrześniu wersja 13.5 dodała audyt Agentic Resource Discovery, o którym pisaliśmy w tekście Lighthouse 13.5 i audyt ARD dla agentów AI. Wersja 13.6 poprawia także ten audyt, ale dla większości zespołów SEO i właścicieli sklepów pierwszoplanowa będzie zmiana w samej punktacji wydajności.

Kluczowe fakty: co dokładnie zmienia Lighthouse 13.6

Wynik wydajności w PageSpeed Insights nie pochodzi z pomiaru na wolnym łączu. Lighthouse domyślnie ładuje stronę z pełną prędkością, a następnie szacuje, jak wyglądałoby to na wolniejszym połączeniu i słabszym urządzeniu. Za tę estymację odpowiada silnik symulacji o nazwie Lantern. Dokumentacja Lighthouse wskazuje, że taki tryb symulowanego dławienia (simulated throttling) odpowiada konfiguracji PageSpeed Insights. Każda zmiana w Lantern przekłada się więc bezpośrednio na liczby, które widzą miliony użytkowników PSI.

Według notatek do wydania 13.6.0 zespół zaktualizował silnik śladów (trace_engine do wersji 0.0.66 i 0.0.67) oraz sposób modelowania żądań i grafu zależności. Najważniejsze zmiany zebraliśmy w tabeli.

Zasoby blokujące renderowanie: Chrome mówi, Lantern słucha

Do tej pory Lantern zgadywał, czy dany plik blokuje renderowanie, na podstawie jego priorytetu pobierania. To przybliżenie bywało mylące: plik o wysokim priorytecie nie zawsze wstrzymuje pierwsze malowanie, a w nowoczesnych frameworkach priorytety często są ustawiane ręcznie. W wersji 13.6 symulacja korzysta z flagi renderBlocking, którą przeglądarka sama przypisuje każdemu żądaniu. Priorytet służy już tylko jako zapasowe źródło informacji, gdy takiej etykiety brakuje.

Tekstowe LCP i przypadek strony z Framera

Druga zmiana dotyczy stron, na których największym elementem w pierwszym widoku jest tekst, wyświetlany w tej samej klatce co pierwsza treść. Wtedy jeden element jest jednocześnie FCP i LCP. Stara symulacja liczyła jednak LCP z zestawu, który mógł obejmować wszystkie żądania wykonane przed LCP, przez co raport pokazywał LCP znacznie późniejsze od FCP, choć w rzeczywistości oba zdarzenia zachodziły równocześnie.

Problem udokumentował w zgłoszeniu na GitHubie Ivan Akulov, specjalista od wydajności stron. Na testowej stronie zbudowanej we Framerze jedyną treścią nad linią załamania był tekst. Preładowanie modułów JavaScript poprawiało realną interaktywność strony, a mimo to symulowane LCP w Lighthouse się pogarszało. Innymi słowy: dobra praktyka optymalizacyjna była karana w raporcie. Pollard podziękował Akulovowi publicznie, pisząc, że to on „zapoczątkował część tych usprawnień”, a zespół zamknął zgłoszenie jako rozwiązane w ramach aktualizacji Lantern opisanej w notatkach do 13.6.

Kto zobaczy największą różnicę

Pollard zacytował na Bluesky dewelopera, który zauważył wyraźną poprawę wyników aplikacji jednostronicowych (SPA) po aktualizacji, podając jako przykład react.dev. Odpowiedział krótko: „True!”, po czym doprecyzował, że zmiana nie dotyczy wyłącznie SPA i nie ma związku z innymi pracami zespołu wokół takich aplikacji, ale „najprawdopodobniej wpłynie na strony mocno oparte na JavaScripcie”.

W praktyce oznacza to, że największe skoki mogą zobaczyć sklepy na headless commerce, serwisy na React, Vue czy Next.js, strony budowane w kreatorach typu Framer oraz rozbudowane motywy WordPressa z ciężkimi page builderami. Klasyczne, lekkie strony renderowane po stronie serwera mogą odnotować niewielką zmianę albo żadną.

Co to znaczy dla SEO i AIO

Ranking się nie zmienia, raporty tak

Najważniejsza rzecz na początek: wynik wydajności w PageSpeed Insights to dane laboratoryjne. Google w dokumentacji PSI zaznacza, że dane laboratoryjne powstają w symulowanym załadowaniu strony na jednym urządzeniu przy stałych warunkach sieciowych i że „dobre dane laboratoryjne nie oznaczają, że doświadczenia prawdziwych użytkowników również będą dobre”. Sygnał Core Web Vitals, który Google uwzględnia w systemach oceny doświadczenia strony, opiera się na danych terenowych z raportu Chrome User Experience Report (CrUX), czyli na prawdziwych wizytach z ostatnich 28 dni.

Aktualizacja Lighthouse nie zmienia więc ani o milisekundę tego, jak szybko Twoja strona ładuje się realnym użytkownikom, ani danych CrUX, z których korzysta wyszukiwarka. Jeśli chcesz odświeżyć sobie, ile Core Web Vitals faktycznie ważą w rankingu, wracamy do tego w analizie Core Web Vitals w 2026: ile naprawdę ważą.

Ryzyko numer jeden: fałszywe sukcesy w raportach

Zmienia się za to coś, co w agencjach i działach marketingu bywa równie ważne jak ranking: raportowanie. Wyniki sprzed i po aktualizacji do 13.6 nie zostały zmierzone tą samą symulacją. Jeśli w ostatnich dniach wdrożyłeś optymalizację i widzisz skok z 62 do 81 punktów, część tej poprawy może wynikać wyłącznie z nowej wersji narzędzia. Wykresy śledzące wynik Lighthouse w czasie (w narzędziach do monitoringu, arkuszach czy dashboardach Looker Studio) mogą pokazać schodek dokładnie w dniu przełączenia.

Działa to też w drugą stronę. Zespół, który porównuje wynik strony klienta z wynikiem konkurenta, a jedno badanie zrobił na 13.5, a drugie na 13.6, porównuje dwie różne miary. To samo dotyczy przetargów i umów, w których próg „minimum 90 punktów w PageSpeed Insights” bywa zapisanym celem. Strona może dziś ten próg przekroczyć bez żadnej pracy wykonawcy.

Co sprawdzić przed raportem

• Numer wersji Lighthouse. Każdy raport PageSpeed Insights podaje go obok informacji o emulowanym urządzeniu. Porównuj tylko wyniki z tą samą wersją.
• Dane terenowe CrUX. Jeżeli poprawa jest realna, pojawi się z opóźnieniem w danych z prawdziwych wizyt. Okno 28 dni oznacza, że efekt optymalizacji będzie widoczny stopniowo.
• Metryki, nie tylko wynik. Zmiana dotyczy głównie symulowanego FCP i LCP. Jeśli rośnie wynik, ale Total Blocking Time i CLS stoją w miejscu, to mocny sygnał, że różnica wynika z narzędzia.
• Adnotacja na wykresach. W dashboardach warto oznaczyć datę przejścia PSI na 13.6, żeby za kilka miesięcy nikt nie przypisał tego skoku konkretnemu wdrożeniu.
• Lokalne narzędzia. DevTools w Chrome dostaną 13.6 dopiero z Chrome 159. Do tego czasu wynik w lokalnej przeglądarce i w PSI mogą się różnić z powodu samej wersji.

Wątek AIO: manifest ARD i agenci AI

Dla zespołów, które przygotowują serwisy pod agentów AI i wyszukiwarki konwersacyjne, istotna jest zmiana w audycie Agentic Resource Discovery. Wersja 13.5 szukała manifestu pod starymi nazwami ai-catalog, choć specyfikacja przeszła już na plik ard.json. Strona, która publikowała wyłącznie nowy plik i nie miała w robots.txt linii Agentmap, dostawała status „nie dotyczy”.

Lighthouse 13.6 implementuje specyfikację ARD v0.91. Najpierw szuka linii Agentmap w robots.txt, znacznika link rel=”ard” lub nagłówka HTTP Link oraz pliku /.well-known/ard.json, a dopiero potem starych lokalizacji ai-catalog. Gdy manifest leży tylko w starym miejscu, raport ostrzega, że konsumenci ARD nie mają obowiązku tam zaglądać. Stopka raportu pokazuje też wersję specyfikacji ARD, na której oparto audyt. Jeśli wdrożyłeś manifest według wcześniejszych instrukcji, to dobry moment na migrację do ard.json.

Przy okazji warto odnotować dwie mniejsze poprawki w audytach robots.txt i llms.txt: Lighthouse nie zgłasza już błędu, gdy treść tych plików jest pusta (null), a odpowiedź HTTP 429 przy ich pobieraniu traktuje jako niezaliczony audyt. Serwisy, które agresywnie limitują ruch botów, mogą więc zobaczyć nowe ostrzeżenia w tej sekcji.

Reakcje branży

Pierwsze reakcje pojawiły się głównie wśród deweloperów i specjalistów od wydajności, a nie w samym środowisku SEO. Według relacji Search Engine Journal to właśnie programiści aplikacji jednostronicowych jako pierwsi publicznie zauważyli, że ich wyniki wyraźnie poszły w górę po aktualizacji, a Barry Pollard potwierdził tę obserwację, jednocześnie studząc interpretację, że chodzi o zmianę „pod SPA”.

Przypadek Ivana Akulova pokazuje z kolei, że część środowiska od dawna wskazywała słabości symulacji Lantern. Jego zgłoszenie dotyczyło sytuacji, w której zalecana optymalizacja pogarszała wynik w raporcie. Dla zespołów technicznego SEO to istotna lekcja: wynik Lighthouse jest modelem, a modele mają błędy, które bywają naprawiane w kolejnych wersjach.

Wśród polskich specjalistów od lat powtarza się zresztą zasada, że wynik PageSpeed Insights to narzędzie diagnostyczne, a nie cel sam w sobie. Aktualizacja 13.6 daje dobry argument w rozmowach z klientami, którzy oczekują „zielonej setki”: liczba może się zmienić nawet wtedy, gdy strona pozostaje dokładnie taka sama. Warto też pamiętać, że zewnętrzne skrypty pomiarowe, z których korzystamy do monitorowania wydajności, same bywają ryzykiem, co pokazał niedawny incydent z przejętym DNS DebugBear.

Co dalej

Najbliższa data, którą warto zapisać w kalendarzu, to 8 grudnia 2026 roku. Według harmonogramu wydań Chrome (stan na 2 listopada) na ten dzień zaplanowano stabilne wydanie Chrome 159, a zespół Lighthouse spodziewa się, że wersja 13.6 trafi właśnie do DevTools tej przeglądarki. Obecnie Chrome 159 jest dostępny w kanale Dev na desktopie i w Canary. Do grudnia wyniki z PageSpeed Insights i z lokalnej zakładki Lighthouse w stabilnym Chrome mogą się więc rozjeżdżać.

Na GitHubie Lighthouse otwarte jest też kolejne zgłoszenie, które bada przypadki, gdy symulowane LCP w Lantern wypada dużo wyżej niż LCP zmierzone w rzeczywistości. Jako przykłady podawane są duże serwisy oparte na JavaScripcie i aplikacje SPA. To sygnał, że prace nad dokładnością symulacji trwają i kolejne wersje mogą znów przesunąć wyniki, tym razem w przypadku cięższych stron.

Dla zespołów prowadzących regularne audyty istotna jest również nowa funkcja CLI: Lighthouse 13.6 potrafi w jednym poleceniu zbadać wiele adresów kolejno, przekazanych jako argumenty albo z pliku (–url-file), z opcją przerwania przy pierwszym błędzie (–fail-fast). Domyślne nazwy plików raportów zawierają teraz ścieżkę adresu, więc audyt kilkudziesięciu podstron jednej domeny nie nadpisze wyników. To ułatwia porównywanie szablonów (strona kategorii, karta produktu, wpis blogowy) bez pisania własnych skryptów.

Nasza rekomendacja na najbliższe tygodnie jest prosta: zapisz dzisiejsze wyniki kluczowych szablonów wraz z numerem wersji Lighthouse, oznacz datę zmiany w dashboardach i opieraj decyzje o priorytetach optymalizacji na danych CrUX oraz Search Console. Jeżeli realnie skróciłeś czas ładowania, dane terenowe to potwierdzą. Jeżeli wzrósł tylko wynik laboratoryjny, nie ma czego świętować ani czego się obawiać.

FAQ