Narzędzia do diagnostyki wydajności 2026

Narzędzia do diagnostyki wydajności strony w 2026 roku dzielą się na cztery kategorie: lab testing (Lighthouse, WebPageTest), real user monitoring (CrUX, SpeedCurve), profilowanie developerskie (Chrome DevTools, React DevTools Profiler) oraz syntetyczny monitoring ciągły (Pingdom, Calibre, SpeedCurve synthetic). Każda ma inne zastosowanie, inny koszt i inne ograniczenia.

Ten przewodnik wybiera 18 narzędzi, które realnie używamy w pracy na 47 projektach optymalizacji CWV w 2024–2025 i grupuje je według scenariusza: co do debugowania, co do monitoringu, co do raportowania klientowi, co do CI/CD. Budżety od 0 zł do 2 tys. zł miesięcznie.

Ten tekst uzupełnia szerszy kontekst CWV: progi metryk i ich znaczenie omawia przewodnik Core Web Vitals 2026, a specyfika WordPressa – checklista WordPress CWV. Tutaj skupiamy się na stacku narzędziowym.

Bezpłatny stack – czego nie kupisz za zero

Zanim wydacie jakiekolwiek pieniądze na płatne narzędzia, zbudujcie darmowy stack. W 85% przypadków mniejszym i średnim firmom całkowicie wystarcza. Płatne tools są uzasadnione dopiero, gdy zero-cost stack nie daje odpowiedzi na konkretne pytania.

Google Search Console — Core Web Vitals report

Najważniejsze darmowe narzędzie. Pokazuje status URL-i per status (good, needs improvement, poor) z podziałem na mobile/desktop. Agregacja jest per „group of similar URLs” – co z jednej strony upraszcza raport, z drugiej ukrywa granularność.

Kiedy używać: weekly check, po każdym dużym deployu, przy spadku pozycji w SERP. Nie używać do: szczegółów konkretnej strony — tam lepszy PageSpeed Insights.

PageSpeed Insights

Dwa dane w jednym interfejsie: field data z CrUX (real users, 28 dni) i lab data z Lighthouse (symulacja). Pokazuje LCP/INP/CLS na mobile i desktop osobno, z historią 6 ostatnich pomiarów.

Ograniczenia: field data dostępne tylko dla URL-i z dostatecznym ruchem (zwykle >1000 sesji/mies.). Dla nowych stron lub low-traffic widać tylko lab data. PageSpeed Insights nie daje alertów – trzeba sprawdzać ręcznie lub via API.

Chrome DevTools

Niedocenione, a to jest najpotężniejsze darmowe narzędzie frontend performance. Trzy panele, które używam codziennie: Powiązane zagadnienia opisujemy w metodyki audytu SEO.

• Performance panel – profilowanie CPU i renderingu w realnym czasie. Widać long tasks, event handler timing, layout shifts. Tutaj debuguje się INP.
• Network panel – waterfall wszystkich requestów. Preload verification, request priority, timing. Tutaj debuguje się LCP.
• Rendering → Frame Rendering Stats + Layout Shift Regions — pokazuje wizualnie, które elementy powodują CLS.

Lighthouse

Lokalna wersja PSI, uruchamiana w DevTools (panel Lighthouse) lub CLI (npm install -g lighthouse). CLI umożliwia batch testing i integrację z CI/CD.

Kluczowy skill: czytanie „Diagnostics” i „Opportunities” sekcji, które Lighthouse proponuje. Nie wszystkie są priorytetowe – np. „Avoid chained critical requests” często ma niskie znaczenie w porównaniu do „Eliminate render-blocking resources” i „Properly size images”.

web-vitals.js od Google

Biblioteka 8 KB, którą dodajecie do strony. Mierzy LCP/INP/CLS per sesja użytkownika i wysyła raporty tam, gdzie chcecie (GA4, custom endpoint, Sentry, console.log). Tryb v3+ attribution daje dodatkowy kontekst: który element jest LCP, który handler spowodował INP, który element shifted dla CLS.

CrUX API + BigQuery

CrUX API (darmowe, limit 150 queries/min, API key z Google Cloud) pozwala pobrać dane CWV dla dowolnej publicznej strony. Przydatne do: historycznego trackowania własnej strony (GSC pokazuje tylko 90 dni), analizy konkurencji, automatyzacji raportów.

Alternatywa: BigQuery public dataset chrome-ux-report – pełne miesięczne snapshoty CrUX dla milionów domen. Wymaga SQL i Google Cloud account. Koszt: <1 USD/mies. przy normalnym wolumenie zapytań.

Płatne narzędzia RUM – kiedy warto

Darmowy stack ma dwa ograniczenia: (1) ograniczona segmentacja, (2) brak alertów w czasie rzeczywistym. Dla firmy, gdzie strona generuje 500 tys. zł+ miesięcznie, te ograniczenia bolą. Wtedy warto wydać 89–499 USD/mies. na płatny RUM. Praktyczne wskazówki zawiera pełnym przewodniku SEO 2026.

SpeedCurve

• Cena: 149 USD/mies. (starter), 499 USD/mies. (pro).
• Co daje: RUM + synthetic w jednym panelu, piękne dashbordy, trendy historyczne, alerty email/Slack, integracja z deploymentami.
• Dla kogo: e-commerce od 3 mln zł GMV/rok, agencje obsługujące 10+ klientów.
• Co nie: startupy na początku (overkill), firmy z własnym zespołem DevOps (mogą zbudować taniej).

Calibre

• Cena: 89 USD/mies. (starter), 349 USD/mies. (pro).
• Co daje: synthetic monitoring Lighthouse z GitHub integration (PR checks), profile scenariuszy (login, checkout, koszyk), user journey monitoring.
• Dla kogo: zespoły developerów (bardziej technical orientation niż SpeedCurve), produkty z kluczowymi user journeyami.
• Co nie: marketingowcy bez technicznego background (krzywa nauki).

Datadog RUM

• Cena: 1,50 USD/1000 sesji (na podstawie wolumenu).
• Co daje: pełna obserwowalność (logs + metrics + traces + RUM w jednym), session replay, error tracking.
• Dla kogo: firmy, które już mają Datadog dla infrastruktury — dodanie RUM to minimalny overhead.
• Co nie: małe firmy bez Datadoga – koszt wejścia wysoki.

New Relic Browser

• Cena: od 99 USD/mies., skaluje się z wolumenem.
• Co daje: pełny observability stack, monitoring BE + FE + RUM, AIOps.
• Dla kogo: enterprise z dojrzałymi praktykami SRE.

Porównanie w tabeli

Narzędzie	Cena od	RUM	Synthetic	CI/CD	Alerty	Session replay
PSI + DevTools	0 zł	częściowo	manual	via Lighthouse CI	nie	nie
SpeedCurve	149 USD	tak	tak	tak	tak	nie
Calibre	89 USD	nie	tak	tak	tak	nie
Datadog RUM	od 1,5 USD/1k sess.	tak	osobno	tak	tak	tak (dodatek)
New Relic	99 USD	tak	tak	tak	tak	nie
GA4 + web-vitals.js	0 zł	tak	nie	nie	częściowo	nie

Narzędzia debugowania – INP, LCP, CLS

Debug każdej metryki wymaga innego zestawu narzędzi, bo każda ma inne źródło problemu.

Debugging LCP

1. PageSpeed Insights – pierwsze miejsce. Pokazuje „Largest Contentful Paint element” (zrzut), TTFB, czas poszczególnych faz (resource load delay, render delay).
2. Chrome DevTools Network panel — sprawdzenie, czy LCP image jest priorytetowo pobrany (Priority: High), czy preload działa, czy nie blokuje go render-blocking CSS.
3. WebPageTest (darmowe, webpagetest.org) – waterfall z różnych lokalizacji geograficznych, porównanie TTFB z wielu regionów. Bezcenne dla międzynarodowych stron.
4. GTMetrix (freemium, gtmetrix.com) – drugie źródło danych Lighthouse + waterfall. Wolny, ale darmowe testy z 7 lokalizacji.

Debugging INP

1. Chrome DevTools Performance panel – nagrywajcie sesję podczas interakcji, szukajcie „Long tasks” markerów.
2. web-vitals.js w trybie attribution — raportuje nazwę eventu, ID elementu, czasy faz (input delay, processing, presentation).
3. React DevTools Profiler – dla aplikacji React, pokazuje, które komponenty re-renderują się podczas interakcji.
4. Google Tag Assistant + GTM Preview – dla stron z dużą ilością tagów GTM, sprawdzenie, które skrypty blokują main thread.

Debugging CLS

1. Chrome DevTools Rendering panel – opcja „Layout Shift Regions” pokazuje wizualnie obszary, które się przesuwają.
2. web-vitals.js z CLS attribution — raportuje konkretne elementy, które shifted.
3. Lighthouse „Avoid large layout shifts” audit – pokazuje element-by-element, co przyczynia się do CLS.
4. Testowanie na slow 3G w DevTools – wiele CLS widać tylko na wolnych połączeniach, gdy reklamy lub fonty ładują się z opóźnieniem.

Synthetic monitoring – ciągły nadzór

Synthetic monitoring to uruchamianie Lighthouse (lub innego test framework) z określoną częstotliwością z konkretnej lokalizacji. Wartość: wykryjecie regresje w godzinach, nie w tygodniach.

GitHub Actions + Lighthouse CI

Zero-cost setup dla developerów. Każdy PR wyzwala Lighthouse na deploy preview, wyniki pojawiają się jako komentarz w PR. Regresja >5% = failing check.

Konfiguracja: plik lighthouserc.js z listą URL do testowania, job w .github/workflows/lighthouse.yml. Integracja z Vercel, Netlify, Cloudflare Pages. Czas wdrożenia: 2–4 godziny.

Cron + Lighthouse CLI + webhook

Dla stron produkcyjnych poza GitHub flow: prosty skrypt Node.js, który uruchamia Lighthouse co godzinę z AWS Lambda (koszt ~2 USD/mies.), zapisuje wyniki do S3 lub BigQuery, wysyła webhook do Slacka przy przekroczeniu progu.

Platformy SaaS

• DebugBear (29 USD/mies.) — tanie, jasne dashbordy, synthetic z wielu lokalizacji.
• Pingdom (15 USD/mies. basic) – klasyk, ale ostatnio mniejsza inwestycja w frontend performance.
• Uptrends (28 USD/mies.) – kombinacja uptime + CWV monitoring.

Raportowanie klientowi – Looker Studio + CrUX API

Raporty dla klientów (lub zarządu) nie powinny być zrzutem z PageSpeed Insights. Powinny być dashbordem z trendem, porównaniem do konkurencji, segmentacją, komentarzem. Looker Studio + CrUX API to darmowy sposób na profesjonalny raport.

Architektura raportu

1. Źródło danych — Google Sheets z pobranymi raz dziennie danymi CrUX API (skrypt Apps Script uruchamiany cron).
2. Model danych – tabela per URL per data per metryka per device. 3 metryki × 2 devices × 30 URL × 90 dni = 16200 wierszy.
3. Dashboard – Looker Studio z widokiem wysokopoziomowym (% URL-i „good” w czasie) + drilldown per URL.
4. Komentarz – tygodniowa notka z SEO analityka: co się zmieniło, dlaczego, plan na kolejny tydzień.

Struktura raportu PDF dla klienta

• Strona 1: executive summary — status CWV vs cel, trend 90 dni, główne wnioski.
• Strona 2: performance per device – mobile vs desktop, P75.
• Strona 3: benchmarking – nasze CWV vs 3 konkurenci.
• Strona 4: problematic pages – top 5 stron z najgorszym CWV, diagnoza.
• Strona 5: roadmap — co zrobione, co planowane na kolejne 30 dni.

Typowe zestawy – budżet i scenariusz

Cztery gotowe konfiguracje dla najczęstszych sytuacji.

Startup / solo freelancer – 0 zł/mies.

• Google Search Console (darmowe).
• PageSpeed Insights (darmowe).
• Chrome DevTools (darmowe).
• web-vitals.js + GA4 (darmowe, 3h wdrożenia).
• Ręczne sprawdzenia co 2 tygodnie.

Wartość: 80% tego, co daje płatny stack, za zero złotych.

SMB (10–50 osób) – 100–200 USD/mies.

• Cały darmowy stack + DebugBear (29 USD) lub Calibre starter (89 USD).
• Lighthouse CI w GitHub Actions.
• Raport miesięczny do zarządu z Looker Studio.
• Alerts w Slacku przy regresach.

E-commerce 3–30 mln zł GMV — 300–600 USD/mies.

• SpeedCurve starter (149 USD) lub Calibre pro (349 USD).
• Web-vitals.js w produkcji z custom endpointem.
• CrUX API w własnym dashboardzie.
• Dedykowany frontend + SEO analityk z 30% etatu na CWV.

Enterprise – 1000+ USD/mies.

• Datadog RUM + APM (pełna obserwowalność).
• SpeedCurve pro + synthetic w wielu lokalizacjach.
• Custom RUM pipeline do BigQuery + Looker.
• Dedykowany performance engineer (minimum 50% etatu).

Błędy w doborze narzędzi

Błąd 1: Kupowanie SpeedCurve, zanim darmowy stack jest wykorzystany

Najczęstszy błąd. Firma kupuje SpeedCurve za 149 USD/mies., ale nie używa Google Search Console ani nie wdrożyła web-vitals.js w GA4. Darmowe rozwiązania dałyby 80% wartości – SpeedCurve to jedynie 20% extra.

Błąd 2: Optymalizacja pod Lighthouse score

Lighthouse to lab tool. Jego score (0–100) nie jest metryką rankingową. Google używa CrUX. Firma, która goni Lighthouse 100/100, marnuje czas na rzeczy, których real users nie widzą.

Błąd 3: Brak segmentacji mobile/desktop

Agregaty mobile+desktop ukrywają problem. Desktop często jest „good”, mobile „poor”. Tymczasem ranking Google to mobile-first. Zawsze segmentujcie.

Błąd 4: Ignorowanie konkurencji

Wasz CWV jest „good”? Super. Ale jeśli konkurencja ma LCP 1,2s a wy 2,3s, wciąż przegrywacie. Benchmarking via CrUX API jest darmowy i obowiązkowy.

Błąd 5: Payed tooling bez procesu

Dashbord w SpeedCurve, ale nikt nie patrzy na niego więcej niż raz na miesiąc. Alerty w Slacku, na które nikt nie reaguje. Narzędzia bez procesu to marnowanie budżetu. Najpierw proces (kto patrzy, kiedy, co robi), potem narzędzie.

Przykładowy workflow diagnostyki — 2 godziny pracy

Teoria narzędziowa jest OK, ale co w praktyce? Poniższy workflow to 2-godzinna sesja diagnostyki dla strony, która dostała alert „needs improvement” w Search Console. To dokładnie taka sesja, jaką prowadzimy co tydzień w agencji.

Krok 1: Baseline z CrUX (10 minut)

Otwieramy GSC → Experience → Core Web Vitals. Notujemy: które URL-e są „poor”, które „needs improvement”, dla jakich metryk. Następnie otwieramy PageSpeed Insights dla 3 reprezentatywnych URL z kategorii „poor” i zapisujemy aktualne wartości P75 dla LCP/INP/CLS mobile.

Krok 2: Lab diagnosis (30 minut)

Dla każdego z 3 URL uruchamiamy Lighthouse mobile audit w DevTools. Notujemy: (1) które „Opportunities” mają największy potential saving (w ms), (2) które „Diagnostics” wskazują na poważny problem. Zrzuty ekranu do raportu.

Dodatkowo – Chrome DevTools Network panel z emulacją Fast 3G. Waterfall pokazuje, co blokuje LCP. Pliki >200 KB, render-blocking CSS, brak preload — wszystko zapisujemy.

Krok 3: Real user data (25 minut)

Jeśli strona ma wdrożoną web-vitals.js + GA4, pobieramy dane z ostatnich 7 dni. Segmentacja: device, country, page_type. Wyciągamy 3–5 najczęstszych wzorców problemów (np. „mobile Android ma 2x gorszy INP niż iOS”, „country DE ma wyższy TTFB niż PL”).

Jeśli RUM nie jest wdrożony — to top priority: wdrożenie web-vitals.js to 2 godziny, bez tego nie zobaczycie prawdziwego obrazu.

Krok 4: Benchmark z konkurencją (25 minut)

Przez CrUX API pobieramy dane dla 3 konkurentów na top 5 kluczowych URL. Porównujemy: są oni lepsi/gorsi, w których metrykach? To kontekst dla prezentacji zarządowi – „nasz LCP 2,8s, benchmark konkurencji 1,9s”.

Krok 5: Priorytetyzacja i planowanie (30 minut)

Z danych z kroków 1–4 piszemy listę 5–8 konkretnych zadań z priorytetami: (1) impact na CWV (wysokość dźwigni), (2) effort implementacji (roboczogodziny), (3) dependency (co blokuje co). Top 3 zadania trafiają do sprintu – reszta do backlogu.

Wynik sesji

Po 2 godzinach mamy: baseline z CrUX, diagnozę lab z Lighthouse, segmentację RUM, benchmark konkurencji, listę 5–8 zadań priorytetyzowanych, szacunek czasu implementacji i oczekiwanego lifta. To jest wartość, którą inaczej dałby drogi audyt zewnętrzny za 8–15 tys. zł.

Integracje z WordPress i popularnymi CMS

WordPress ma kilka pluginów performance monitoring. Większość jest ograniczona, ale dla małych stron wystarczająca.

Site Kit by Google

Darmowy oficjalny plugin Google dla WordPress. Integracja GSC + GA4 + PSI + AdSense w jednym panelu. CWV widoczne w dashboardzie Admin. Najszybsze wdrożenie (5 minut).

Jetpack Boost

Pluginn performance Automattic. Darmowy, automatyzuje critical CSS, lazy load, defer non-critical JS. Ma wbudowany speed score. Dla blogów WP – najlepsze wejście w optymalizację.

WP Rocket

Płatny plugin cache (59 USD/rok). Nie monitoring, ale optymalizacja — cache, minification, lazy, critical CSS. Widoczny efekt na LCP 200–800ms. Pair z ImagineLoad lub ShortPixel dla obrazów.

Zespół i role – kto pracuje z narzędziami CWV

Narzędzia CWV w 2026 nie są zadaniem jednej osoby – są dystrybuowane przez cross-functional team. Różne osoby korzystają z różnych narzędzi, zależnie od swojej roli.

SEO analityk techniczny

Używa: Google Search Console, PageSpeed Insights, CrUX API, Looker Studio. Codzienna rutyna: check GSC Experience, tygodniowe raporty dla marketingu, miesięczne raporty dla zarządu. Wynagrodzenie w Polsce: 8–14 tys. zł brutto dla mida, 14–22 tys. zł dla seniora.

Frontend developer

Używa: Chrome DevTools, Lighthouse CLI, web-vitals.js, React DevTools Profiler. Codzienna rutyna: debugowanie konkretnych regresji, optymalizacja komponentów, code reviews pod kątem performance. Wynagrodzenie: 12–18 tys. zł (mid), 18–28 tys. zł (senior).

DevOps / SRE

Używa: Datadog / New Relic (observability), Lighthouse CI, CDN dashboards (Cloudflare, Akamai), performance logs z application layer. Codzienna rutyna: monitoring TTFB, cache hit ratios, CDN edge performance. Wynagrodzenie: 16–24 tys. zł (mid), 22–35 tys. zł (senior).

Performance engineer (w enterprise)

Używa: wszystkiego powyższego + custom profiling tools, PerfDash własnego, integration z APM. Najczęściej w firmach 100+ osób z dedykowanym stanowiskiem. Wynagrodzenie: 22–35 tys. zł.

Kto kupuje narzędzia

Budżet narzędzi powinien być centralny (CTO lub Head of Engineering decyduje), nie per-team. Powód: overlap funkcjonalności. Trzy osoby kupujące trzy podobne narzędzia = koszt 3x wyższy niż jedno centralne. Standardowa praktyka: raz do roku review stacka narzędziowego, konsolidacja, negocjacje enterprise z vendorami.

Roadmapa wdrożenia stacka – 30/60/90 dni

Dni 1–30: fundament darmowy

• Google Search Console — weryfikacja wszystkich domen.
• PageSpeed Insights – manual audit top 20 URL (baseline).
• web-vitals.js – wdrożenie + GA4 events + BigQuery export.
• Looker Studio – pierwszy dashboard z CrUX API.
• Chrome DevTools — szkolenie frontendu z Performance/Network/Rendering.

Dni 31–60: automatyzacja

• Lighthouse CI w GitHub Actions (lub equivalent dla GitLab/Bitbucket).
• Cron job dla daily CrUX snapshot do BigQuery.
• Slack webhook dla alertów przy regresie.
• Tygodniowy raport automatyczny w kanale Slack „#performance”.
• Pierwsza iteracja optymalizacji – top 3 URL z najgorszym CWV.

Dni 61–90: eskalacja jeśli potrzebna

• Weryfikacja: czy darmowy stack + proces wystarcza?
• Jeśli nie – decyzja: SpeedCurve, Calibre lub Datadog RUM.
• Integracja z process engineering (PR checks, deployment marks).
• Pierwszy miesięczny raport do zarządu z trendem 90 dni.
• Plan Q+1 – co optymalizujemy w kolejnym kwartale.

FAQ — najczęstsze pytania

Które narzędzie jest najlepsze do debugowania INP?

Kombinacja: web-vitals.js w trybie attribution (do złapania problemu w realnych sesjach) + Chrome DevTools Performance panel (do analizy w środowisku dev). web-vitals.js raportuje, który element i który event, a DevTools pokazuje na timeline, co się dzieje w handlerze. React DevTools Profiler jest dodatkiem dla aplikacji React. Żadne narzędzie solo nie wystarczy — zawsze 2 razem.

Czy płatne narzędzia są warte swojej ceny?

Tylko, gdy darmowy stack osiągnął swój sufit. Firma bez web-vitals.js w GA4, bez CrUX API i bez Lighthouse CI ma 80% wartości SpeedCurve za zero złotych. Płatne narzędzia mają sens dla: (1) e-commerce 3M+ GMV rocznie, (2) agencji z 10+ klientami, (3) firm z kontraktami SLA. Dla reszty – darmowy stack plus 1 godzina pracy tygodniowo.

Jak często mierzyć CWV i raportować?

Daily automated (przez Lighthouse CI w CI/CD), weekly manual (spojrzenie w GSC i PSI), monthly report do zarządu/klienta (Looker Studio), quarterly deep dive (audyt pełny + roadmap). Zbyt częste raporty są ignorowane (noise), zbyt rzadkie – tracicie kontekst. Rytm miesięczny dla decision-makers to sweet spot.

Czy Ahrefs i Semrush mierzą CWV?

Tak, oba narzędzia pokazują CWV dla stron w raportach audytów, ale danymi są snapshots Lighthouse (lab, nie field). To OK do ogólnego przeglądu, ale nie nadaje się jako jedyne źródło. Google do rankingu używa CrUX (field). Ahrefs i Semrush przydają się do porównania konkurencji i znalezienia stron z poor CWV w audycie – ale CrUX API daje te same dane precyzyjniej i za darmo.

Jakie narzędzie używać do A/B testowania performance zmian?

SpeedCurve lub Calibre mają natywny support dla deployment marks (oznaczenia „to była wersja v1.2” na wykresie). Darmowa alternatywa: GA4 events z parametrem „build_version” + custom explore. Niezależnie od narzędzia: zawsze testujcie w 3 segmentach (mobile/desktop/country), obserwujcie 7–14 dni przed decyzją, pilnujcie statystycznej istotności (różnica >5% P75 z N>1000 sesji).

Czy Lighthouse score 100/100 gwarantuje „good” CWV?

Nie. Lighthouse to symulacja w lab (emulowany iPhone, 4G slow). Real users mają różne urządzenia, sieci i zachowania. Strony z Lighthouse 95+ bywają „poor” w CrUX, bo np. reklamy, third-party skrypty albo regionalna latencja nie są widoczne w lab. Używajcie Lighthouse jako debugger, CrUX jako wyznacznik sukcesu.

Ile czasu zajmuje wdrożenie pełnego stacka monitoringu CWV?

Darmowy stack (GSC + PSI + web-vitals.js + GA4 + Looker Studio raport): 6–10 godzin frontend + 2–3 godziny analityka. Rozszerzony o Lighthouse CI w GitHub Actions: +3–5 godzin DevOps. Płatny SpeedCurve/Calibre: +2–4 godziny konfiguracji. Dla średniej firmy pełny setup to 2–3 dni pracy seniora. Zwrot: czasochłonność maleje do 0.5h/tydzień po wdrożeniu.

Co dalej

Na początek sprawdź przewodnik Core Web Vitals 2026. Gdy opanujesz podstawy, przejdź do checklist optymalizacji WordPress — tam czekają zaawansowane techniki.