PageSpeed Insights — jak czytać raport: dane użytkowników, wynik Lighthouse i ustawienia testu

PageSpeed Insights pokazuje na jednym ekranie dwa różne pomiary, a większość nieporozumień wokół wyniku bierze się z czytania jednej połowy raportu tak, jakby była drugą. Górna część to dane od prawdziwych użytkowników Chrome z ostatnich 28 dni: dla adresu, który wpisałeś, dla całej domeny albo żadne. Dolna to jedno symulowane ładowanie strony przez Lighthouse na emulowanym telefonie ze średniej półki, przy spowolnionym łączu i procesorze.

Google opisuje ten podział wprost: „Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience - but has a more limited set of metrics” (About PageSpeed Insights, strona zaktualizowana 21.10.2024, odczyt 03.10.2026). Dane laboratoryjne służą więc do szukania przyczyn, a dane terenowe mówią, jak strona działa u ludzi.

Z pomylenia tych dwóch pomiarów biorą się trzy typowe pytania: dlaczego wynik skacze, choć nic nie zmieniałeś; dlaczego zielone 90 punktów nie oznacza zdanej oceny Core Web Vitals; dlaczego zamiast danych od użytkowników widzisz informację o ich braku. Wszystkie trzy porządkuje jedna zasada: wynik 0–100 służy do diagnozy, a o tym, czy strona zdaje ocenę, rozstrzygają dane terenowe.

Co pokazuje PageSpeed Insights: dwa pomiary na jednym ekranie

Górna część raportu pochodzi z Chrome User Experience Report (CrUX), dolna z Lighthouse — to dwa źródła, które mierzą różne rzeczy w różnym czasie. Według tej samej strony Google PSI pokazuje doświadczenia prawdziwych użytkowników dla First Contentful Paint (FCP), Interaction to Next Paint (INP), Largest Contentful Paint (LCP) i Cumulative Layout Shift (CLS) „over the previous 28-day collection period”, a do tego eksperymentalną metrykę Time to First Byte (TTFB).

Okno 28 dni jest kroczące. Dane w PSI odświeżają się codziennie, natomiast zbiór CrUX w BigQuery raz w miesiącu i tylko na poziomie całych domen; oba obejmują 28 dni wstecz (About PageSpeed Insights, odczyt 03.10.2026). Liczby w górnej części raportu nie opisują więc dzisiejszej wersji strony, tylko doświadczenia użytkowników z ostatnich czterech tygodni.

Dolna część to Lighthouse: „PSI uses Lighthouse to analyze the given URL in a simulated environment for the Performance, Accessibility, Best Practices, and SEO categories”. Test uruchamia się na serwerach Google, a raport podaje, w którym regionie: „PageSpeed will report running in one of: North America, Europe, or Asia” (tamże).

Obie części mogą sobie przeczyć i to nie jest błąd narzędzia. Google odpowiada na to w FAQ: dane terenowe to „a historical report about how a particular URL has performed”, a dane laboratoryjne opierają się na „a simulated load of a page on a single device and fixed set of network conditions. As a result, the values may differ” (tamże). Szerzej o tym, dlaczego laboratorium i teren rozjeżdżają się na konkretnych metrykach, piszemy w artykule o Core Web Vitals.

Górna część raportu: dane prawdziwych użytkowników

Górna połowa ekranu odpowiada na jedno pytanie: jak strona działała u ludzi w ostatnich 28 dniach. Żeby ją dobrze odczytać, trzeba wiedzieć, czyje to dane, dlaczego może ich nie być i co znaczy liczba nad paskami.

Ten adres czy cała domena

PSI najpierw szuka danych dla dokładnie tego adresu. Jeśli ich nie ma, przechodzi poziom wyżej. Google formułuje to tak: „A page might not have sufficient data if it has been recently published or has too few samples from real users. When this happens, PSI will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website. Sometimes the origin may also have insufficient data, in which case PSI will be unable to show any real-user experience data” (About PageSpeed Insights, odczyt 03.10.2026). W odpowiedzi API to dwa osobne obiekty: loadingExperience dla adresu i originLoadingExperience dla domeny (dokumentacja runPagespeed, strona z 03.09.2024).

Stąd bierze się zjawisko, które często wygląda na błąd: liczby wyświetlane przy podstronie mogą się zmienić, choć na tej podstronie nic się nie zmieniło. Gdy PSI pokazuje dane całej domeny, obejmują one wszystkie odsłony na wszystkich stronach witryny. Wystarczy, że zmieni się inna podstrona albo proporcje ruchu między podstronami, a wynik „Twojej” strony też się przesunie. Do tego okno 28 dni przesuwa się codziennie, więc z każdym dniem wypadają z niego najstarsze odsłony. Zanim porównasz dwa odczyty, sprawdź, czy oba dotyczą tego samego zakresu.

Dlaczego danych może nie być wcale

Do CrUX trafia tylko adres, który jest publiczny i może być zaindeksowany. Metodologia CrUX stosuje „the same indexability criteria as search engines”: strona wypada, jeśli po przekierowaniach odpowiada innym statusem niż 200, ma nagłówek X-Robots-Tag: noindex albo znacznik <meta name="robots" content="noindex"> (CrUX methodology, strona z 20.06.2024, odczyt 03.10.2026).

Drugi warunek to popularność. Google nie podaje progu: „An exact number is not disclosed … The minimum number is the same for pages and origins”. Strony poniżej progu nie ma w zbiorze, a zgłosić jej ręcznie nie można: „At this time, you cannot manually submit pages or origins for inclusion” (tamże). Liczą się przy tym tylko użytkownicy Chrome z włączonym raportowaniem statystyk użytkowania i synchronizacją historii, bez hasła synchronizacji, na komputerach i Androidzie; Chrome na iOS do CrUX nie raportuje. Co brak danych terenowych oznacza dla małej strony firmowej, opisujemy w artykule o Core Web Vitals.

Paski i liczba nad nimi

Każda metryka ma pasek podzielony na trzy kolory: dobry, do poprawy i słaby. Google podaje przykład: „seeing 11% within LCP's amber bar indicates that 11% of all observed LCP values fall between 2500ms and 4000ms”. Liczba nad paskiem to nie średnia: „Above the distribution bars, PSI reports the 75th percentile for all metrics” (About PageSpeed Insights, odczyt 03.10.2026). Wartość nad paskiem LCP znaczy więc, że trzy czwarte odsłon miało LCP nie gorsze niż ta liczba, a jedna czwarta gorsze.

Kiedy strona zdaje ocenę Core Web Vitals

Ocena dotyczy trzech metryk: INP, LCP i CLS. Reguła PSI ma dwa przypadki brzegowe: „the aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good. Otherwise, the aggregation does not pass the assessment. If the aggregation has insufficient data for INP, then it will pass the assessment if both the 75th percentiles of LCP and CLS are Good. If either LCP or CLS have insufficient data, the page or origin-level aggregation cannot be assessed” (tamże). Brak danych o INP nie blokuje więc zaliczenia, a brak danych o LCP albo CLS uniemożliwia ocenę.

Progi trzech metryk (LCP 2,5 s, INP 200 ms, CLS 0,1 na 75. percentylu) i to, co je psuje, omawiamy w artykule o Core Web Vitals. Raport pokazuje jeszcze dwie metryki, które nie wchodzą do oceny, a mają własne progi w tabeli PSI (tamże):

• FCP: dobry do 1 800 ms, do poprawy powyżej 1 800 ms do 3 000 ms, słaby powyżej 3 000 ms;
• TTFB (eksperymentalny): dobry do 800 ms, do poprawy powyżej 800 ms do 1 800 ms, słaby powyżej 1 800 ms.

Dwa odczyty z 03.10.2026

Sprawdziliśmy, co API PageSpeed Insights zwraca dla naszej domeny i dla strony z dużym ruchem. Dla www.digitalvantage.pl odpowiedź nie zawierała żadnych danych terenowych, ani dla adresu, ani dla domeny — nasza witryna nie ma w CrUX wystarczającej liczby pomiarów. W tej samej minucie dla web.dev API zwróciło pełne dane: ogólna kategoria SLOW, LCP 3 139 ms, INP 218 ms i CLS 0,01 na 75. percentylu. Nawet serwis poświęcony wydajności stron nie mieścił się więc w progach dla LCP i INP. To jeden odczyt przez API, nie przez interfejs, i dotyczy kroczącego okna 28 dni sprzed tej daty.

Dolna część: skąd się bierze wynik 0–100

Wynik wydajności to średnia ważona pięciu metryk laboratoryjnych z jednego symulowanego ładowania, a nie ocena doświadczeń użytkowników. Google podaje pasma: „A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor” i od razu dodaje zastrzeżenie: „having good lab data does not necessarily mean real-user experiences will also be good” (About PageSpeed Insights, odczyt 03.10.2026).

Do wyniku liczą się tylko metryki: „The Performance score is a weighted average of the metric scores” oraz „only metrics contribute to your Lighthouse Performance score, not the results of Opportunities or Diagnostics” (Lighthouse performance scoring, strona z 19.09.2019, odczyt 03.10.2026; wagi aktualne według konfiguracji Lighthouse, odczyt 03.10.2026). Zalecenia wyświetlane pod wynikiem pomagają szukać przyczyn, ale same nie dodają ani nie odejmują punktów.

Metryki nie ważą tyle samo. Według dokumentacji Lighthouse LCP ma wagę 25%, a Total Blocking Time 30%, czyli te dwie metryki dają razem 55% wyniku. Pozostałe 45% to FCP, Speed Index i CLS. Pełną tabelę wag i to, dlaczego metryka o największej wadze nie należy do Core Web Vitals, opisujemy w artykule o Core Web Vitals.

Dlaczego od 90 do 100 jest najdrożej

Każda metryka dostaje punkty według krzywej opartej na danych HTTP Archive: „The 25th percentile of HTTP Archive data becomes a score of 50 … and the 8th percentile becomes a score of 90”. Krzywa spłaszcza się przy końcu skali: „taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94” (Lighthouse performance scoring, odczyt 03.10.2026). Przejście z 99 na 100 wymaga więc mniej więcej takiej poprawy metryk jak przejście z 90 na 94. Jeśli ktoś proponuje Ci „dojście do 100”, płacisz za najdroższy odcinek skali.

Dlaczego w dolnej części nie ma INP

Laboratoryjny test w PSI tylko ładuje stronę. Nikt w nią nie klika, więc nie ma interakcji, którą można by zmierzyć. Google pisze o tym: „some lab tools won't report a page's INP because they only observe the loading of a page without any interactions. In such cases, Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it's not a substitute for INP in and of itself” (web.dev, Interaction to Next Paint, aktualizacja 02.09.2025, odczyt 03.10.2026). TBT dotyczy blokowania głównego wątku przeglądarki podczas ładowania, a nie reakcji strony na konkretne kliknięcie.

Nie znaczy to, że Lighthouse nigdy nie zmierzy INP. W trybie Timespan, dostępnym m.in. w panelu Lighthouse w Chrome DevTools, Lighthouse rejestruje okres, w którym sam klikasz po stronie, i tylko w tym trybie działa jego audyt INP (kod audytu INP w Lighthouse, odczyt 03.10.2026). Taki pomiar zależy jednak od tego, co zrobisz: wartość INP w laboratorium „will be dependent on what interactions are performed during the measurement period” (web.dev), a raport Timespan nie daje ogólnego wyniku wydajności (Lighthouse, user flows, odczyt 03.10.2026). Czym INP różni się od TBT i co go psuje, opisujemy w artykule o Core Web Vitals.

Telefon i komputer: z jakimi ustawieniami mierzy PageSpeed Insights

Raport ma dwie zakładki, telefon i komputer, i każda mierzy przy innych założeniach co do urządzenia, łącza i procesora. Ustawienia telefonu odpowiadają słabemu łączu komórkowemu. Dokumentacja Lighthouse mówi, że dławienie sieci ma emulować „the ~85th percentile mobile connection speed”; profil o opóźnieniu 150 ms i przepustowości 1,6 Mb/s w dół i 750 kb/s w górę reprezentuje „roughly the bottom 25% of 4G connections and top 25% of 3G connections”, a nazwa profilu to „Slow 4G”, który „used to be labeled as "Fast 3G"” (Lighthouse, Network Throttling, odczyt 03.10.2026). To nie jest 4G w potocznym sensie, tylko słabe łącze komórkowe.

Procesor zwalnia się czterokrotnie: „By default, Lighthouse uses a constant 4x CPU multiplier”, co według tej samej dokumentacji przesuwa typowy pomiar z klasy mocnego komputera „somewhere into the mid-tier mobile bracket” (tamże). Emulowane urządzenie to moto g power (2022) — ten model podaje konfiguracja Lighthouse i ten sam model był w nagłówku user-agent odpowiedzi PSI API, którą dostaliśmy 03.10.2026 (Chrome 153). Komputer jest mierzony przy opóźnieniu 40 ms, przepustowości 10 Mb/s i bez spowolnienia procesora. Strona „About PageSpeed Insights” wymienia wciąż starszy telefon; w tej sprawie aktualny jest kod Lighthouse.

Jedno zastrzeżenie do tej tabeli. PSI sam nie publikuje tych liczb, a jego API nie zwraca ich w odpowiedzi. Pochodzą z kodu Lighthouse, a to, że PSI ich używa, opiera się na zdaniu z dokumentacji Lighthouse: symulowane dławienie „remains the default setting. This matches the setup of PageSpeed Insights and the Lighthouse CLI default” (Lighthouse, Network Throttling).

Dławienie symulowane, a nie fizyczne

Słowo „symulowane” jest tu dosłowne. PSI nie ogranicza fizycznie łącza ani procesora podczas testu. Lighthouse ładuje stronę bez ograniczeń, a potem wylicza, jak to ładowanie przebiegłoby na wolnej sieci i słabszym procesorze: symulowane dławienie „uses a simulation of a page load, based on the data observed in the initial unthrottled load” (tamże). Dlatego dokumentacja ostrzega, że po otwarciu oryginalnego zapisu ładowania „the trace values will not match up with Lighthouse's metric results, as the original trace is prior to the simulation”. Ta sama dokumentacja uczciwie dodaje, że symulacja ma przypadki brzegowe i że do głębokiej analizy lepsze są inne metody.

Stąd różnica między wynikiem z PSI a wynikiem Lighthouse uruchomionego lokalnie na szybkim komputerze. Lokalnie symulacja wychodzi od ładowania zmierzonego na Twoim sprzęcie i Twoim łączu, a czterokrotne spowolnienie procesora mnoży moc Twojej maszyny, nie serwera Google; dokumentacja Lighthouse wprost podaje, że na słabszym komputerze można ten mnożnik obniżyć (tamże). Możesz też wybrać inną metodę, DevTools throttling, która spowalnia same zapytania.

Dlaczego telefon wypada gorzej i co z API

Wynik na telefonie jest zwykle niższy z prostego powodu: profil zakłada wolniejszą sieć i czterokrotnie wolniejszy procesor, więc każdy kilobajt i każda milisekunda pracy skryptów kosztują więcej. Do tego komputer ma od Lighthouse 6 własne, ostrzejsze krzywe punktacji (Lighthouse performance scoring), więc wyników z obu zakładek nie da się porównywać punkt w punkt. Jak projektować stronę z myślą o telefonie, opisujemy w artykule o stronie mobilnej.

Pułapka dla automatycznych pomiarów: parametr strategy w API ma opis „The analysis strategy (desktop or mobile) to use, and desktop is the default” (dokumentacja runPagespeed, strona z 03.09.2024, odczyt 03.10.2026). Skrypt, który wywołuje API bez strategy=mobile, mierzy komputer, czyli wariant o łagodniejszych ustawieniach.

Dlaczego wynik PageSpeed się zmienia, choć nic nie zmieniłeś

Wynik laboratoryjny zmienia się między uruchomieniami z założenia, więc pojedynczy test nie jest dowodem, że coś się poprawiło albo pogorszyło. Dokumentacja Lighthouse mówi to wprost: „Lighthouse performance scores will change due to inherent variability in web and network technologies, even if there hasn't been a code change. Run Lighthouse multiple times and beware of variability before drawing conclusions” (Lighthouse, Score Variability, odczyt 03.10.2026).

Ten sam dokument ocenia, jak prawdopodobne są poszczególne źródła zmienności w PageSpeed Insights:

• pewne: niedeterminizm przeglądarki;
• prawdopodobne: niedeterminizm samej strony i serwer, na którym stoi;
• możliwe: sieć szkieletowa i współdzielenie zasobów na maszynie testującej;
• mało prawdopodobne: sieć lokalna i sprzęt klienta.

Ostatni punkt ma praktyczne znaczenie: w PSI Twoje Wi-Fi i Twój laptop raczej nie tłumaczą wahań, bo test odbywa się na serwerach Google. W Chrome DevTools, gdzie test działa na Twoim komputerze, sprzęt i jego obciążenie mają już znaczenie (o tym niżej). Strona Google o punktacji wymienia też przyczyny po stronie samej witryny: testy A/B, reklamy, routing ruchu (Lighthouse performance scoring). Jeśli strona za każdym razem ładuje inny zestaw reklam, każdy test mierzy trochę inną stronę.

Sprawdziliśmy to 3 października 2026 na developer.chrome.com, stronie Google. Trzy uruchomienia PSI na telefonie w ciągu pięciu minut dały 55, 62 i 72 punkty, a górna część raportu za każdym razem pokazywała te same dane użytkowników: LCP 3,1 s, INP 297 ms, CLS 0,02. Różnica 17 punktów to tylko zmienność samego testu.

Odpowiedzią jest agregacja. Dokument Lighthouse podaje: „The median Lighthouse score of 5 runs is twice as stable as 1 run” i zaleca „aggregate values like the median, 90th percentile, or even min/max instead of single test results” (Lighthouse, Score Variability). My mierzymy pięć razy i bierzemy medianę; całą procedurę opisujemy w artykule o testowaniu strony.

Który adres wpisać do PageSpeed Insights

Testuj adres końcowy, ten, pod którym strona naprawdę się otwiera, a nie jego wersję z przekierowaniem. Gdy 03.10.2026 wpisaliśmy do PSI https://digitalvantage.pl/ (bez „www”), raport dodał ostrzeżenie, że adres „was redirected to https://www.digitalvantage.pl/. Try testing the second URL directly”. PSI od 2022 roku próbuje sam podążyć za przekierowaniami przed analizą (release notes PSI, wpis z 10.05.2022, odczyt 03.10.2026), ale ostrzeżenie mówi jasno, który adres warto mierzyć.

Przy danych terenowych liczy się adres w takiej postaci, w jakiej zna go CrUX. Metodologia CrUX opisuje trzy reguły (CrUX methodology, odczyt 03.10.2026):

• parametry i fragmenty są usuwane, więc adres z ?utm_medium=email albo #main to dla CrUX ten sam adres co bez nich;
• w aplikacjach jednostronicowych przejścia między widokami przypisuje się pierwszej odsłonie;
• strona z noindex albo ze statusem innym niż 200 nie ma danych terenowych w ogóle.

I jeszcze jedno: nie testuj wyłącznie strony głównej. W Web Almanac 2025 strony główne zdawały Core Web Vitals rzadziej niż podstrony — szczegóły w części o danych rynkowych niżej. Mierz strony, na które ludzie naprawdę trafiają z wyszukiwarki i z reklam.

Lighthouse w Chrome DevTools a PageSpeed Insights

Lighthouse to ten sam silnik, który działa w PSI, ale uruchomiony w Twojej przeglądarce mierzy też Twój komputer. Google opisuje go jako „an open-source, automated tool”, który można uruchomić „in Chrome DevTools, from the command line, or as a Node module” (Lighthouse overview, strona z 02.06.2025, odczyt 03.10.2026). Lighthouse w Chrome znajdziesz jako osobny panel w narzędziach deweloperskich (DevTools).

Różnice opisuje dokumentacja panelu (Lighthouse w Chrome DevTools, aktualizacja 15.10.2025, odczyt 03.10.2026):

• wynik zależy od Twojego środowiska: „Lighthouse is influenced by your setup, including other load happening on your device, Chrome extensions, and any device settings you've stored in cookies, local storage, or similar”;
• tryb incognito pomaga, ale nie w pełni: „even then this may still be subject to these influences”;
• dlatego „you cannot directly compare two Lighthouse audits completed on different machines”;
• PSI i narzędzia CI uruchamiane na osobnych serwerach „may produce a "cleaner" and more consistent Lighthouse audits”.

DevTools ma za to możliwości, których PSI nie daje. Potrafi zbadać stronę wymagającą logowania — Google wymienia „Audit pages that require authentication” wśród zastosowań Lighthouse (Lighthouse overview). Pozwala też wybrać urządzenie i kategorie audytu: „Many Lighthouse tools (for example PageSpeed Insights) don't offer the option to choose the device type or audit categories”. Oprócz domyślnego trybu Navigation ma tryby Timespan i Snapshot, a obok symulowanego dławienia także DevTools throttling.

Praktyczny podział jest więc taki: PSI do porównywalnych pomiarów stron publicznych, DevTools do stron za logowaniem i do pracy nad konkretną interakcją. Przy samym szukaniu przyczyn Google kieruje dalej: „When using DevTools to debug performance problems, we recommend the Performance panel over Lighthouse” (tamże).

Lighthouse 13: audyty zamienione na „insights”

Jeśli porównujesz raport z poradnikiem sprzed roku, lista zaleceń pod wynikiem może wyglądać zupełnie inaczej — punktacja nie. Lighthouse 13.0 (wpis na blogu Chrome z 10.10.2025) zastąpił dotychczasowe audyty wydajności tak zwanymi insights, wspólnymi z panelem Performance w DevTools. Google podkreśla przy tym: „There are no changes to the performance scoring in this version of Lighthouse, which is based on the metrics rather than the audits. Only the non-scored audits are changing” (Lighthouse 13.0, odczyt 03.10.2026).

Dla czytelnika raportu oznacza to dwie rzeczy. Zrzuty ekranu i listy „okazji” ze starszych poradników mogą nie odpowiadać temu, co widzisz. A wynik 0–100 liczy się tak samo jak wcześniej, z tych samych pięciu metryk i tych samych wag.

Najnowsze wydanie to Lighthouse 13.5.0, opublikowane 18.09.2026 (wydania Lighthouse na GitHubie, odczyt 03.10.2026). W naszych wywołaniach PSI API z 03.10.2026 pole lighthouseVersion miało wartość 13.5.0, więc PSI działał wtedy na tej samej wersji.

PageSpeed Insights API: klucz, limity i zapowiedziana zmiana

API PageSpeed Insights daje te same dane co interfejs, ale ma inne wartości domyślne i zapowiedzianą zmianę, którą trzeba uwzględnić przy budowie automatycznego monitoringu. Klucz nie jest obowiązkowy: „The API can be used with or without an API key, although a key is recommended for frequent, automated queries” (PSI API, Get Started, strona z 28.08.2025, odczyt 03.10.2026).

O limitach Google nie podaje liczb na stronach dokumentacji PSI. Bez klucza API szybko trafia się na limit; z kluczem limit widać w konsoli Google Cloud. Nasze wywołanie bez klucza 03.10.2026 zwróciło błąd HTTP 429 z informacją o przekroczeniu dziennego limitu zapytań i wartością limitu 0. To pojedyncza obserwacja — nie wiemy, czy to stałe ustawienie, czy wyczerpana wspólna pula.

Dwie wartości domyślne zaskakują przy pierwszym skrypcie. Bez parametru category API uruchamia tylko wydajność: „if none are given, only Performance category will be run”. Bez parametru strategy mierzy komputer (dokumentacja runPagespeed). Dane terenowe przychodzą w dwóch obiektach: loadingExperience dla adresu i originLoadingExperience dla domeny.

Najważniejsza jest zapowiedź z dokumentacji: „We plan to discontinue including real-world data from the Chrome User Experience Report in this API. We recommend the CrUX API (guide) or the CrUX History API (guide) instead” (PSI API, Get Started). Google nie podał daty. 03.10.2026 API wciąż zwracało dane terenowe. Jeśli budujesz monitoring na dłużej, dane terenowe pobieraj od razu z CrUX API: jest bezpłatne, ma limit 150 zapytań na minutę na projekt Google Cloud, dane odświeżają się codziennie około 04:00 UTC bez gwarancji godziny i są około dwóch dni za bieżącą datą (CrUX API, strona z 11.02.2025, odczyt 03.10.2026).

Jak wypadają inne strony: Web Almanac 2025

Dobre Core Web Vitals ma mniej więcej co druga strona na świecie, a porównanie lat pokazuje, że obie połowy raportu PSI naprawdę zmieniają się niezależnie. Rozdział 7 „Performance” Web Almanac 2025 opiera się na pomiarach z lipca 2025, z HTTP Archive i CrUX (Web Almanac 2025, Performance, opublikowany 15.01.2026, odczyt 03.10.2026). To dane globalne, bez wydzielenia Polski.

Według Web Almanac dobre Core Web Vitals miało w 2025 roku 48% stron na telefonach i 56% na komputerach. Rok wcześniej było to 44% i 55%, a w 2023 roku 36% i 48%. Tysiąc najpopularniejszych witryn wypada niewiele lepiej: 51% i 59%. Strony główne zdawały rzadziej niż podstrony — 45% na telefonach i 47% na komputerach wobec 56% i 61% (tamże).

Według metryk dobry wynik na telefonach i komputerach miało: LCP 62% i 74%, INP 77% i 97%, CLS 81% i 72%. Najciekawsze jest zestawienie laboratorium z terenem. Mediana TBT w teście laboratoryjnym na telefonach wzrosła z 1 209 ms w 2024 roku do 1 916 ms w 2025, a odsetek stron z dobrym INP w terenie na telefonach wzrósł w tym czasie z 74% do 77% (tamże). Wskaźnik laboratoryjny się pogorszył, a terenowy poprawił. Dokładnie dlatego dolnej połowy raportu nie należy czytać jako prognozy górnej. Wyniki dla platform sklepowych z rozdziału 13 tego samego raportu omawiamy w artykule o Core Web Vitals w sklepie.

Co zrobić z wynikiem

Co zrobić dalej, zależy od tego, którą część raportu masz. Jeśli górna część pokazuje dane terenowe i ocena nie jest zaliczona, zacznij od metryki, która nie mieści się w progu; co ją psuje i w jakiej kolejności to naprawiać, opisujemy w artykule o Core Web Vitals. Jeśli danych terenowych nie ma, traktuj wynik Lighthouse jako diagnostykę i mierz według procedury, nie pojedynczym testem — patrz testowanie strony. Jeśli chcesz ocenić wiele adresów naraz, sięgnij po raport Core Web Vitals w Google Search Console, który grupuje podobne strony; Google zaznacza, że statystyki pojedynczego adresu w PSI „might not match the group results in Core Web Vitals” (pomoc Search Console, raport Core Web Vitals, odczyt 03.10.2026). Jak czytać ten i pozostałe raporty, opisujemy w artykule o Google Search Console.

Obie połowy raportu dla własnej strony możesz zobaczyć w naszym teście szybkości strony. Pokazuje on dane prawdziwych użytkowników Chrome z ostatnich 28 dni, z oznaczeniem, czy dotyczą tego adresu, czy całej witryny, albo komunikat, że ich brak, i ocenia je progami Core Web Vitals. Osobno pokazuje test laboratoryjny Lighthouse, w którym zamiast INP jest TBT.