WebPageTest

WebPageTest to darmowe, open-source'owe, laboratoryjne narzędzie do testowania wydajności, po które sięgają techniczni SEO, gdy PageSpeed Insights mówi, że strona jest wolna, ale nie mówi dlaczego — historia, jak czytać waterfall i filmstrip, przepis na polowanie na CLS oraz miejsce WebPageTest obok Lighthouse, PSI i CrUX.

Opublikowano po raz pierwszy: 3 lip 2026 · Ostatnia aktualizacja: 3 sie 2026 · Advanced
Języki

WebPageTest to darmowe, open-source'owe laboratoryjne (syntetyczne) narzędzie do testowania wydajności — stworzone przez Patricka Meenana w 2008 roku jako wewnętrzne narzędzie AOL i przejęte przez Catchpoint w 2020. Podajesz mu URL, prawdziwą lokalizację testową, przeglądarkę i profil sieciowy, a ono uruchamia stronę na prawdziwym urządzeniu i zwraca szczegółowe dane, których żaden pojedynczy wynik nie odda: wykres waterfall (flagi blokujące renderowanie, sekwencjonowanie żądań), widok filmstrip/wideo (klatka po klatce, z opcją Highlight Layout Shifts dla CLS), widok połączenia (DNS/TCP/TLS/TTFB) oraz Core Web Vitals klatka po klatce. Najważniejsza rzecz do zapamiętania: WebPageTest generuje dane laboratoryjne, a nie terenowe — nie zasila sygnału rankingowego Core Web Vitals Google (to dane od prawdziwych użytkowników z CrUX). Służy do diagnozy, a nie do wyniku, który widzi Google. To też nie jest konkurent Lighthouse — możesz uruchomić Lighthouse z jego poziomu. Sięgaj po niego, gdy PageSpeed Insights mówi, że strona jest wolna, ale nie mówi dlaczego ani gdzie w procesie ładowania.

Evidence for this claim WebPageTest provides synthetic browser tests with waterfalls, filmstrips, and configurable test locations and networks. Scope: Lab testing; available features can depend on plan and test agent. Confidence: high · Verified: WebPageTest documentation Evidence for this claim WebPageTest publishes its test server and agent source code in an official repository. Scope: Open-source components; hosted service terms and features are separate. Confidence: high · Verified: WebPageTest GitHub

TL;DR — WebPageTest to darmowe, open-source’owe laboratoryjne (syntetyczne) narzędzie do pomiaru wydajności: adres URL, prawdziwa rozproszona lokalizacja testowa, przeglądarka i profil sieciowy na wejściu, zaawansowana diagnostyka na wyjściu — wodospad (flagi blokowania renderowania, sekwencjonowanie), pasek filmowy/wideo (klatka po klatce, z opcją Highlight Layout Shifts dla CLS), widok połączenia (DNS/TCP/TLS/TTFB) i Core Web Vitals klatka po klatce. Patrick Meenan zbudował go w 2008 roku (wewnętrzne narzędzie AOL); Catchpoint przejął go w 2020 roku; kod pozostaje otwarty na licencji Polyform Shield. Fundament dokładności: generuje dane laboratoryjne, a nie terenowe, więc nie zasila sygnału rankingowego CWV Google (to prawdziwi użytkownicy CrUX). To narzędzie diagnostyczne, a nie wynik, który widzi Google — i nie jest konkurentem Lighthouse, ponieważ możesz uruchomić Lighthouse wewnątrz niego. Sięgaj po niego, gdy PageSpeed Insights mówi Ci, że strona jest wolna, ale nie dlaczego ani gdzie w procesie ładowania.

Czym to naprawdę jest

Każdy wynik WebPageTest to jedno skonfigurowane uruchomienie: adres URL, testowany z konkretnej lokalizacji, na konkretnej przeglądarce i urządzeniu, przez konkretny profil połączenia, w konkretnym momencie. To nie jest uniwersalny pomiar „jak szybka jest Twoja strona” — to dowód z tego uruchomienia i należy go tak czytać.

W tych ramach WebPageTest jest narzędziem do głębokiej diagnostyki w zestawie narzędzi do wydajności sieci. web.dev, własna strona deweloperska Google, ujmuje to dobrze: “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (tłumaczenie) „WebPageTest zawiera zaawansowany zestaw metryk i przeglądarek śladów. Umożliwia dogłębną analizę wydajności Twojej witryny na prawdziwym sprzęcie mobilnym z określonymi warunkami sieciowymi.” (web.dev, “How To Think About Speed Tools”)

Jego strona „audit” dodaje aspekt związany z SEO: “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (tłumaczenie) „WebPagetest sprawdzi również buforowanie treści statycznych, czas do pierwszego bajtu oraz to, czy Twoja witryna efektywnie wykorzystuje CDN-y.” (web.dev, “Audit performance”)

Tam, gdzie pokrewne narzędzia w tym klastrze — Google Lighthouse, PageSpeed Insights i Chrome UX Report (CrUX) — dają wynik lub ocenę zaliczenia/niezaliczenia, WebPageTest dostarcza dowody żądanie po żądaniu, klatka po klatce, które leżą u podstaw wyniku.

Krótka historia — i naprawdę osobliwy przypis

Patrick Meenan stworzył WebPageTest i udostępnił go jako open-source w 2008 roku; początkowo był to wewnętrzne narzędzie testowe w AOL. Catchpoint przejął je w 2020 roku. Strona About opowiada historię pochodzenia wprost: “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (tłumaczenie) „Przejęcie WebPageTest przez Catchpoint w 2020 roku, stworzonego i udostępnionego jako open-source przez Patricka Meenana w 2008 roku, stanowiło znaczący kamień milowy.” Deklarowana misja jest tam bezpośrednia: “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (tłumaczenie) „wolne działanie to nowa awaria, a naszą misją jest umożliwienie Ci dostarczania najlepszych doświadczeń Twoim użytkownikom.” (webpagetest.org/about)

Oto osobliwy przypis, który warto nazwać: Meenan pracuje obecnie w Google nad Chrome i wydajnością sieci. A jednak oficjalna strona Google z narzędziami do Core Web Vitals — web.dev/articles/vitals-tools, dokładnie ta strona, do której dokumentacja Core Web Vitals w Search Central linkuje jako do „różnych narzędzi, które mogą pomóc Ci mierzyć i raportować Core Web Vitals” — nie wspomina o WebPageTest. Wymienia CrUX, PageSpeed Insights, Search Console, Lighthouse, panel Performance w DevTools, bibliotekę JS web-vitals oraz Lighthouse-CI. Narzędzie zbudowane przez osobę, która obecnie tam pracuje, jest nieobecne.

Przeczytaj to jednak uważnie: nie jest to sygnał, że WebPageTest jest przestarzały lub pozbawiony poparcia. Google kuratoruje listę narzędzi własnych produktów; narzędzie open-source innej firmy po prostu się na niej nie znajduje. Inne strony web.dev (speed-tools, performance-audit-tools) pozytywnie odnoszą się do WebPageTest. To luka w kurateli, a nie werdykt dotyczący narzędzia.

Lab vs. pole — rozróżnienie, które ma największe znaczenie

To jest kręgosłup dokładności całego tematu i jest to odpowiednik punktu lab-vs-pole, który przewija się przez cały klaster narzędzi do wydajności sieci.

WebPageTest uruchamia dane laboratoryjne (syntetyczne): kontrolowany, powtarzalny test na maszynie, którą konfigurujesz, w wybranym przez Ciebie momencie. To coś innego niż dane terenowe — pomiary Chrome UX Report (CrUX) od rzeczywistych użytkowników, które Google Search faktycznie wykorzystuje jako sygnał rankingowy Core Web Vitals i które pojawiają się w PageSpeed Insights oraz Search Console.

Więc wprost:

  • Uruchomienie WebPageTest nie zasila sygnału rankingowego Google. Mierzy te same metryki, na których zależy Google (LCP, INP, CLS), ale liczba, na podstawie której Google rankuje, pochodzi z danych terenowych CrUX, a nie z żadnego uruchomienia laboratoryjnego — ani WebPageTest, ani sekcji lab w PSI, ani Lighthouse.
  • WebPageTest służy do diagnozy: odtworzenia problemu, wyizolowania go i potwierdzenia poprawki w szybkiej, kontrolowanej pętli. Dane terenowe (CrUX) to powolne, autorytatywne potwierdzenie, że prawdziwi użytkownicy odczuli poprawę — zobacz Core Web Vitals, aby dowiedzieć się, jak działa ten sygnał rankingowy.

Mówiąc wprost, wynik WebPageTest nie jest — i nie może zastąpić — danych terenowych CrUX, rzeczywistych liczb ruchu użytkowników ani wyniku rankingu Google czy doświadczenia strony. To osobne zbiory danych, które wymagają własnych dowodów; szybki test syntetyczny nie jest dowodem na zmianę żadnego z nich.

Jeśli zapamiętasz tylko jedną rzecz z tej strony: WebPageTest mówi ci, co naprawić; CrUX mówi ci, czy sygnał rankingu Google się zmienił.

Jak przeprowadzić podstawowy test

Podstawowy przepływ jest celowo prosty:

  1. URL. Publiczna strona, którą chcesz przetestować (musi być publicznie dostępna).
  2. Lokalizacja testu. WebPageTest działa na fizycznie rozproszonych prawdziwych maszynach na całym świecie — wybierz taką blisko swojej grupy odbiorców, ponieważ odległość i warunki sieciowe zmieniają wynik.
  3. Przeglądarka / urządzenie. Chrome daje najwięcej danych. Możesz także emulować urządzenia mobilne.
  4. Profil połączenia. Ograniczona sieć (np. wolne połączenie mobilne), aby testować realistyczne warunki, a nie światłowód biurowy.
  5. Powtórzone przebiegi. To jest to, co początkujący pomijają. Wydajność różni się między przebiegami (drgania sieci, obciążenie serwera, rywalizacja o CPU), więc WebPageTest uruchamia wiele testów i raportuje medianę. Nigdy nie ufaj pojedynczemu przebiegowi — czytaj medianę. Pamiętaj jednak, że mediana to nadal syntetyczna próbka z wybranej konfiguracji, a nie pomiar na poziomie populacji tego, czego doświadczają prawdziwi odwiedzający — do tego służą dane terenowe (CrUX).

Każde z tych ustawień jest częścią eksperymentu, a nie przypadkowym szczegółem. Jeśli porównujesz dwa testy — przed/po naprawie lub swoją stronę z konkurencją — porównanie ma sens tylko wtedy, gdy zapiszesz ustawienia i utrzymasz je stałe: ta sama lokalizacja, ta sama przeglądarka, ten sam profil połączenia, ten sam stan pamięci podręcznej (pierwszy widok vs. powtórzony widok) oraz mniej więcej ta sama liczba przebiegów i okno czasowe. Zmiana któregokolwiek z tych elementów między przebiegami może sprawić, że pomyłkowo uznasz dryf konfiguracji testu za rzeczywistą różnicę wydajności.

Czytanie wyników

Wykres kaskadowy

Kaskada to oś czasu żądanie po żądaniu: jeden wiersz na zasób, w kolejności ładowania, każdy pasek pokazujący fazy DNS/połączenie/TLS/oczekiwanie/pobieranie. Oznacza zasoby blokujące renderowanie, pokazuje łańcuchy przekierowań jako dodatkowe skoki i uwidacznia, gdy kilka zasobów na górze blokuje wszystko za nimi. To tutaj „zmniejsz zasoby blokujące renderowanie” przestaje być abstrakcją, a staje się „ten plik CSS, w tej sekundzie”.

Widok połączeń

Pogrupowany według połączeń, a nie żądań, ten widok ujawnia wyszukiwanie DNS, połączenie TCP, negocjację TLS oraz czas do pierwszego bajtu (TTFB) dla każdego hosta. To najszybszy sposób, aby zobaczyć, czy Twoja powolność jest po stronie serwera/sieci (wolny TTFB, zbyt wiele osobnych połączeń), czy po stronie treści.

Pasek klatek / widok wideo — i mój przepis na polowanie na CLS

Pasek klatek to pasek zrzutów ekranu strony malowanej w czasie; widok wideo odtwarza go. To sposób, aby zobaczyć — a nie wywnioskować — kiedy pojawia się główna treść i kiedy coś na stronie skacze.

To funkcja WebPageTest, na której polegam najbardziej, i wielokrotnie ją omawiałem w wystąpieniach i w moim przewodniku po Core Web Vitals od Ahrefs. Aby polować na Cumulative Layout Shift, dokładny przepis, którego używam: “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (tłumaczenie) „W widoku paska klatek użyj następujących opcji: Podświetl zmiany układu, Rozmiar miniatury: Ogromny, Interwał miniatur: 0,1 s.” To zamienia pasek klatek w wysokorozdzielczą oś czasu, na której przesunięcie jest niemożliwe do przeoczenia. W prawdziwym przykładzie z tego przewodnika winowajcą była zmiana czcionki — “Notice how our font restyles between 5.1 secs and 5.2 secs, shifting the layout as our custom font is applied.” (tłumaczenie) „Zauważ, jak nasza czcionka zmienia styl między 5,1 s a 5,2 s, przesuwając układ, gdy stosowana jest nasza niestandardowa czcionka.” Czcionki internetowe, późno ładowane obrazy i wstrzykiwane reklamy to zwykli podejrzani o CLS, a pasek klatek łapie je wizualnie na gorącym uczynku.

Jedna uwaga: zasób kończący ładowanie w waterfallu w tym samym momencie, w którym filmstrip pokazuje skok, to mocny poszlakowy dowód, a nie pewnik — to hipoteza. Potwierdź ją, izolując podejrzanego (zablokuj tę domenę/żądanie lub odrocz je) i uruchamiając ponownie tę samą konfigurację; jeśli przesunięcie zniknie, potwierdziłeś przyczynę, zamiast tylko korelować dwie osie czasu.

Core Web Vitals, klatka po klatce

WebPageTest raportuje LCP, CLS oraz (przy prawdziwej interakcji) INP obok TTFB, FCP i Speed Index — i pozwala zobaczyć, gdzie w trakcie ładowania każde z nich wystąpiło, a nie tylko końcową wartość. Tam, gdzie dostępne są dane terenowe CrUX, można je pokazać obok wyników laboratoryjnych, ale głęboka diagnostyka pochodzi z testu laboratoryjnego.

Zaawansowane funkcje

  • Skrypty / przepływy wieloetapowe. Testuj strony za logowaniem lub przepływ koszyka/płatności — zapisz kroki, aby WebPageTest mierzył prawdziwą podróż użytkownika, a nie tylko zimną stronę główną. Kontroluj i zapisz, od czego zależy skrypt: użyte konto testowe/dane uwierzytelniające, stan konta, dynamiczne treści na stronie oraz Twój limit API — nieudokumentowany skrypt jest równie trudny do porównania między uruchomieniami, jak nieudokumentowany test manualny.
  • Blokowanie domen / żądań. Zablokuj konkretną domenę zewnętrzną i uruchom ponownie, aby dokładnie zmierzyć, ile kosztuje Cię ten widget czatu lub skrypt reklamowy. To coś, czego PSI po prostu nie potrafi.
  • Lighthouse wewnątrz WebPageTest. „WebPageTest vs. Lighthouse” to fałszywa dychotomia — możesz uruchomić audyt Lighthouse z poziomu WebPageTest. Warto być precyzyjnym, co to oznacza: audyt Lighthouse to osobny, wersjonowany raport — z własnym wynikiem 0–100 i własną listą audytów — generowany w ramach szerszej sesji testowej WebPageTest, a nie scalony z natywnymi metrykami waterfall/filmstrip WebPageTest. Jak ująłem to w przewodniku Ahrefs, większość narzędzi do szybkości używa Lighthouse pod maską: „The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (tłumaczenie) „Wyjątkiem jest WebPageTest, chociaż można również uruchamiać testy Lighthouse za jego pomocą.” (Ahrefs — Core Web Vitals)
  • Opportunities & Experiments. Funkcja porównywania zmian HTML przed/po bez kodowania, która pozwala porównać dwa stany strony bez dotykania produkcji — wprowadzona około 2022 roku, według ówczesnych relacji Detlefa Johnsona w Search Engine Land (ten konkretny artykuł został od tego czasu usunięty z serwisu, a ja nie mogłem niezależnie potwierdzić aktualnej nazwy ani dostępności tej funkcji na żywej sesji WebPageTest podczas tej aktualizacji — warto sprawdzić to od nowa, zanim zbudujesz wokół niej przepływ pracy pod tą nazwą).
  • API / automatyzacja i instancje prywatne. Istnieje API do testowania programowego, a ponieważ kod jest open source, możesz uruchomić własną prywatną instancję.

Używanie WebPageTest do technicznego SEO

To jest aspekt, który większość przewodników po WebPageTest pomija, i dlatego to narzędzie należy do wyposażenia technicznego SEO:

  • Testuj jako Googlebot. Możesz ustawić user agent Googlebota i obserwować, jak zachowuje się blokujący renderowanie JS — to użyteczne przybliżenie (nie idealna kopia) tego, jak renderer Google’a może doświadczać strony. Przewodnik MobileMoxie dotyczący technicznego SEO w WebPageTest dobrze ujmuje wartość SEO: “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (tłumaczenie) „Narzędzie dostarcza szczegółowych informacji o kondycji Twoich stron i pomaga analizować takie rzeczy jak żądania w obie strony, błędy zasobów, przekierowania, problemy z buforowaniem, informacje o bezpieczeństwie i nie tylko.”
  • Audytuj łańcuchy przekierowań. Waterfall ujawnia każdy przeskok przekierowania, więc rozbudowany łańcuch przekierowań (każdy to podróż w obie strony) jest widoczny zamiast ukryty.
  • Sprawdź skuteczność buforowania i CDN. Według web.dev powyżej, WebPageTest sprawdza buforowanie treści statycznych, TTFB i użycie CDN — infrastrukturę, która decyduje o tym, jak szybko boty i użytkownicy otrzymują Twoje bajty.
  • Diagnozuj problemy z renderowaniem JS. Jeśli treść pojawia się dopiero po uruchomieniu JavaScriptu, filmstrip i waterfall pokazują, kiedy (i czy) została namalowana.
  • Dowody przed/po dla interesariuszy. Filmstrip obok siebie przedstawiający obecną stronę versus proponowaną poprawkę jest znacznie bardziej przekonującym artefaktem dla klienta lub zespołu inżynierskiego niż liczba Lighthouse, która spadła o sześć punktów.

Cennik i dostęp

Bezpłatna publiczna usługa na webpagetest.org oferowała historycznie rzędu setek przebiegów testów miesięcznie, plus darmowy klucz API z dziennymi limitami. Płatny poziom WebPageTest Pro odblokowuje większy wolumen API, prywatne testy i priorytet w kolejce testów. A ponieważ całość jest open source na licencji Polyform Shield — ujęcie Catchpoint jest takie, że “the WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects” (tłumaczenie) „kod WebPageTest pozostaje swobodnie dostępny na licencji Polyform Shield, co pozwala na jego użycie w wewnętrznych lub niekonkurencyjnych projektach komercyjnych” (webpagetest.org/about) — możesz również hostować prywatną instancję samodzielnie.

Uczciwe ograniczenia

  • Krzywa uczenia się. Interfejs jest gęsty; waterfall onieśmiela, zanim stanie się użyteczny.
  • Konto potrzebne do zapisanych/prywatnych wyników. Swobodne jednorazowe testy są otwarte, ale zapisywanie i prywatne testowanie wymaga konta.
  • Diagnozuje, nie naprawia. WebPageTest pokazuje problem w najdrobniejszych szczegółach; nie poprowadzi Cię za rękę przez naprawę tak, jak próbują to robić niektóre narzędzia punktujące.
  • Zmienność pojedynczego uruchomienia. Jeden przebieg może wprowadzić w błąd. Użyj wielu przebiegów i czytaj medianę — narzędzie domyślnie to robi z jakiegoś powodu.

Uwaga o Bing

Nie ma dokumentacji Bing ani Microsoft, która pozycjonowałaby WebPageTest jako czynnik rankingowy lub rekomendację pierwszego wyboru. Bing Webmaster Tools ma własne Site Scan i zalecenia związane z szybkością, ale nic specyficznego dla WebPageTest — a Core Web Vitals pozostaje przede wszystkim konstruktem Google. (Nie myl WebPageTest z własnym bing.com/tools/speedtest Bing, które jest testem szybkości sieci, a nie narzędziem do wydajności stron.)

Gdzie to się znajduje

To członek klastra narzędzi do wydajności stron internetowych zajmujący się głęboką diagnostyką. Jego rodzeństwo ma różne zadania: Google Lighthouse to audyt laboratoryjny, który generuje wynik 0–100 (i który wiele innych narzędzi uruchamia pod maską); PageSpeed Insights pokazuje dane terenowe CrUX i laboratoryjny przebieg Lighthouse w jednym interfejsie; Chrome UX Report (CrUX) to zbiór danych terenowych od prawdziwych użytkowników, na którym Google faktycznie opiera ranking. Aby poznać metryki, które wszystkie te narzędzia mierzą, oraz progi, których używa Google, zacznij od centrum Core Web Vitals. Aby zobaczyć cały pipeline, w którym te narzędzia działają, zobacz klaster wydajności stron internetowych.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.