Analiza sieci w DevTools i jak ją czytać

Analiza ruchu sieciowego w narzędziach developerskich przestaje być tajemnicą, jeśli podejdziemy do niej systematycznie. Ten artykuł poprowadzi krok po kroku przez najważniejsze elementy zakładki DevTools, pokaże jak czytać listę żądań i wykres Waterfall, oraz wyposaży w praktyczne metody debugowania problemów związanych z wydajnością sieci. Omówione zostaną też kluczowe pojęcia takie jak nagłówki, cache czy TTFB, a także operacje na protokole HTTPS i techniki symulacji połączeń (np. throttling). Na końcu znajdziesz wskazówki dotyczące eksportu danych do HAR i analizowania łańcuchów inicjacji (inicjator).

Co pokazuje zakładka Network w DevTools

Zakładka Network to centrum informacji o każdym żądaniu HTTP/HTTPS wysyłanym przez stronę. Na pierwszy rzut oka zobaczysz listę zasobów: pliki HTML, CSS, JavaScript, obrazy, fonty, żądania XHR/Fetch i WebSockety. Kluczowe kolumny to nazwa zasobu, status HTTP, typ zasobu, rozmiar, czas oraz wspomniany wcześniej wykres Waterfall. Dzięki tym danym szybko określisz, które zasoby blokują renderowanie i skąd pochodzą opóźnienia.

Główne elementy interfejsu

Name — nazwa lub URL zasobu.
Status — kod HTTP (200, 301, 304, 404, 500, itp.).
Type — typ treści (document, script, stylesheet, xhr, font, image itp.).
Initiator — skąd pochodzi żądanie: parser HTML, skrypt, redirect lub other. Daje wskazówkę, co wywołało pobranie zasobu.
Time i Waterfall — ile trwało żądanie i jego rozbicie na fazy.
Size/Transferred — ile bajtów zostało pobranych, z uwzględnieniem kompresji.

Filtry i tryby wyświetlania

DevTools pozwala filtrować żądania według typu (XHR, JS, CSS), po nazwie lub użyć zaawansowanych filtrów (np. metoda:GET, status:4xx). Przydatne opcje to „Preserve log” (zachowanie logu między przeładowaniami) oraz możliwość czyszczenia listy. Funkcja „Disable cache” ułatwia testowanie zachowania serwera bez korzystania z lokalnego cache.

Jak czytać wykres Waterfall i czasy ładowania

Wykres Waterfall to wizualne przedstawienie sekwencji i czasu trwania poszczególnych etapów żądania. Zrozumienie jego kolorów i segmentów pozwala zidentyfikować, które fazy wymagają optymalizacji.

Rozbicie czasu żądania

Queued / Stalled — żądanie czeka na zasoby przeglądarki (np. limit równoległych połączeń) lub na procesy wewnętrzne.
DNS Lookup — czas potrzebny na rozwiązanie nazwy domeny (można go uniknąć przez ustawienia DNS lub preconnect).
Initial connection / TCP — nawiązanie połączenia TCP.
HTTPS / SSL — negocjacja TLS, handshake; może być istotna przy długich opóźnieniach.
Request sent — czas wysyłania żądania.
Waiting (TTFB) — czas do pierwszego bajtu odpowiedzi, czyli TTFB, kluczowy wskaźnik opóźnień serwera.
Content Download — pobieranie treści odpowiedzi.

Przykładowo, jeśli większość czasu spędzona jest w fazie SSL lub TCP, warto sprawdzić konfigurację serwera, CDN lub ustawić keep-alive. Gdy dominującym elementem jest TTFB, problemy najczęściej leżą po stronie backendu (wolne zapytania do bazy, blokady, nieoptymalne generowanie HTML).

Interpretacja opóźnień

Nie każde długie żądanie wymaga tej samej naprawy. Kilka typowych sytuacji:

Wysokie DNS Lookup — rozważ użycie CDN, DNS prefetch lub konsolidacji domen.
Duże wartości Stalled — sprawdź liczbę jednoczesnych połączeń; przeglądarki ograniczają ją per-host.
Długi Request / TTFB — profiluj backend, cachuj dynamiczne fragmenty, użyj edge caching.
Content Download zajmuje dużo czasu — zmniejsz rozmiary plików (kompresja, optymalizacja obrazów, kodu), włącz gzip lub Brotli.

Analiza żądań — nagłówki, odpowiedzi i zasoby

Szczegółowy wgląd w nagłówki HTTP pozwala wykryć błędy konfiguracji i zrozumieć strategię cachowania. Sekcja Headers to pierwsze miejsce, gdzie spojrzysz przy analizie problemów.

Co sprawdzać w nagłówkach

Cache-Control, Expires, Last-Modified, ETag — reguły cachowania wpływają na liczbę żądań i ich koszt. Polecenie „Disable cache” pomaga zweryfikować ich działanie.
Content-Encoding — czy odpowiedź jest kompresowana (gzip, br)? Jeśli nie, warto włączyć kompresję na serwerze.
Content-Type — upewnij się, że MIME type jest prawidłowy (zapobiega błędom renderowania i problemom bezpieczeństwa).
Set-Cookie — oraz polityka SameSite, kiedy praca z ciasteczkami wpływa na żądania cross-site.
Vary — wpływa na cache pośredniczący (CDN, proxy).

Statusy i kody błędów

Kody HTTP informują o naturze problemu. 2xx to sukcesy, 3xx — przekierowania (warto śledzić niepotrzebne łańcuchy redirectów), 4xx to błędy klienta (np. brak zasobu), 5xx — błędy serwera wymagające naprawy po stronie backendu. Oprócz tego 304 (Not Modified) oznacza, że przeglądarka użyła cache warunkowego, co może być pożądane.

Narzędzia i techniki — filtrowanie, throttling, HAR, service worker

DevTools oferuje funkcje, które pozwalają symulować warunki i zbierać dane do późniejszej analizy. Znajomość tych narzędzi przyspiesza diagnozowanie problemów i komunikację z zespołem backendowym.

Symulacja i debugowanie

Network throttling — symuluj wolne 3G, 4G czy niestabilne połączenia, aby zobaczyć jak strona zachowuje się przy złych warunkach.
CPU throttling — łącz testy sieciowe z obciążeniem CPU, by odtworzyć warunki na urządzeniach mobilnych.
Request blocking — blokuj konkretne zasoby, by ocenić zależności i wpływ zewnętrznych skryptów.
Disable cache — przy testach zachowania bez cache, szczególnie przy debugowaniu plików statycznych.

HAR i eksport danych

Plik HAR (HTTP Archive) zawiera zapis wszystkich żądań i odpowiedzi, łącznie z nagłówkami i czasami. Eksport HAR jest przydatny, gdy trzeba przesłać pełne ślady do zespołu backendu lub analityków. Pamiętaj, by oczyścić wrażliwe dane (tokeny, ciasteczka) przed udostępnieniem.

Service Workers, WebSockety i Fetch/XHR

DevTools umożliwia monitorowanie żądań XHR/Fetch oraz połączeń WebSocket. Service Worker może interceptować żądania i zwracać zasoby z cache — w DevTools widać, czy odpowiedź pochodzi ze sw-cache (Service Worker) czy z sieci.

Praktyczne wskazówki i scenariusze debugowania

Poniżej znajdują się konkretne kroki, które możesz wykonać, gdy strona ładuje się wolno lub zachowuje się niepoprawnie.

1. Znajdź najwolniejsze żądania

Sortuj po kolumnie Time lub kliknij na Waterfall, by zobaczyć długie paski.
Sprawdź czy długi czas to DNS/SSL/TTFB czy Content Download — to wskaże warstwę do optymalizacji.

2. Zidentyfikuj blokujące zasoby

Pliki JS i CSS często blokują renderowanie. Szukaj zasobów ładowanych w head bez atrybutów asynchronicznych lub defer. Rozważ dzielenie kodu (code splitting) i ładowanie asynchroniczne zasobów niekrytycznych.

3. Sprawdź cache i nagłówki

Upewnij się, że statyczne zasoby (obrazy, skrypty) mają długie reguły cache, a dynamiczne treści są cachowane warunkowo lub na poziomie edge (CDN).
Jeśli widzisz 304 często, sprawdź, czy to oczekiwane zachowanie i czy nie lepiej wysyłać zasoby z długim expires.

4. Analiza inicjatorów i łańcuchów zależności

Klikając wartość Initiator możesz zobaczyć, który skrypt wywołał żądanie. To pomaga wyłapać zewnętrzne biblioteki, które wywołują wiele dodatkowych zasobów, lub skrypty ładujące elementy dynamicznie.

5. Problemy z fontami i obrazami

Fonty potrafią blokować renderowanie tekstu. Używaj font-display:swap i optymalizuj rozmiar plików. Obrazy kompresuj i stosuj formaty nowej generacji (WebP, AVIF). Lazy-loading obrazów zmniejszy początkowy transfer.

6. Przyspiesz połączenia

Użyj CDN dla zasobów globalnych.
Włącz HTTP/2 lub HTTP/3 — zmniejszą one koszty wielu małych żądań.
Preconnect i DNS-prefetch pomagają skrócić czas nawiązywania połączeń do zewnętrznych domen.

7. Łączenie z narzędziami Performance i Lighthouse

DevTools Network warto używać równolegle z zakładką Performance, by skorelować żądania z CPU i renderingiem. Lighthouse da gotowe rekomendacje dotyczące optymalizacji zasobów i cachowania.

Przykładowe checklisty do codziennej analizy

Krótka lista kontrolna, którą możesz przejść podczas audytu strony:

Wyeksportuj HAR i przejrzyj największe payloady.
Sprawdź, które żądania mają długi TTFB — profiluj backend.
Przeanalizuj nagłówki cache — czy są sensownie ustawione?
Zidentyfikuj zasoby blokujące renderowanie — JS i CSS.
Symuluj słabe łącze przy pomocy throttlingu.
Usuń zbędne lub duplikowane żądania (np. fonty z różnych źródeł).
Upewnij się, że wszystkie zasoby statyczne są skompresowane (gzip/brotli).

Praca z zakładką Network w DevTools to umiejętność, którą warto ćwiczyć regularnie. Dzięki systematycznemu podejściu i opisanym powyżej technikom szybko zauważysz, które elementy aplikacji najbardziej obciążają połączenie i jak je zoptymalizować. Pamiętaj o eksportowaniu HAR i o weryfikacji inicjatorów, bo to często one wskażą główny punkt zapalny w złożonych aplikacjach. Powodzenia w analizie i optymalizacji!