Analiza har files pod kątem SEO

Plik z rejestrem żądań sieciowych bywa niedoceniany w pracy SEO, a potrafi ujawnić prawdziwą mapę przeszkód między robotem, przeglądarką i serwerem. Analiza HAR pozwala prześledzić każdy bajt oraz moment, w którym strona zwalnia, blokuje renderowanie albo traci zasoby przez błędną konfigurację. To narzędzie łączy perspektywę inżynierską z potrzebami widoczności organicznej: od indeksacji i renderowania po stabilność metryk, konwersje oraz skalowalność wdrożeń.

Podstawy: co wnosi analiza HAR do SEO technicznego

Jak czytać strukturę HAR i mapować ją na problemy SEO

Plik HAR (HTTP Archive) to eksport przebiegu komunikacji sieciowej: lista żądań i odpowiedzi z czasami oraz nagłówkami. Każdy wpis zawiera m.in. adres, status, typ zasobu, rozmiary i rozbicie na etapy: queueing, dns, connect, ssl, send, wait, receive. W SEO technicznym przekładamy to na pytania o indeksowalność, szybkość pierwszego bajtu (TTFB), opóźnienia zasobów krytycznych i integralność łańcuchów. W HARze widać, które pliki CSS i JS mają wpływ na czas do pierwszego renderu, które zasoby są dubletami, a które nie ładują się wcale.

Warto zwracać uwagę na httpVersion (współczesne serwisy powinny działać na HTTP/2 lub HTTP/3), rozbicie czasu oczekiwania (wait) wskazujące wąskie gardła serwera, a także nagłówki determinujące cache i kompresję. To jest podstawa mapowania przyczyn problemów wydajnościowych na konsekwencje rankingowe oraz doświadczenie użytkownika i robota.

Co robot i przeglądarka widzą inaczej

Roboty nie zawsze inicjują identyczny zestaw żądań co przeglądarka użytkownika. Różnice w nagłówkach Accept, User-Agent i Accept-Language, a także brak interakcji użytkownika, potrafią zmienić kolejność i zestaw wczytanych zasobów. Dlatego warto przechwycić HAR zarówno z widokiem mobile, jak i desktop oraz z emulacją Googlebot Smartphone, aby porównać: czy te same zasoby CSS/JS są serwowane i czy nie pojawiają się błędne warianty językowe. Z HARa wyczytamy też, czy banery RODO, skrypty A/B lub tag manager spowalniają wstępny render dla robotów.

Różnice między danymi laboratoryjnymi a polowymi

HAR to zapis sesji w kontrolowanych warunkach. Polowe metryki (np. z RUM) odzwierciedlają realne sieci, urządzenia i zachowania. W praktyce łączymy HAR z polowymi metrykami jak Core Web Vitals dla hipotez: który zasób z waterfallu wpływa na LCP/INP/CLS w terenie. To pomaga podejmować decyzje o priorytetach optymalizacji, budżetach wydajnościowych i testach A/B wydajności.

Narzędzia i przeglądarki do pozyskania HAR

Plik można wyeksportować z Chrome DevTools, Firefox DevTools, Edge, WebPageTest, Puppeteer/Playwright. DevTools daje podgląd filmstripu, blokady renderowania i priorytetowania, a WebPageTest automatycznie oznacza zasoby krytyczne. W automatyzacji CI używamy skryptów, które otwierają adresy, czekają na idle network i zapisują HAR z metadanymi (np. commit SHA, gałąź, wariant testu).

Jak zebrać dobrej jakości HAR do analizy SEO

Przygotowanie środowiska pomiarowego

Rzetelny HAR zaczyna się od kontrolowanych warunków. W przeglądarce ustaw throttling (np. Fast 3G lub LTE), wyłącz cache, ustaw UA mobile, włącz filmstrip oraz logowanie nagłówków. Dla stron międzynarodowych ustaw kilka języków Accept-Language, aby wykryć niezamierzone warianty treści. Zadbaj o czyste cookies, wyłącz rozszerzenia i zamknij inne karty – unikniesz zaszumienia sesji.

• Test 1: pierwsza wizyta (zimna pamięć podręczna)
• Test 2: druga wizyta (ciepła pamięć podręczna i ew. Service Worker)
• Test 3: prywatne okno bez consentu (czy UI ładuje się inaczej)
• Test 4: UA Googlebota (sprawdzenie zasobów dostępnych robotom)

Dla SPA/MPA ustal sygnał zakończenia: np. network idle 500 ms lub pojawienie się kluczowego elementu. W przeciwnym razie HAR może uciąć istotne żądania pobierane później (lazy load, hydration).

Eksport i sanityzacja

Po przechwyceniu HAR sprawdź spójność strefy czasowej, wielkości pliku i obciętych ciągów binarnych. Usuń dane wrażliwe (tokeny autoryzacyjne, parametry PII). Jeśli automatyzujesz, haszuj URL-e z parametrami user_id lub dołącz listę kluczy do zaciemnienia. Zapisuj wersję przeglądarki, konfigurację throttlingu i UA w metadanych – bez tego porównania w czasie są obarczone błędem.

Scenariusze krytyczne dla SEO

Poza stroną główną przechwyć HAR dla stron kategorii, produktu, wyszukiwania wewnętrznego, filtrów i paginacji. To te szablony odpowiadają za większość budżetu crawl i za powtarzalne błędy: niekończące się łańcuchy przekierowań, parametry powodujące duplikację treści, niespójne canonicale. Dodaj także strony ze stanami 404/410 oraz 301/302, by zbadać, jak szybko i jak czysto domykają się przekierowania.

Kontrola wersji i porównywalność

Przechowuj HAR w repozytorium artefaktów z etykietami buildów. Analiza regresji wydajności polega na różnicowaniu waterfallu między commitami i wykrywaniu pojawienia się nowego skryptu zewnętrznego czy utraty kompresji. To zapobiega cichym degradacjom, które nie przejdą niezauważone przez kilka sprintów, a później odbijają się w metrykach ruchu organicznego.

Indeksacja i renderowanie: sygnały, które widać w HAR

Łańcuchy przekierowań i konsekwencje

W waterfallu natychmiast widać kaskady 301/302/307. Dla SEO liczy się skrócenie łańcucha do jednego kroku i spójność protokołu oraz hosta (www vs bez www). Długi łańcuch podbija TTFB, marnuje budżet crawl i bywa źródłem duplikacji. Analizuj nie tylko przekierowanie samego dokumentu, ale też zasobów osadzonych (obrazy, fonty, skrypty), bo każde 302 obrazka LCP wydłuża ścieżkę renderu.

W HAR sprawdzisz, czy canonical docelowej strony odpowiada 200, czy któryś z zasobów krytycznych zwraca 404, oraz czy parametry UTM nie generują alternatywnych wersji bez rel=canonical. Notuj hosty zewnętrzne w łańcuchach (CDN, shortener), bo brak HSTS może powodować pierwsze żądanie po HTTP, a dopiero potem podniesienie do HTTPS.

Krytyczna ścieżka renderowania

Waterfall ujawnia kolejność i priorytety zasobów CSS/JS. Zwróć uwagę na style blokujące render, ich rozmiar i czas odpowiedzi. Pliki JS bez atrybutów async/defer często stają się render-blocking, co odbija się na czasie pierwszego renderu i stabilności układu. Tam, gdzie to możliwe, dziel kod na krytyczny i niekrytyczny, a krytyczny CSS inline’uj w dokumencie, resztę ładuj asynchronicznie.

Jeśli korzystasz z preloadu, w HAR pojawią się wcześniejsze żądania zasobów LCP. W połączeniu z priorytetami sieci (priorytet H2/H3 i Priority Hints) możesz skrócić opóźnienie największego elementu. Sprawdź, czy fonty nie wstrzymują renderu tekstu oraz czy ich warianty są ograniczone do faktycznie używanych subsetów.

Dostępność zasobów dla robotów i błędy konfiguracji

Choć robots.txt nie jest częścią HAR, widać tu konsekwencje blokad: CSS lub JS opisywany w logach indeksacji jako niedostępny, w HAR może wracać 403, 404 albo timeout z innego hosta. Analizuj nagłówki CORS dla zasobów używanych przez renderowanie po stronie klienta. Błędy CORS generują błędne stany UI, których robot może nie zrenderować. Porównaj też odpowiedzi vary=User-Agent — serwowanie różnych zasobów może prowadzić do błędów w mobile-first indexing, jeśli wariant mobile jest niekompletny.

SPA, Service Worker i hydratacja

W aplikacjach SPA hydratacja oraz pobieranie danych przez API pojawiają się w HAR po wczytaniu pierwszego HTML. Jeśli te żądania są wolne, widać to jako opóźnione wyświetlenie treści, a roboty mogą przerwać renderowanie przed czasem. Sprawdź, czy SSR lub prerender są włączone. Gdy działa Service Worker, porównaj pierwszą wizytę (bez SW) i drugą (z SW) – różnice w zestawie żądań i ich czasach powiedzą, czy offline cache i strategia stale-while-revalidate faktycznie służą SEO.

Wydajność i CWV: na co patrzeć w HAR

TTFB i segmentacja czasu

Opóźnienia w wait/ttfb wynikają z wielu przyczyn: powolna aplikacja, wolne bazy danych, geograficzny dystans, brak cache na brzegu. W HAR zobaczysz, czy problem jest globalny (wszystkie zasoby z jednego hosta mają wysokie wait) czy selektywny (tylko HTML lub API). Koreluj to z obszarami kluczowymi dla LCP oraz stabilnością interakcji mierzoną INP. Długi TTFB HTML zwykle przesuwa LCP; długie TTFB API opóźnia interaktywność.

Warto sprawdzić DNS i SSL. Długi dns wskazuje problemy z rekurencyjnym resolverem lub brak prefetchu; długi ssl to sygnał do optymalizacji konfiguracji TLS, certyfikatów i sesji.

Transfer, kompresja i protokół

Rozmiar transferu i kompresja to szybkie zwycięstwa. W nagłówkach Accept-Encoding/Content-Encoding upewnij się, że tekstowe zasoby używają Brotli lub gzip. HAR pokazuje różnicę między rozmiarem nie- i skompresowanym. Analizuj też httpVersion – przejście na HTTP/2 umożliwia multiplexing, lepsze priorytetowanie oraz eliminację potrzeby concat-spritingu. Dla HTTP/3/QUIC czasy connect/ssl będą inaczej rozbite, ale cel pozostaje ten sam: minimalizacja opóźnień pierwszego bajtu i przepływu.

Redukuj bloat JS: każdy kilobajt JS to koszt parsowania i wykonywania, którego nie pokaże sam HAR, ale waterfall wskaże zbyt wiele skryptów ładujących się przed treścią. Używaj tree-shakingu, kodu warunkowego i dynamic import, aby skrócić ścieżkę do renderu treści.

Cache i walidacja warunkowa

Warstwa cache decyduje o powtarzalności doświadczenia użytkownika i robota. W nagłówkach badaj Cache-Control, ETag i Last-Modified. Przy drugiej wizycie patrz, czy odpowiedzi wracają jako 304 (not modified) i czy rozmiar transferu spada. Warto stosować immutability dla zasobów wersjonowanych (cache busting w nazwach plików) oraz krótsze TTL dla HTML/API z walidacją warunkową. Strategia stale-while-revalidate skraca opóźnienia, ale w HAR zobaczysz tylko pierwsze i drugie pobranie – pełną korzyść zweryfikujesz w danych polowych.

Jeśli używasz CDN, porównaj regiony i hosty. Rozjazd w TTFB między CDN a origin wskaże błędy w hit ratio, brak edge side includes lub niekorzystne reguły cache.

Third-party i priorytety zasobów

Zewnętrzne skrypty (analityka, reklamowe, widgety) często dominują czas i wątki. W HAR złapiesz ich opóźnienia, błędy DNS i łańcuchy przekierowań. Dodaj resource hints: preconnect do krytycznych domen, preload do zasobów LCP i prefetch dla nawigacji następczych. Kontroluj, by third-party nie stały się blokujące; w miarę możliwości ładuj je po interakcji lub z niższym priorytetem. Korzystaj z Subresource Integrity i ograniczaj zbędne wstawki z tag managera – każda eksperymentalna etykieta to kolejne żądanie.

Praktyka: checklisty i decyzje optymalizacyjne z HAR

Szybkie audyty krok po kroku

• Sprawdź główne czasy: dns, connect, ssl, TTFB, receive dla HTML, CSS, JS i obrazów LCP.
• Wypisz łańcuchy przekierowań i usuń pośrednie kroki.
• Identyfikuj zasoby blokujące: CSS bez inliningu krytycznych stylów, JS bez async/defer generujący render-blocking.
• Zweryfikuj kompresję: wymuś Brotli dla tekstu na wspieranych przeglądarkach.
• Potwierdź protokół: włącz HTTP/2/HTTP/3 i sprawdź priorytety.
• Ustal politykę cache: popraw Cache-Control, ETag, stale-while-revalidate.
• Dodaj hinty: preconnect, preload zasobu LCP, prefetch dla następnej strony.
• Usuń dublujące się żądania i nadmiarowe warianty obrazów.
• Zweryfikuj dostępność zasobów dla Googlebotu (CORS, statusy, hosty).
• Porównaj pierwszą i drugą wizytę, aby ocenić wpływ SW i cache.

Obrazy i fonty – typowe pułapki

W HAR rozpoznasz, które obrazy ładują się przed tekstem, czy ich rozmiary są nadmierne i czy CDN serwuje właściwe formaty (WebP/AVIF). Dopilnuj lazy-loadu poza viewportem i wstrzymaj obrazki w sliderach na starcie. Fonty powinny być subsetowane i cachowane długo z wersjonowaniem. Jeśli font FOUT/FOIT psuje doświadczenie, rozważ font-display: swap, ale z preloadingiem najważniejszych krojów.

API i mikroserwisy

W aplikacjach rozproszonych HAR często ujawnia rozjazd czasów między usługami. Wysoki wait dla jednego hosta potrafi uziemić hydratację. Wprowadzaj cachowanie odpowiedzi API dla treści statycznych, batchuj żądania gdzie możliwe, a w UI renderuj szkielety i fallbacki, które są indeksowane i nie mylą robotów. Stosuj separację hostów tylko wtedy, gdy faktycznie poprawia to wydajność i kontrolę cache.

Bezpieczeństwo a wydajność

Migracje do HTTPS, HSTS preload, poprawne certyfikaty i współczesne pakiety szyfrów wpływają na ssl time. W HAR zauważysz mieszane treści (http w https), które blokują render i obniżają wiarygodność. Zabezpieczenia CSP i SRI powinny równoważyć bezpieczeństwo z wydajnością – błędne polityki powodują błędy pobrań widoczne w waterfallu.

Automatyzacja, budżety i raportowanie z HAR

Budżety wydajnościowe i progi alertów

Wprowadź budżety: maksymalny rozmiar JS na pierwszą wizytę, limit liczby żądań przed interaktywnością, maksymalny TTFB dla HTML, liczba przekierowań, minimalna stopa kompresji dla CSS/JS. Z HAR wyliczysz je deterministycznie i zautomatyzujesz alerty w CI. Gdy budżet zostanie przekroczony, pipeline oznacza build i wymaga akceptacji technicznej.

Integracja z CI/CD i testy regresji

Puppeteer/Playwright mogą uruchamiać scenariusze i eksportować HAR dla kluczowych adresów po każdym buildzie. Artefakty porównuj narzędziem diff: wykryjesz nowe third-party, utratę kompresji, zmianę protokołu, wzrost rozmiaru obrazów. Raport z agregacją per host pokaże, czy winny jest origin, CDN czy zewnętrzny dostawca.

Łączenie HAR z metrykami CWV i biznesem

Choć HAR nie mierzy bezpośrednio CWV, jest perfekcyjny do identyfikacji przyczyn. Mapuj zasób LCP (zdjęcie, blok hero) na jego czasy w HAR i patrz, jak zmiany w cache, preloadzie, protokole i kompresji przesuwają LCP. Dla interakcji łącz kolejność i wagę JS z polowymi danymi INP. Twórz dashboardy, gdzie każde wdrożenie ma swoje HAR, a obok widoczne są zmiany w ruchu i konwersjach.

Dobre praktyki i pułapki

Ustal spójną metodologię: zawsze ten sam throttling, UA, viewport, moment zakończenia. Unikaj nadmiernej granularności – HAR potrafi być ogromny; filtruj do hostów i ścieżek kluczowych dla SEO. Dbaj o prywatność: tokeny i dane użytkowników maskuj w automatach. Nie diagnozuj wszystkiego wyłącznie z HAR – łącz go z logami serwera, danymi RUM i raportami Search Console, aby tworzyć pełny obraz.