WebPageTest – jak przetestować szybkość strony i czytać wykres waterfall

WebPageTest to narzędzie, które ładuje Twoją stronę w prawdziwej przeglądarce (Chrome, Edge lub Firefox) z wybranej lokalizacji i na symulowanym łączu, a potem pokazuje dokładnie, co działo się podczas ładowania: kolejność i czas pobierania każdego pliku na wykresie waterfall, klatki obrazu co 100 ms oraz metryki takie jak TTFB, LCP i CLS. Dzięki temu nie tylko wiesz, że strona jest wolna, ale widzisz, który zasób ją spowalnia.

Narzędzie działa pod adresem webpagetest.org i od 2020 r. należy do firmy Catchpoint (od grudnia 2025 r. części LogicMonitor). Poniżej pokazuję, jak ustawić sensowny test, jak czytać wyniki i jakie poprawki najczęściej wynikają z analizy.

Kiedy WebPageTest, a kiedy PageSpeed Insights

Oba narzędzia się uzupełniają, ale odpowiadają na różne pytania.

PageSpeed Insights mówi, czy masz problem z Core Web Vitals u realnych użytkowników. WebPageTest pozwala znaleźć przyczynę i sprawdzić, czy poprawka zadziałała. Szerszą listę testów, które warto zrobić na stronie (nie tylko szybkości), znajdziesz w artykule test strony internetowej — checklista.

Jak ustawić test w WebPageTest krok po kroku

1. Wejdź na webpagetest.org i zaloguj się (darmowe konto daje miesięczny limit testów).
2. Wpisz pełny adres testowanej podstrony. Testuj nie tylko stronę główną, ale też typowe podstrony: wpis blogowy, kartę produktu, kategorię.
3. Wybierz lokalizację testu możliwie blisko Twoich użytkowników — dla polskiej strony najlepiej serwer w Europie Środkowej.
4. Wybierz przeglądarkę i profil łącza. Do oceny doświadczenia mobilnego użyj emulacji telefonu i profilu 4G; do porównań między wersjami strony trzymaj się zawsze tego samego profilu.
5. W ustawieniach zaawansowanych ustaw liczbę przebiegów (Number of Tests to Run) na co najmniej 3. Pojedynczy test bywa przypadkowy; WebPageTest wskaże przebieg medianowy.
6. Zostaw włączony Repeat View (First View and Repeat View), żeby zobaczyć, jak strona ładuje się z cache przeglądarki.
7. Uruchom test i poczekaj — przy kilku przebiegach i wolnym łączu trwa to od kilkudziesięciu sekund do kilku minut.

Przydatne opcje zaawansowane: blokowanie wybranych domen (szybki sposób, żeby sprawdzić, ile kosztuje np. czat albo piksel reklamowy), własne nagłówki HTTP, uruchomienie dodatkowego audytu Lighthouse oraz skrypt, który np. loguje się na konto przed właściwym pomiarem.

Wskazówka: Jeśli korzystasz z cache strony lub CDN, uruchom test dwukrotnie. Pierwsze wejście może trafić na „zimny” cache serwera i pokazać zawyżony TTFB, który nie odpowiada doświadczeniu większości użytkowników.

Najważniejsze metryki w podsumowaniu wyników

Na górze raportu zobaczysz tabelę metryk dla First View i Repeat View. Najważniejsze z nich:

Dla porównania z progami Google: dobry LCP to do 2,5 s, dobry CLS do 0,1. TBT jest laboratoryjnym przybliżeniem responsywności — w danych od użytkowników Google mierzy ją wskaźnikiem INP (dobry wynik do 200 ms).

Jak czytać wykres waterfall

Waterfall to serce WebPageTest. Każdy wiersz to jeden zasób (HTML, CSS, JS, obraz, font), a poziomy pasek pokazuje, kiedy i jak długo był pobierany. Pasek dzieli się na kolorowe fazy:

• DNS — rozwiązywanie nazwy domeny,
• connect — nawiązanie połączenia TCP,
• SSL — negocjacja TLS,
• wait (TTFB) — oczekiwanie na pierwszy bajt odpowiedzi serwera,
• content download — pobieranie treści.

Pionowe linie oznaczają momenty takie jak Start Render, LCP czy zdarzenie onload. Legenda kolorów jest nad wykresem — warto ją mieć przed oczami przy pierwszych analizach.

Na co patrzeć po kolei:

1. Pierwszy wiersz (dokument HTML). Jeśli faza oczekiwania jest długa, problem leży w serwerze: brak cache strony, wolne zapytania do bazy, słaby hosting, dużo wtyczek. Zwróć uwagę na przekierowania na początku (np. http → https → www) — każde to dodatkowy obieg.
2. Zasoby przed linią Start Render. Wszystko, co jest pobierane przed pierwszym renderowaniem i ma ikonę blokowania, opóźnia wyświetlenie strony. Typowi winowajcy to wiele plików CSS, skrypty JS w <head> bez defer oraz fonty z zewnętrznych serwerów.
3. Obraz LCP. Znajdź wiersz z obrazem, który jest elementem LCP. Jeśli zaczyna się pobierać późno — np. dopiero po wykonaniu JavaScriptu lub z leniwym ładowaniem — to łatwa poprawka.
4. Nowe połączenia do obcych domen. Każda nowa domena to DNS + connect + SSL. Dziesięć domen reklamowych i analitycznych potrafi dodać sekundy, szczególnie na łączu mobilnym.
5. Czerwone wiersze. Błędy 404 i 5xx to pobrania, które nic nie dają, a zajmują czas.

Widok Connection View pokazuje te same dane pogrupowane według połączeń, a zakładka z wykresami procesora (CPU) — jak długo przeglądarka była zajęta wykonywaniem JavaScriptu.

Filmstrip i porównanie testów

W widoku Filmstrip zobaczysz klatki ekranu w odstępach np. 100 ms lub 0,5 s. To najlepszy sposób, żeby zrozumieć, co użytkownik widzi w praktyce: czy przez dwie sekundy patrzy na biały ekran, czy treść pojawia się szybko, a potem przeskakuje (CLS).

Możesz zaznaczyć kilka testów i porównać je obok siebie — klatka po klatce lub jako wideo. To idealne narzędzie do pokazania efektu optymalizacji: test „przed” i „po” na tej samej lokalizacji i tym samym łączu mówi więcej niż sam wynik punktowy. Ten sam mechanizm przyda się do porównania Twojej strony z konkurencją.

Najczęstsze problemy i co poprawić

Na podstawie tego, co pokaże waterfall, najczęściej wdraża się kilka poprawek:

• Długi TTFB: włącz cache strony (w WordPressie wtyczka cache lub cache po stronie serwera), aktualną wersję PHP z OPcache, ogranicz ciężkie wtyczki. Jeśli strona ma użytkowników z wielu krajów, dodaj CDN. W WordPressie sprawdź też, czy zadania WP-Cron nie uruchamiają się przy wizytach — więcej w tekście WP-Cron vs Cron.
• Późny LCP: nie stosuj loading="lazy" dla pierwszego dużego zdjęcia, dodaj mu fetchpriority="high", serwuj je w AVIF lub WebP i w rozmiarze dopasowanym do ekranu (srcset).
• Zasoby blokujące renderowanie: skrypty oznacz jako defer, krytyczny CSS osadź w HTML, resztę ładuj później; fonty hostuj u siebie i używaj font-display: swap.
• Wysoki TBT: usuń nieużywane skrypty i wtyczki, przenieś skrypty firm trzecich na później lub ładuj je dopiero po interakcji (np. czat po kliknięciu).
• Wysoki CLS: nadaj obrazom i ramkom width i height (lub aspect-ratio), zarezerwuj miejsce na banery i reklamy.
• Brak kompresji i cache: włącz kompresję Brotli lub gzip dla HTML, CSS i JS, ustaw długie nagłówki Cache-Control dla plików statycznych z wersjonowaną nazwą, upewnij się, że serwer obsługuje HTTP/2 lub HTTP/3.

Szybkość ma wpływ także na widoczność w Google, choć nie jest najważniejszym czynnikiem rankingowym. Przy sklepach internetowych warto połączyć te zmiany z resztą prac SEO, opisanych w poradniku SEO dla sklepu internetowego.

Inne narzędzia do pomiaru wydajności

• Lighthouse — wbudowany w narzędzia deweloperskie Chrome (F12 → zakładka Lighthouse); szybki audyt wydajności, dostępności i SEO.
• Panel Performance w Chrome DevTools — dokładny zapis pracy przeglądarki, przydatny do szukania ciężkiego JavaScriptu.
• PageSpeed Insights i raport Core Web Vitals w Search Console — dane od prawdziwych użytkowników.
• GTmetrix — raport oparty na Lighthouse z waterfallem i wyborem lokalizacji (część funkcji płatna).
• Pingdom Website Speed Test — prosty test z waterfallem, plus płatny monitoring dostępności.

Google Analytics 4 nie ma wbudowanych raportów czasu ładowania stron, jakie znano z Universal Analytics — do stałego monitoringu wydajności u użytkowników lepiej nadają się dane CrUX, Search Console albo narzędzia RUM (Real User Monitoring).

Jak wpleść WebPageTest w regularną pracę nad stroną

Zapisz linki do testów kluczowych podstron jako punkt odniesienia. Po każdej większej zmianie — nowym motywie, wtyczce, skrypcie marketingowym — powtórz test z tymi samymi ustawieniami i porównaj filmstripy. Raz w miesiącu zestaw te wyniki z raportem Core Web Vitals w Search Console. Jeśli dane laboratoryjne się poprawiają, a dane od użytkowników nie, szukaj problemu w warunkach, których test nie odwzorowuje: wolniejszych telefonach, zgodach cookies i skryptach ładowanych dopiero po interakcji.