Core Web Vitals: testy laboratoryjne a dane terenowe CrUX
To materiał do artykułu Core Web Vitals: dane laboratoryjne a CrUX. We wrześniu 2026 wielokrotnie testowałem cztery niezmienione strony cometweb.io, żeby sprawdzić trzy rzeczy: jak bardzo Lighthouse waha się sam z siebie, jak bardzo mój komputer i PageSpeed Insights różnią się w ocenie i co do tego dokładają dane terenowe CrUX.
Na co patrzyłem
Każdą z czterech stron produkcyjnych przepuściłem przez Lighthouse siedem razy: stronę główną, /pricing, /tools/auditor i /blog/woff2-vs-ttf. Użyłem domyślnego profilu mobilnego z symulowanym dławieniem, bez logowania i bez zgody na cookies. Każda próba dostawała nowy profil przeglądarki, więc za każdym razem było to zimne ładowanie, a strony szły na zmianę, żeby żadna nie miała wszystkich prób w jednym przedziale czasu.
Waga każdej strony mieściła się we wszystkich próbach w 0,31 KB, co zgadza się z tym, że w trakcie nic nie wdrażałem. Zostawiłem wszystkie 28 prób i żadnej nie wykluczyłem.
Do tego wywołałem API PageSpeed Insights trzy razy na stronę. Każda odpowiedź zawiera też dane terenowe CrUX, które Google ma dla adresu albo, zastępczo, dla całej domeny. Samo API CrUX było dla mojego klucza wyłączone, więc dane CrUX czytałem z odpowiedzi PSI.
Żeby zobaczyć, co mówi laboratorium tam, gdzie dane terenowe istnieją, wywołałem PSI raz dla pięciu znanych stron głównych, które niemal na pewno mają dane CrUX: web.dev, developer.chrome.com, MDN, w3.org i wikipedia.org. Wybrałem je właśnie z tego powodu, więc traktuj je jako ilustrację, bez wniosków o całej sieci.
Wyniki
Cztery niezmienione strony, 28 lokalnych prób. Podaję medianę, a w nawiasie najniższą i najwyższą wartość.
| Strona | Wynik | LCP | FCP | TBT |
|---|---|---|---|---|
/ | 67 (63–68) | 6,4 s (6,0–6,8) | 4,2 s (4,1–4,4) | 32 ms (17–43) |
/pricing | 67 (65–75) | 6,3 s (4,9–7,0) | 4,0 s (3,4–4,5) | 3 ms (0–17) |
/tools/auditor | 69 (68–72) | 5,9 s (5,3–6,1) | 3,7 s (3,6–4,1) | 1 ms (0–31) |
/blog/woff2-vs-ttf | 70 (69–77) | 5,7 s (4,8–5,9) | 3,7 s (2,9–3,9) | 0 ms (0–20) |
We wszystkich 28 próbach wynik wahał się od 63 do 77. Żadna symulowana próba nie miała LCP na poziomie 2,5 s albo niżej. Bez dławienia te same ładowania kończyły LCP w około 1,3 s (mediana), co pokazuje, ile z wyniku laboratoryjnego to model dławienia. Wszystkie 28 lokalnych prób miało CLS równe dokładnie 0.
PageSpeed Insights wobec moich lokalnych prób, trzy wywołania PSI na stronę:
| Strona | Wynik PSI | Wynik lokalny | LCP w PSI | LCP lokalnie |
|---|---|---|---|---|
/ | 71 (63–76) | 67 | 4,5 s | 6,4 s |
/pricing | 85 (79–85) | 67 | 3,8 s | 6,3 s |
/tools/auditor | 79 (78–82) | 69 | 4,2 s | 5,9 s |
/blog/woff2-vs-ttf | 78 (77–81) | 70 | 4,1 s | 5,7 s |
PSI dawał od 4 do 18 punktów więcej. Jego maszyny są dużo wolniejsze: indeks wydajności, który zapisuje Lighthouse, wynosił na moim komputerze od 4191 do 4430, a w PSI od 499 do 1338. Jedna próba PSI strony głównej miała TBT 433 ms, a moje najwyższe lokalne TBT wyniosło 43 ms.
CrUX nie miał dla cometweb.io żadnych danych terenowych, ani dla adresów, ani dla domeny.
Pięć publicznych stron, jedna laboratoryjna próba PSI wobec 75. percentyla CrUX z tej samej odpowiedzi:
| Strona | LCP w laboratorium | LCP w terenie (p75) | INP w terenie (p75) | Core Web Vitals w terenie |
|---|---|---|---|---|
| web.dev | 6,8 s | 3,1 s | 220 ms | niezaliczone |
| developer.chrome.com | 3,8 s | 3,0 s | 294 ms | niezaliczone |
| developer.mozilla.org | 2,7 s | 1,9 s | 160 ms | zaliczone |
| w3.org | 1,7 s | 1,1 s | 89 ms | zaliczone |
| wikipedia.org | 1,4 s | 1,3 s | 98 ms | zaliczone |
LCP z laboratorium był wyższy na wszystkich pięciu stronach. Pojedyncza próba i percentyl z 28 dni to liczby innego rodzaju, więc różnica pokazuje, czym się te dwie liczby różnią, i żadne narzędzie się tu nie myli.
Po 28 próbach uruchomiłem Lighthouse jeszcze raz na stronie głównej i przeczytałem jego diagnostykę. Szacowane oszczędności to estymacje Lighthouse z tej jednej próby. Poprawkę, która z tego wyszła, opisuję w pomiarze przed i po.
Czego te dane nie pokażą
- Jak cometweb.io działa u prawdziwych ludzi. CrUX nie miał nic, więc każda liczba tutaj pochodzi z laboratorium.
- Czy inne strony wahają się tak samo. To cztery strony jednego małego serwisu w SvelteKit, mierzone na jednym komputerze, z jednego domowego łącza w Polsce, jednego dnia. Siedem prób na stronę pokazuje rozrzut, ale nie wystarczy, żeby ustalić stabilny rozkład.
- Ile z różnicy wobec PSI to wolniejszy procesor, a ile sieć. PSI działa w centrum danych Google i z tych danych nie da się tego rozdzielić.
- Jak strony reagują na kliknięcia i pisanie. Testy nie miały żadnej interakcji, więc nic nie mówią o INP, a laboratoryjny CLS obejmuje tylko przesunięcia w trakcie ładowania.
- Jak laboratorium ma się do terenu w ogóle. Pięć znanych stron, po jednym wywołaniu, to ilustracja.
Pliki
Pola w plikach danych mają angielskie nazwy, wspólne dla obu wersji językowych.
summary.json: mediany, rozrzuty i różnice; stąd pochodzi każda liczba w artykulelab-runs.json: wszystkie 28 lokalnych prób w skróconej formiepsi-runs.json: odpowiedzi PSI z metrykami laboratoryjnymi i blokami danych CrUXdiagnostic-home.json: dodatkowa próba diagnostyczna strony głównejsources.json: dokumentacja cytowana w artykulelab-runs.mjs: uruchamia Lighthouse lokalniepsi-runs.mjs: wywołuje API PSIanalyze.mjs: liczy summary.json z prób, bez dostępu do siecicharts.mjs: rysuje oba wykresy z artykułu (--lang plalbo--lang en)homepage-fix-2026-09-24/README.md: strona główna przed poprawką i po niejmethodology.md: ta strona po angielsku
Żeby to powtórzyć, zainstaluj lighthouse@13.5.0, a potem uruchom CHROME_PATH=<Chromium> node lab-runs.mjs --runs 7 --out lab-runs.json, node psi-runs.mjs --out psi-runs.json (opcjonalny klucz podajesz w PAGESPEED_API_KEY i nie trafia on do żadnego pliku) oraz node analyze.mjs.