Narzędzia do testowania Core Web Vitals w 2026

Porównujemy 10 narzędzi do testowania Core Web Vitals najczęściej używanych w polskich projektach: Google PageSpeed Insights, Lighthouse (Chrome DevTools + CLI), Chrome User Experience Report (CrUX), web.dev Measure, GTmetrix, WebPageTest, Treo, Calibre, sitespeed.io i SpeedCurve. Pokazujemy, czym różni się lab data od field data, kiedy Lighthouse wystarczy, a kiedy trzeba sięgnąć po Real User Monitoring (RUM), oraz ile realnie kosztuje monitoring wydajności w skali roku.

Czym są Core Web Vitals i czym różni się field data od lab data?

Core Web Vitals to zestaw trzech metryk wydajności, które Google używa jako sygnał rankingowy od czerwca 2021 r.: LCP (Largest Contentful Paint, czas wyświetlenia największego elementu strony), INP (Interaction to Next Paint, czas reakcji na interakcję użytkownika, zastąpił FID w marcu 2024 r.) i CLS (Cumulative Layout Shift, miara przesunięć układu strony). Każda metryka ma trzy progi: “Good”, “Needs Improvement” i “Poor”. Strona przechodzi Core Web Vitals tylko wtedy, gdy wszystkie trzy metryki są w zielonym progu dla 75-tego percentyla użytkowników.

Field data to pomiary zebrane z rzeczywistych wizyt na stronie. Źródłem jest Chrome User Experience Report (CrUX), publiczna baza danych Google, która agreguje pomiary z przeglądarki Chrome użytkowników, którzy zgodzili się na zbieranie danych telemetrycznych. CrUX raportuje 75-ty percentyl LCP, INP, CLS, FCP i TTFB dla każdej domeny i każdego URL-a, który ma wystarczająco wizyt (zwykle minimum 1 000 unique users miesięcznie). To dane, które Google realnie używa do rankingu.

Lab data to pomiary z kontrolowanego, syntetycznego środowiska: jedno urządzenie, jedna sieć, brak zmiennych. Narzędzie (Lighthouse, WebPageTest) emuluje przeglądarkę i mobile network (zwykle “Slow 4G”), pobiera stronę i mierzy metryki w izolacji. Wynik jest powtarzalny, ale nie odzwierciedla doświadczenia rzeczywistych użytkowników, którzy mają różne urządzenia, sieci, lokalizacje i historię wizyt. Lab data jest świetna do diagnostyki (“co konkretnie zwalnia tę stronę”), ale nie nadaje się do oceny realnej wydajności. Więcej kontekstu o samych metrykach jest w naszym poradniku szybkość ładowania strony: jakie podstawy warto optymalizować.

Trzecim rodzajem danych jest RUM (Real User Monitoring), czyli telemetria zbierana bezpośrednio z odwiedzin użytkowników na własnej domenie. RUM łączy zalety field data (rzeczywiste pomiary) z zaletami własnego pipeline (segmentacja per kraj/urządzenie/typ strony, integracja z analityką). RUM jest dziś dla domen w segmencie e-commerce z 100 000+ wizyt miesięcznie standardem branżowym, ale wymaga osobnego narzędzia (SpeedCurve, Calibre, Akamai mPulse, Cloudflare Web Analytics).

10 narzędzi do testowania Core Web Vitals w 2026

Tabela zestawia 10 najczęściej używanych narzędzi. Ceny przeliczone z USD/EUR po kursie 4,15 zł/USD i 4,40 zł/EUR. Kolumna “Typ danych” mówi, czy narzędzie zbiera field data (z CrUX lub własnego RUM), czy lab data (syntetyczny pomiar).

Trzy obserwacje z tabeli. Pierwsze cztery narzędzia (PageSpeed Insights, Lighthouse, CrUX, web.dev) są oficjalne od Google, bezpłatne i pokrywają 80% potrzeb przeciętnej polskiej domeny. GTmetrix i WebPageTest to klasyczne lab tools dla deweloperów (świetne do debug). Treo, Calibre i SpeedCurve to RUM/monitoring platformy z opłatą miesięczną, sensowne dla domen z 100 000+ unique users miesięcznie. sitespeed.io to open source alternatywa dla zespołów technicznych.

Field data vs lab data: dwie różne prawdy o wydajności

Najczęstszym błędem zespołów SEO jest mylenie field data z lab data i raportowanie klientowi “wynik PageSpeed 95/100” jako sukcesu. Tabela poniżej pokazuje różnice między tymi dwoma źródłami i kiedy używać którego.

Praktyczna konkluzja: dla domen z ruchem 1 000+ unique users miesięcznie zawsze należy patrzeć przede wszystkim na field data (PageSpeed Insights “Field Data” lub bezpośrednio CrUX). Lab data służy do diagnostyki konkretnych problemów i rzadko jest źródłem rzetelnego raportu o wydajności. Dla domen poniżej 1 000 users CrUX nie ma wystarczająco danych (raporty pokazują “Not enough data”), więc trzeba patrzeć na lab + własne RUM. Im większa domena, tym większa wartość field data i RUM (więcej w poradniku jak przyspieszyć działanie strony internetowej).

Szczegółowy ranking 10 narzędzi do testowania Core Web Vitals

Google PageSpeed Insights

Oficjalny dashboard od Google. Łączy field data z CrUX z lab data z Lighthouse i pokazuje obie warstwy obok siebie. Bezpłatny, dostępny przez URL. Mocne strony: pierwsze źródło prawdy o tym, jak Google ocenia stronę, integracja z GSC, pokrycie 80% potrzeb. Słabe strony: brak segmentacji (jedna metryka per URL), brak alertów, brak historii dla pojedynczego URL-a.

Lighthouse (Chrome DevTools / CLI)

Wbudowane w Chrome DevTools, dostępne także jako CLI dla CI/CD pipeline. Lab data tool, generuje raport z 5 obszarów: Performance, Accessibility, Best Practices, SEO, PWA. Bezpłatny. Mocne strony: integracja z Chrome, automatyzacja w CI/CD, szczegółowe diagnostyki “Opportunities”. Słabe strony: tylko lab data, wyniki zależą od mocy urządzenia testującego (CI runner z 16 vCPU pokaże inne wyniki niż laptop deweloperski).

Chrome User Experience Report (CrUX)

Publiczna baza danych Google z field data. Dostępna przez BigQuery (dla całych zbiorów) lub przez PageSpeed Insights API (dla pojedynczych URL-i). Bezpłatna. Mocne strony: oryginalne źródło danych, których Google używa do rankingu, możliwość analizy historycznej i agregacji per domena. Słabe strony: rolling window 28 dni (opóźnienie), brak danych dla niskotrafficowych URL-i.

web.dev Measure

Oficjalny dashboard Google dla deweloperów. Pokazuje wynik Lighthouse + CrUX z dodatkowymi wytycznymi i linkami do dokumentacji. Bezpłatny. Mocne strony: świetny do nauki, integracja z dokumentacją, wytyczne “co konkretnie poprawić”. Słabe strony: brak monitoringu w czasie, jedna domena/URL na raz.

GTmetrix

Komercyjna platforma do testowania wydajności. Cena od 14 USD/mies. (Pro). Mocne strony: czytelne raporty dla klientów, archiwum testów historycznych w pakietach Pro, możliwość testowania z różnych lokalizacji. Słabe strony: lab data only (bez field), w bezpłatnej wersji ograniczone funkcje, archaiczny UI.

WebPageTest

Najbardziej rozbudowane lab data tool na rynku, ze szczegółowymi waterfallami i opcjami konfiguracji (urządzenia, sieci, lokalizacje). Cena: bezpłatny dla okazjonalnego użycia, od 17 USD/mies. dla Pro. Mocne strony: maksymalna głębia diagnostyki, dane z 20+ lokalizacji globalnie, integracje CI/CD. Słabe strony: krzywa nauki, brak field data, mniej czytelne raporty dla nietechnicznych odbiorców.

Treo

Cloud monitoring CWV z wbudowanym CrUX trackingiem i własnym RUM. Cena od 32 USD/mies. Mocne strony: monitorowanie wszystkich URL-i domeny z alertami, dobre integracje z GSC i Datadog, niski próg cenowy w segmencie RUM. Słabe strony: mniejsza społeczność, mniej tutoriali niż konkurencja.

Calibre

Platforma do continuous performance monitoring z lab + RUM. Cena od 65 USD/mies. Mocne strony: świetne integracje CI/CD, dashboardy dla zespołu, A/B porównanie wersji. Słabe strony: cena, krzywa nauki, dla bardzo dużych domen może wymagać enterprise plan.

sitespeed.io

Open source stack do monitoringu wydajności, hostowany na własnej infrastrukturze. Cena: zero (open source). Mocne strony: pełna kontrola, brak limitów URL, integracja z Grafana. Słabe strony: wymaga setupu DevOps (Docker, Grafana, InfluxDB), brak commercial support, koszt utrzymania własnej infrastruktury.

SpeedCurve

Enterprise platforma do RUM i synthetic monitoringu z najlepszym UI w segmencie premium. Cena od 144 USD/mies. Mocne strony: najlepsze dashboardy dla C-level, A/B testy zmian wydajności, wsparcie globalnych zespołów. Słabe strony: cena, dla MŚP nieuzasadnione.

Kiedy potrzebujesz RUM, a kiedy wystarczy Lighthouse?

Pytanie “RUM czy synthetic” jest podstawowym wyborem w monitoringu wydajności. RUM (Real User Monitoring) zbiera dane od prawdziwych użytkowników w przeglądarce. Synthetic monitoring (Lighthouse, WebPageTest, GTmetrix) syntetycznie testuje stronę w zdefiniowanym środowisku. Tabela porównuje oba podejścia.

Dla większości polskich domen ścieżka rozwoju wygląda następująco: na starcie wystarczają bezpłatne PageSpeed Insights + Lighthouse w CI/CD. Po przekroczeniu 10 000 unique users miesięcznie warto dodać monitoring CrUX (Treo, własny dashboard z BigQuery). Powyżej 100 000 unique users monthly RUM staje się obowiązkowy, bo bez niego nie da się rzetelnie ocenić wpływu zmian na rzeczywistych użytkowników. Najczęstszą zalecaną kombinacją u średnich i dużych klientów SemTree jest Lighthouse CI (do regression testing) + Treo lub Calibre (do RUM). Pomocnym jest też tutaj kontekst aktualnych technik optymalizacji, jak preload zasobów krytycznych (więcej w poradniku preload strony internetowej).

Nasze ekomendacje: które narzędzie do testowania Core Web Vitals wybrać?

Wybór narzędzia zależy od skali domeny, częstotliwości deployów i tego, czy zespół ma kompetencje devops. Tabela podsumowuje rekomendacje dla 6 typowych scenariuszy.

Dla większości polskich domen w 2026 r. wystarczające jest połączenie PageSpeed Insights (jako podstawowe źródło field data) z Lighthouse w CI/CD pipeline (jako gatekeeper przed deployem). Dodanie Treo (32 USD/mies.) lub Calibre (65 USD/mies.) staje się sensowne po przekroczeniu 50 000 unique users miesięcznie, gdy własny RUM daje istotnie lepsze dane niż agregaty CrUX. Aspekty mobile-first nadal pozostają osobnym ważnym wymiarem (Google ranking jest oparty głównie na mobile, więc desktop test pokazuje dane, których Google realnie nie używa, zobacz algorytm Google mobile-first indexing).

Niezależnie od narzędzia, sam pomiar nie poprawi wydajności. Lista 17 issues z Lighthouse to początek pracy. Realna optymalizacja Core Web Vitals wymaga współpracy zespołu SEO z developerami (refaktor JS/CSS, lazy loading, code splitting), infrastrukturą (CDN, cache, serwer) i designem (wagi obrazów, typografia, fonty). Sam wynik 95/100 w PageSpeed Insights nigdy nie poprawi pozycji, jeśli pod spodem CLS u użytkowników skacze ze względu na późno doładowywane banery cookies.