Jak analizować pliki HAR w praktyce

Plik HAR to „czarna skrzynka” ładowania strony: pełna historia żądań sieciowych, którą da się odczytać jak mapę drogową błędów i wąskich gardeł. Dzięki niemu analityk SEO może przełożyć surowe czasy i nagłówki HTTP na konkretne zadania: odchudzenie zasobów, naprawę przekierowań, dyscyplinę 3rd party i domknięcie budżetów wydajności. Poniżej znajdziesz praktyczny przewodnik, jak czytać waterfall, diagnozować TTFB i przekuć wnioski w przewagę w SEO technicznym.

Dlaczego plik HAR jest kluczowy w SEO technicznym i jak go pozyskać

Co właściwie zapisuje HAR i dlaczego to ma znaczenie

HAR (HTTP Archive) przechowuje chronologiczny rejestr zdarzeń sieciowych: każdą próbę połączenia, czas DNS, TLS, transferu, odpowiedzi, rozmiary, a także nagłówki żądań i odpowiedzi. Z perspektywy SEO technicznego to bezcenne, bo daje wgląd w realne blokady render-blocking, opóźnienia serwera, łańcuchy przekierowań, polisy cache oraz wpływ skryptów zewnętrznych. Analiza HAR pozwala ułożyć backlog optymalizacji nie na intuicję, lecz na twarde dane: które zasoby opóźniają wyrenderowanie „above the fold”, które hosty hamują pierwszą treść, gdzie trwonimy budżet transferu i ile żądań zjadają integracje marketingowe.

To także sposób na weryfikację tego, co realnie widzi Googlebot. Choć robot nie odpala wszystkich skryptów tak jak użytkownik, obsługuje HTTP/2 i reaguje na sygnały sieciowe, więc przejrzysty profil żądań i stabilne czasy TTFB skracają czas do zindeksowania i redukują ryzyko problemów z renderowaniem zawartości opartej na JS. HAR jest więc łącznikiem między Page Experience a crawl budget: jeśli serwer wolno odpowiada, a 3rd party rozpycha oś czasu, robot marnuje swój przydział.

Jak nagrać HAR w Chrome, Firefox, Edge i Safari

Najprościej: włącz DevTools, zakładka Network, zaznacz „Preserve log”, ewentualnie „Disable cache”, rozpocznij nagrywanie (czerwona kropka), odśwież stronę, odczekaj aż wszystko się załaduje, kliknij prawym w obszarze tabeli i wybierz „Save all as HAR with content”. W Firefoxie i Edge działa to podobnie. W Safari trzeba włączyć narzędzia deweloperskie w preferencjach, a następnie skorzystać z Network i eksportu. Jeśli testujesz warunki mobilne, włącz emulację urządzenia i przepustowości (np. 4G/Slow 4G) oraz ewentualne opóźnienie RTT – to zbliży sesję do realnych doświadczeń użytkownika.

Warto zapisać kilka wariantów: „cold” (z wyłączonym cache), „warm” (po jednym odświeżeniu, by przetestować nagłówki pamięci), oraz wizyty z i bez zgód na 3rd party – by zobaczyć, jak CMP wpływa na ścieżkę żądań. Jeżeli strona to SPA, nagraj także przejścia kluczowych widoków oraz interakcje, które dociągają dane (XHR/Fetch), bo to one kształtują faktyczne doświadczenie użytkownika po pierwszym renderze.

Higiena danych: bezpieczeństwo, RODO i poufność

HAR zawiera nagłówki, cookie i query stringi; to często informacje wrażliwe. Przed udostępnieniem w zespole lub vendorowi: usuń tokeny, parametry zawierające identyfikatory użytkowników, a w razie potrzeby „redactuj” całe nagłówki Authorization. Wiele narzędzi (np. WebPageTest, Charles, Fiddler) oferuje filtry maskujące. Upewnij się też, że nagrywasz środowisko zgodne z polityką prywatności – najlepiej staging z danymi testowymi lub produkcję na neutralnym koncie.

Kiedy i co nagrywać, by wnioski były wiarygodne

Ustal scenariusz: wejście na adres kanoniczny (bez i z www, http→https), strona listowania, produkt, koszyk, checkout oraz krytyczne landing page’e z SEO. Dodaj kroki z przekierowaniami i parametrami kampanii. Nagrywaj o różnych porach, bo wydajność może falować wraz z ruchem. Zadbaj o spójne warunki sieci (to samo „throttling”), identyczne rozszerzenia przeglądarki (najlepiej profil „goły”) i czystszy start (incognito). Tylko wtedy porównania HAR między buildami mają sens.

Jak czytać strukturę HAR i przekładać ją na priorytety SEO

Najważniejsze pola: entries, timings, pageref i nagłówki

W pliku najistotniejsza jest lista „entries”. Każdy wpis to pojedyncze żądanie z polami: url, method, status, timings (blocked, dns, connect, ssl, send, wait, receive), size (encoded/decoded), cache, response i request headers, a także „pageref”, który wiąże żądania z konkretną „stroną” (przydatne dla SPA lub kilku nawigacji). Te mikropola pozwalają rozebrać na czynniki pierwsze każdy etap: czy blokuje nas kolejka gniazd, czy DNS jest wolny, czy TLS robi powolny handshake, czy serwer każe czekać (wait), czy transfer jest ciężki (receive). W SEO – to atomowa analiza problemów, które zwykle przemykają między metrykami syntetycznymi.

Przykładowe sygnały alarmowe: duży udział „blocked” (limit równoległych połączeń albo zbyt wiele hostów), skoki „dns” (brak warmingu w resolverze lub słaby dostawca), wysoki „ssl” (stary TLS, brak session resumption), przerośnięty „wait” (gorące TTFB), czy rozrastające się „receive” (brak kompresji i minifikacji, duże obrazy). Każde z nich to inny rodzaj pracy: infrastruktura, backend, CDN, front‑end, policy 3rd party.

Metryki, które mają znaczenie dla indeksacji i doświadczeń

Horyzontalnie spina wszystko LCP – największa treść widoczna w oknie, skorelowana z wydajnością backendu, priorytetem krytycznych zasobów oraz budową DOM. HAR nie podaje LCP wprost, ale pozwala znaleźć ścieżkę do LCP: CSS krytyczny, czcionki, pierwsze obrazy i JS, który modyfikuje hero. Z kolei TTFB wynika głównie z „wait” i zdradza kłopoty z generowaniem HTMLu albo z konfiguracją CDN (cache miss, cold origin). Wpływ na crawling? Długi TTFB spowalnia tempo pobierania, co może ograniczać liczbę stron odwiedzanych przez Googlebota w danym oknie czasu.

Na poziomie nagłówków oceniasz politykę pamięci: Cache-Control, Expires, ETag, Surrogate‑Control, Age. Stąd wyczytasz, czy grafika nie jest przypadkiem bez pamięci podręcznej, czy zasoby statyczne korzystają z długich TTL i wersjonowania przez fingerprint w nazwie, a HTML ma krótką lub zerową pamięć. To fundament dobrych trafień w cache oraz niższego TTFB na kolejnych użytkownikach. Sprawdź też Content-Encoding (gzip/br) – brak lub złe ustawienie to niewykorzystana kompresja.

Protokół, połączenia i priorytetyzacja

HAR zdradza, czy używasz HTTP/2 lub HTTP/3, jak wygląda reuse połączeń, a pośrednio – priorytetyzacja strumieni. Rozdrobnienie na zbyt wiele hostów (sharding) zabija korzyści multiplexingu; zamiast jednego gniazda dla kilkudziesięciu zasobów przeglądarka tworzy wiele połączeń i płaci koszt TLS/DNS za każde. Zwróć uwagę na wczesne zasoby: CSS, czcionki i JS inicjalny. Jeśli lądują późno w waterfallu, sprawdź, czy nie można zasygnalizować ich pierwszeństwa przez hints: preload dla krytycznych arkuszy/assetów oraz preconnect do hostów CDN i 3rd party. Dziś dochodzi także 103 Early Hints i Priority Hints – HAR pomoże zweryfikować, czy serwer wysyła sygnały, a przeglądarka faktycznie korzysta.

Zasoby krytyczne i blokady renderowania

W SEO technicznym liczy się, jak szybko użytkownik i robot widzą stabilną, użyteczną treść. CSS zawsze ma wysoką rangę; jeśli jest łączony w jeden plik o 300 kB z tysiącem reguł, rozważ krytyczny fragment inline i resztę ładowaną asynchronicznie. Czcionki webowe potrafią zdominować oś czasu: ustaw font-display: swap, zoptymalizuj subsety i formaty (WOFF2), a w HAR sprawdź, kiedy pierwsza czcionka zaczyna się pobierać względem CSS. Skrypty inicjalne odchudź, rozbijając je na moduły i deferując wszystko, co nie jest potrzebne do pierwszej treści. Jeśli widzisz w HAR powtarzające się łańcuchy zależności (JS wymaga innego JS, który dopiero inicjuje CSS), to klasyczny antywzorzec opóźniający LCP.

Analiza krok po kroku: od waterfall do planu optymalizacji

Odczytywanie osi czasu i detekcja „wąskich gardeł”

Zacznij od pierwszej linii HTML. Sprawdź opóźnienia DNS/connect/SSL, potem długość „wait” – to wgląd w backend i CDN. Przejdź do zasobów, które startują wcześnie, ale kończą późno – to często ciężkie obrazy lub skrypty 3rd party o niskim priorytecie sieciowym. „Dziury” w osi czasu mogą wskazywać na limit połączeń albo blokady w głównym wątku (których sam HAR nie pokaże, ale korelację czasową z długo ładującym się JS już tak). Ułóż listę „Top blockers”: HTML, CSS, czcionki, hero image, JS inicjalny i każdy zasób wpływający na above-the-fold. Dobrze jest oznaczyć kolorami wnioski: infrastruktura (DNS, TLS, TTFB), sieć (transfer, kompresja), front‑end (krytyczne zasoby), 3rd party.

Spójrz też na chwilę gotowości do interakcji – HAR pokaże, kiedy dociera ostatni plik krytyczny. Jeśli od tego momentu coś jeszcze długo się ściąga (np. piksel marketingowy), ale nie blokuje renderu, nie priorytetyzuj tego ponad elementy wpływające na pierwsze malowanie i layout. Analiza ma być pragmatyczna: porządkuj według wpływu na doświadczenie i indeksację, a nie według czystej liczby żądań.

Diagnozowanie backendu i warstwy CDN

Wysoki „wait” przy HTML zwykle znaczy: wolne generowanie szablonu, zapytania do bazy, zewnętrzne API lub brak trafień w CDN. Z HAR wyczytasz, czy odpowiedzi mają Age>0 (trafienie), jak wygląda Cache-Control dla HTML (krótkie, ale nie 0 w systemach headless z pełnym SSR), czy stosujesz stale lub warunkowe odświeżanie (ETag/Last-Modified). Jeżeli TTFB jest losowo wysoki, porównaj różne regiony i godziny – może to problem warmingu instancji lub spike ruchu. Dobrym testem jest kontrola 103 Early Hints oraz Server-Timing: jeśli serwer raportuje czasy DB/templating, skoreluj je z „wait” w HAR, by wskazać konkretną warstwę do optymalizacji.

Po stronie TLS upewnij się, że obsługujesz nowoczesne szyfry i włączone masz session resumption; to skróci „ssl” przy kolejnych połączeniach, co w modelu wielu hostów potrafi dać wymierny efekt. DNS? Zbadaj, czy hosty 3rd party nie psują czasu – wolny resolver po drugiej stronie to realny koszt. Możesz ograniczyć liczbę domen zewnętrznych lub użyć prefetchu DNS, gdy masz na to podstawy.

Eliminowanie blokad renderowania i priorytety zasobów

Prześledź drogę do stylów: jeśli główny CSS jest „monolitem”, zidentyfikuj krytyczne reguły dla powyżej zgięcia ekranu i zainlinuj je w HTML, resztę doładuj asynchronicznie. Sprawdź, czy czcionki pobierają się zaraz po CSS; jeśli nie, dołóż resource hints i preloading. Upewnij się, że obrazy hero korzystają z formatów nowej generacji (AVIF/WebP), mają właściwe wymiary i hinty wysokości/szerokości, by uniknąć layout shift.

Skrypty: wszystko, co nie jest potrzebne do pierwszej treści, deferuj lub ładuj po zdarzeniu DOMContentLoaded. Dla 3rd party inwestuj w menedżery ładowania, które respektują priorytety i potrafią odroczyć inicjalizację do czasu interakcji. Gdy HAR pokazuje łańcuch: piksel → loader → kolejne skrypty, oceń realny zwrot z tych integracji. W SEO liczy się nie tylko obecność, ale też koszt utrzymania widoczności i doświadczeń.

Resource hints, Early Hints i dopasowanie do przeglądarek

Dwa szybkie dźwignie to preconnect do hostów o wysokim wpływie oraz preload dla najważniejszych zasobów krytycznych. W HAR zobaczysz, że po ich wdrożeniu zasoby startują wcześniej, a „blocked/dns/connect/ssl” skurczą się przed pierwszym malowaniem. Sprawdź również 103 Early Hints – jeśli serwer wysyła linki rel=preload w wczesnej odpowiedzi, przeglądarka może ruszyć po zasoby, nim backend złoży HTML. Oceń też Priority Hints (importance=high/low), które pomagają kierować przepływem w wielostrumieniowych protokołach. Nie przesadzaj jednak: zbyt wiele preloadingów może zagłodzić inne krytyczne pliki lub przeciążyć sieć użytkownika.

Automatyzacja, porównania i praca zespołowa na bazie HAR

Jak porównywać HAR między buildami i środowiskami

Wersjonuj HAR wraz z kodem. Z każdym releasem porównuj: liczbę żądań, łączny transfer, czas do zakończenia pobierania HTML/CSS/JS, rozmiary i statusy. Zwracaj uwagę na regresje: nowe hosty 3rd party, inne polityki cache, wzrost TTFB, pojawiające się łańcuchy przekierowań. Ustal budżety wydajności: maksymalna liczba żądań „krytycznych”, maksymalny rozmiar CSS/JS w ścieżce do wyrenderowania, limit łącznego transferu na 4G. Każde przekroczenie powinno zatrzymać wdrożenie lub przynajmniej wymusić akceptację na PR.

Dobrą praktyką jest też porównanie „zimne vs ciepłe” ładowanie. Jeżeli różnica jest niewielka, to znak, że polityka pamięci nie działa; jeśli ogromna – upewnij się, że nie polegasz zbyt mocno na cache’u przeglądarki, bo nowi użytkownicy i roboty go nie mają. Balans jest kluczem.

Narzędzia i pipeline: od CLI po CI/CD

Możesz zbierać HAR automatycznie przez Puppeteer/Playwright (przechwyt requestów i zapis do formatu HAR) albo z narzędzi syntetycznych (WebPageTest, Sitespeed.io). Pipeline w CI/CD: uruchom testy dla kluczowych URL-i, zapisuj HAR, parsuj i generuj raporty porównawcze. Do prostych analiz wystarczy parser JSON i reguły: sumy transferów per typ (document, stylesheet, script, image, font), czasy „wait” dla HTML, wykrywanie braku Content-Encoding, braków Cache-Control na assetach, zbyt długich łańcuchów przekierowań.

Raport powinien produkować checklistę akcji: „Dodaj gzip/br na host X”, „Skróć TTFB na / z 900 ms do 400 ms”, „Wytnij 3rd party Y albo załaduj po interakcji”, „Podziel CSS na krytyczny i resztę”. HAR jest tu surowcem, a wynik – gotową decyzją produktową.

Współpraca: jak dzielić się HAR bez chaosu

Ustal standard: nazewnictwo plików (data, środowisko, scenariusz, urządzenie, sieć), maskowanie wrażliwych danych i wspólny szablon wniosków. Załączaj HAR do ticketów w JIRA wraz ze screenshotem osi czasu i listą top bottlenecków. Jeśli korzystasz z analityki RUM, skoreluj dane syntetyczne z realnymi: czy użytkownicy faktycznie widzą poprawę po zmianach, które HAR sugerował? Jeśli nie, zbadaj różnice w urządzeniach/sieci i kalibruj throttle w testach.

Najczęstsze antywzorce i jak ich unikać

Typowe potknięcia: eksport HAR z włączonymi rozszerzeniami (fałszywe żądania), brak emulacji przepustowości i RTT (nierealne czasy), łączenie wszystkiego w jeden plik „krytyczny” (monolity), bezrefleksyjne dodawanie resource hints oraz mnożenie hostów bez potrzeby. Nie zrzucaj wszystkiego na CDN – jeśli HTML generuje się 1,2 s, żaden CDN nie ukryje tego na pierwszej wizycie. Z drugiej strony, ignorowanie polityki cache to marnowanie tanich zwycięstw. Mierz, wdrażaj małymi krokami, waliduj HAR-em i wracaj do backlogu.

Na koniec pamiętaj, że HAR to wycinek rzeczywistości – syntetyczny i kontrolowany. Pełnię obrazu daje połączenie z danymi RUM, logami serwera i raportami GSC. Jednak to właśnie HAR najczęściej wskaże „pierwsze 5 rzeczy”, które realnie skrócą drogę do treści i poprawią sygnały Page Experience. W SEO technicznym to często różnica między stroną szybką i przewidywalną a taką, którą robot odwiedza rzadziej i z mniejszym apetytem.