Browsertrix Crawler — recenzja: archiwizuje to, co zrobiła przeglądarka, a nie to, co mówi kod

Browsertrix Crawler to archiwizujący crawler Webrecordera: jeden obraz Dockera uruchamia prawdziwy silnik Chromium przez Puppeteer, zapisuje wszystko, co ta przeglądarka pobrała, i zapisuje to do WARC — standardowego formatu archiwum WWW — opcjonalnie pakując całość do WACZ wraz z indeksem, listą stron i logami. To właśnie jego cel odróżnia go od narzędzi do scrapingu, do których zewnętrznie jest podobny. Scraper zbiera dane i porzuca stronę, gdy ma już potrzebne pola; archiwizator zachowuje samą wizytę — bajty, nagłówki, kolejność ich pobrania — tak aby stronę można było otworzyć ponownie długo po tym, jak serwis się zmieni albo zniknie. Webrecorder utrzymuje tę warstwę infrastruktury sieciowej, wraz z formatami i mechanizmem odtwarzania, od czasu zanim archiwizacja zaczęła przypominać kategorię produktową, a korzystają z niej biblioteki, redakcje i badacze.

Przetestowałem wersję v1.14.0 w Dockerze na lokalnym fixture z czterema celowo różnymi klasami endpointów i instrumentowałem obie strony crawl’a: rekordy WARC dla zawartości archiwum oraz licznik trafień po stronie serwera dla faktycznych żądań. Najważniejsza różnica nie sprowadzała się po prostu do statycznego kontra dynamicznego. Browsertrix zarejestrował link utworzony w czasie działania strony oraz fetch() wywołany przez stronę, ale nie zażądał dwóch literalnych adresów URL umieszczonych wewnątrz niewywołanej funkcji JavaScript.

Dołączony app.js został zarchiwizowany w całości, łącznie z oboma literalnymi ścieżkami, ale żaden z tych endpointów nie wygenerował rekordu odpowiedzi, rekordu żądania ani trafienia po stronie serwera. Funkcja, która je zawierała, nigdy nie została uruchomiona. Ten artykuł ocenia więc Browsertrix jako archiwizator sesji przeglądania, a nie jako inwentaryzator każdego URL-a wspomnianego w kodzie źródłowym.

Czym właściwie jest Browsertrix Crawler

Wiele osób trafia tu z oczekiwaniem scrapera i odchodzi rozczarowanych. W domyślnej ścieżce nie dostaniesz CSV z cenami produktów, a oczekiwanie tego byłoby jak wymaganie, żeby kamera samochodowa napisała raport o ruchu drogowym. Wynikiem jest odtwarzalny zapis sesji przeglądania, a każda decyzja projektowa wynika właśnie z tego.

Testowałem v1.14.0 27 lipca 2026: webrecorder/browsertrix-crawler:latest z digestem sha256:9d6800a8…, a crawl --version potwierdził build. Projekt jest objęty licencją AGPL-3.0. Wszystkie pomiary zostały wykonane w Dockerze przez Colimę na macOS arm64, na kontrolowanym lokalnym fixture; licznik po stronie serwera dostarczał dowód niezależny od logów Browsertrix i analizy archiwum.

AGPL-3.0 wymaga osobnej chwili uwagi. To silny copyleft z zapisami dotyczącymi użycia sieciowego. Jeśli Browsertrix Crawler ma trafić do produktu komercyjnego, a nie działać jako samodzielne narzędzie, przed wdrożeniem niech ktoś porządnie przeczyta licencję. To sygnał ostrzegawczy, nie porada prawna.

Archiwum zapisuje sesję, a nie kod źródłowy

Mój fixture udostępniał cztery rodzaje endpointów, celowo rozdzielone, bo archiwizator traktuje je zupełnie inaczej:

• Klasa A — zwykły <a href> w HTML. Cztery strony i łańcuch zagłębienia na trzy poziomy. Każdy crawler potrafi to znaleźć.
• Klasa B — literały URL wewnątrz funkcji, która nigdy się nie uruchamia. Dwie ścieżki, /api/js-endpoint-7 i /api/js-endpoint-8, zapisane jako stringi w niewywołanym loadData() w podłączonym app.js.
• Klasa C — link zbudowany w czasie działania. <a href> składany z fragmentów w JavaScript ('endpoint' + (6 * 7)) i dopinany do DOM. Ciągła ścieżka /runtime-only/endpoint42 nie istnieje w żadnym serwowanym bajcie.
• Klasa D — fetch(), który strona faktycznie wykonuje. Ścieżka złożona tak samo ('runtime-xhr-' + (33 * 3)), a następnie rzeczywiście pobrana przy ładowaniu.

W klasach C i D pełne ścieżki nie występowały jako ciągłe stringi w serwowanych plikach. Trafienia po stronie serwera i rekordy odpowiedzi są więc dowodem, że w tym fixture faktycznie wykonały się konstrukcja w czasie działania i ścieżki żądań.

Co zostało przechwycone, a czego nie

Dwa instrumenty, porównywane ze sobą w każdym wierszu: rekordy odpowiedzi WARC (to, co jest w archiwum) oraz licznik trafień po stronie serwera dla fixture, zliczany według (Host header, path) (to, co faktycznie zostało pobrane). Zgadzały się wszędzie.

Klasa C wyraźnie pokazuje różnicę między prawdziwą przeglądarką a statycznym crawl’em. Domyślne wykrywanie linków czyta wyrenderowany DOM (a[href]->href, zgodnie z dokumentacją opcji wspólnych), więc link, który pojawia się dopiero po wykonaniu JavaScriptu, nadal zostaje zakolejkowany, pobrany i zarchiwizowany. Klasa D trafia do archiwum z innego powodu — strona sama wysłała żądanie, a archiwizator siedzi na ścieżce sieciowej i zapisuje wszystko, co przechodzi.

Jedno uczciwe zastrzeżenie przy klasie C: mój link został wstrzyknięty synchronicznie przy ładowaniu strony. Linki pojawiające się później, w trakcie zachowań Browsertrix, to osobny przypadek, a dla tego scenariusza istnieje otwarty problem — #723, „Links on pages that are discovered during behaviors are not extracted”. Nie testowałem tego przypadku, więc nie twierdzę o nim nic ani w jedną, ani w drugą stronę.

Plik został zarchiwizowany. Endpointy nie.

Potwierdzenie pominięcia klasy B wymagało przejścia rekord po rekordzie przez WARC, a nie spojrzenia na sam podsumowujący licznik.

app.js jest w archiwum — jeden rekord odpowiedzi, 222-bajtowe ciało JavaScript — i oba literały klasy B występują w nim dosłownie. Tymczasem ani /api/js-endpoint-7, ani /api/js-endpoint-8 nie jest docelowym URI choćby jednego rekordu w całym pliku: zero rekordów odpowiedzi, zero rekordów żądań. Każdy z tych stringów pojawia się dokładnie raz w całym archiwum, a oba wystąpienia są w zapisanym ciele app.js.

To wyklucza nudne wyjaśnienie („app.js w ogóle nie został pobrany”). Archiwizator zapisał plik, który odwołuje się do tych endpointów, ale nigdy nie wysłał do nich żądania, bo loadData() nie zostało wywołane. Domyślne zachowania Browsertrix były aktywne — autoplay, autofetch, autoscroll, siteSpecific — a autofetch również ich nie uratował, co ma sens, jeśli przeczyta się, co robi autofetch: pobiera img z srcset, arkusze stylów i URL-e data-*, a nie stringi schowane w treści funkcji.

Dla porównania w tym samym fixture uruchomiłem też Katana v1.6.1 jako katana -u <seed> -jc -silent -nc -d 4. Jego surowe podsumowanie wykryć pokazuje odwrotny wynik dla dwóch celowo zbudowanych klas JavaScript:

Obie komendy korzystały z tego samego fixture i tych samych nazw endpointów. Tabela nie jest ogólnym rankingiem przeglądarkowych i statycznych crawlerów; pokazuje, dlaczego inwentaryzacja endpointów i zachowanie sesji wymagają różnych testów pokrycia.

„Prawdziwa przeglądarka, więc łapie wszystko, co robi JavaScript” — to zdanie często pojawia się w opisach. Jest zbyt mocne. Narzędzie zapisuje tylko wykonany ruch sieciowy. Kod, który wspomina URL, ale nigdy go nie wywołuje, nie generuje żadnego ruchu, a brak ruchu oznacza brak rekordu.

Treści odpowiedzi są w archiwum, ale jednego nie sprawdzałem

Dla dwóch endpointów utworzonych w czasie działania pobrałem z WARC zapisane ciała odpowiedzi HTTP i potwierdziłem, że zawierają serwowany JSON: 206 bajtów dla celu linku wstrzykniętego runtime’owo i 201 bajtów dla celu runtime’owego fetch(). To nie są więc puste stuby indeksu prowadzące donikąd — sama treść jest w archiwum, a to jest warunek konieczny, by odtwarzanie mogło je poprawnie podać.

Czego nie zrobiłem, to nie uruchomiłem pywb ani replayweb.page i nie wyrenderowałem archiwum. Obecność ciała w archiwum i poprawne wyrenderowanie replay to dwie różne tezy, a ten test obejmuje tylko pierwszą. Zachowanie odtwarzania, kontrola autentyczności, łańcuch dowodowy i dopuszczalność dowodowa wymagają osobnej walidacji.

Produkcyjne przechwytywanie potrzebuje szerszego testu akceptacyjnego

Fixture odpowiada precyzyjnie na wąskie pytanie: czy synchroniczny link runtime i żądanie wysłane przez stronę stały się ruchem sieciowym i rekordami archiwum? Produkcyjne zadanie archiwizacji zwykle może jeszcze kilka razy polec, mimo że wynikowy WACZ wygląda poprawnie.

Zacznij od replay. Otwórz pakiet w systemie odtwarzania, z którego zbiór faktycznie będzie korzystał, i porównaj ustalony zestaw stron z referencją z czasu capture. Sprawdź tekst wyrenderowany, obrazy, style, nawigację i wszelkie interakcje istotne dla zapisu. Następnie przejrzyj panel sieciowy przeglądarki odtwarzającej pod kątem brakujących subzasobów. Ciało odpowiedzi może istnieć w WARC, a odtwarzanie nadal może się wysypać, jeśli przepisywanie adresów, indeksy, timing, originy albo zależności nie pasują. Ta recenzja nie przekraczała tej granicy.

Dynamiczne zachowania zasługują na własny zestaw fixture’ów. Link klasy C pojawił się tutaj synchronicznie przy ładowaniu strony. Prawdziwe aplikacje mogą ujawniać treści dopiero po timerach, przewijaniu, zamknięciu zgody, zmianach routingu, custom elements albo długich łańcuchach API. Podłóż po jednym znanym celu za każdym zachowaniem, na którym Ci zależy, i potwierdź zarówno trafienie po stronie serwera, jak i zarchiwizowane ciało. Domyślne zachowania Browsertrix są przydatnym wejściem do takiego testu, ale nie stanowią dowodu, że dotarto do każdego opóźnionego stanu. Issue #723 jest szczególnie ważny, jeśli linki pojawiają się podczas zachowań, a nie podczas początkowego wykonania strony.

Przechwytywanie uwierzytelnione wprowadza pytania o sesję. Upewnij się, że stan logowania trafia do profilu przeglądarki, przetrwa wymagane przejścia i nie przecieka do kolekcji, które powinny pozostać odizolowane. Przećwicz odświeżanie tokenów i ścieżki wylogowania. Jeśli archiwum zawiera materiały prywatne lub osobowe, sprawdź też kontrolę dostępu i retencję wynikowych plików jako część tego samego planu akceptacyjnego. Technicznie poprawne przechwycenie nadal może zostać źle obsłużone po zebraniu.

Service workery, streaming media, WebSockety, pobrania plików, ramki cross-origin i signed URLs każdy zasługują na reprezentatywną stronę, jeśli mają znaczenie dla celu. Jedenastostronicowy fixture nie mówi o nich nic. Nie ustala też, jak crawler zachowuje się, gdy strona pozostaje aktywna przez kilka minut, wysyła żądania po zwykłym oknie uspokojenia albo wymaga gestów użytkownika. Nie zamieniaj „prawdziwego Chromium” w uniwersalną deklarację pokrycia; zdefiniuj zachowania przeglądarki, które kolekcja ma zachować, i spraw, by każde z nich było obserwowalne.

Na koniec zachowaj dowody potrzebne do diagnostyki pominięć. Zapisz dokładny digest obrazu i komendę, logi Browsertrix, listy stron, indeksy, sumy kontrolne WARC/WACZ, dostępne po stronie serwera dowody żądań oraz mały manifest prawdy referencyjnej. Przy powtarzanych capture’ach odnotowuj czas, konfigurację i środowisko razem z artefaktem. Takie zapisy nie tworzą dopuszczalności prawnej, ale sprawiają, że twierdzenie techniczne staje się odtwarzalne i pozwalają ustalić, czy późniejsza różnica wynika z celu, crawlera czy warstwy replay.

Ile bajtów kosztował ten fixture z małymi odpowiedziami

Ten fixture serwuje tylko po kilka setek bajtów na stronę, więc jego proporcji narzutu nie należy przenosić na serwisy bogate w zasoby. W tak wąskim zakresie zmierzyłem skład archiwum, a nie tylko jego końcowy rozmiar:

Liczby per typ i sumy bajtów pochodzą z publicznego capture-summary.json; udziały liczone są względem łącznej zawartości rekordów 17,024 bajty.

W tym małym uruchomieniu rekordy żądań ważyły więcej niż sama zawartość odpowiedzi, a bajty request + urn:pageinfo: były około 2,1× większe niż payload odpowiedzi. To opis składów rekordów tego fixture’u, a nie ogólnej proporcji WARC.

Na dysku, w trzech odizolowanych uruchomieniach:

Biorąc mediany, wychodzą cztery proporcje:

A wewnątrz samego WACZ:

Ten ostatni wiersz był dla mnie zaskoczeniem. Prawie jedna trzecia paczki archiwum, przy małym crawl’u, to zapis samego crawl’a, a nie WWW.

Pomiar był stabilny: payload odpowiedzi wracał bajt w bajt identyczny we wszystkich trzech uruchomieniach (za każdym razem 5,339 B), a WARC.gz i WACZ wahały się poniżej 0,4%.

Te proporcje nie przenoszą się na prawdziwe strony z obrazami, fontami i dużymi paczkami skryptów. Strukturalny wniosek pozostaje jednak ten sam: rekordy request i page-info tworzą narzut niezależny od wielkości payloadu. Zmierz reprezentatywną próbkę, zanim zaczniesz planować produkcyjne storage; nie mnoż proporcji 10× z tego fixture’u przez szacunek dla całej korpusu.

Konfiguracja i miejsce na dysku, które warto zaplanować

Gdy Docker lub Colima są zainstalowane i uruchomione, konfiguracja specyficzna dla Browsertrix sprowadza się do docker pull webrecorder/browsertrix-crawler:latest, a potem docker run … crawl --url … --generateWACZ. Obraz zawiera Chromium, więc nie trzeba osobnej przeglądarki ani środowiska Pythona.

Koszt tej wygody w mierzonych tutaj uruchomieniach:

To kontener jest miejscem tarcia, a linia download+unpack pokazuje koszt dołączenia przeglądarki. Uruchamiałem to z --shm-size 1g, a ponieważ mój fixture znajdował się na hoście, a crawl działał w kontenerze, potrzebowałem --add-host=host.docker.internal:host-gateway oraz fixture’a zbindowanego do 0.0.0.0, a nie do loopback. Jeśli crawl’ujesz publiczny internet, możesz pominąć ten krok sieciowy, ale jeśli archiwizujesz coś na własnej maszynie albo na wewnętrznym hostingu stagingowym, zarezerwuj na to popołudnie.

Katalog wyjściowy to wiersz, który najłatwiej zaniżyć. Przełóż ten wzrost na prawdziwy crawl i zaplanuj storage zanim zaczniesz, a nie dopiero gdy o 3 nad ranem skończy się miejsce na dysku.

Prawdopodobnie uruchamianie przeglądarki istotnie wpływa na crawl 11 stron trwający 28–30 sekund, ale nie rozdzieliłem czasu startu od czasu nawigacji ani pakowania. Z tego przebiegu nie wynika żaden wniosek o przepustowości per page.

Planowanie storage bez nadużywania proporcji z fixture’u

Najlepszy sposób określania rozmiaru kolekcji jest empiryczny. Wybierz strony reprezentujące rzeczywisty rozkład celu: lekkie szkielety aplikacji, landing pages z dużą liczbą obrazów, pobrania dokumentów, długie artykuły i widoki uwierzytelnione, jeśli są w zakresie. Zarchiwizuj każdą klasę z zamierzonymi zachowaniami i ustawieniami pakowania. Zmierz payload odpowiedzi, WARC, WACZ, indeksy, logi, pozostałości profilu przeglądarki oraz każdy tymczasowy workspace, który zostaje podczas uruchomienia. Szczytowe użycie dysku jest równie ważne jak finalny pakiet, jeśli pakowanie na chwilę trzyma kilka kopii naraz.

Rozdziel komponenty stałe i zmienne. Obraz kontenera 3,51 GB to narzut wdrożeniowy, który może być współdzielony przez wiele capture’ów na jednym workerze. Rekordy request, rekordy page-info, indeksy i listy stron rosną wraz z aktywnością crawl’a. Treści odpowiedzi zależą głównie od celu, a logi — od długości i gadatliwości uruchomienia. Retencja i replikacja mnożą finalną kolekcję niezależnie od zachowania crawl’a. Model pojemności oparty wyłącznie na „bajtach na stronę” będzie kruchy.

Kompresja i deduplikacja też potrzebują reprezentatywnej treści. Payload odpowiedzi w tym fixture był identyczny bajt w bajt we wszystkich trzech uruchomieniach, ale nie opisuje to stron z reklamami zmieniającymi się co chwila, znacznikami czasu, spersonalizowanymi odpowiedziami czy URL-ami zasobów zmieniającymi się dla uniknięcia cache. Jeśli powtarzane capture’y są częścią programu, mierz kolejne przechwycenia tych samych stron i analizuj rekordy revisit zamiast zakładać, że strony wyglądające na niezmienione dobrze się deduplikują. Podobnie sprawdź, czy logi i indeksy są utrzymywane na tym samym poziomie replikacji co payload archiwizacji.

Operacyjnie ustaw progi ostrzegawcze zanim kolekcja ruszy. Monitoruj wolne miejsce, wzrost per kolekcja, nieudane pakowanie oraz rozmiar profili przeglądarki i katalogów tymczasowych. Przetestuj odtworzenie z zapisanego WACZ, a nie tylko przejście po sumach kontrolnych. Powyższe proporcje są przydatne, bo pokazują, jakie komponenty istnieją; reprezentatywna próbka mówi dopiero, jak duże będą one dla Twojej strony.

Udokumentuj te założenia obok szacunku pojemności i wróć do nich po pilotażowym crawl’u.

Dyscyplina zakresu, sprawdzona dwoma kontrolami

Archiwizujące crawlery, które „odpływają” poza zakres, są realnym zagrożeniem operacyjnym — możesz jednocześnie narobić problemów prawnych i dostać wysoki rachunek za storage. Moja strona główna linkowała do http://outofscope.test:<port>/page/out, czyli innego hosta wskazującego na ten sam fixture, więc trafienie z takim nagłówkiem Host potwierdziłoby pobranie spoza zakresu bez udziału prawdziwego internetu.

Drugi wiersz sprawia, że pierwszy ma sens. W trybie any link został osiągnięty dwa razy, więc był osiągalny — zero przy domyślnym zakresie prefix to realna dyscyplina zakresu, a nie link, którego crawler po prostu nie zauważył. Istnieje otwarty upstreamowy raport o wyjściach poza zakres w innych konfiguracjach, #788, którego nie odtworzyłem przy domyślnym prefix scope na tym fixture. Warto wiedzieć, że istnieje; nie warto twierdzić, że go widziałem.

Odporność była po prostu dobra. Trasa zwracająca HTTP 500 i martwy link zostały pobrane, crawl zakończył się poprawnie z ważnym WARC i WACZ, a martwy link zapisano jako zdeduplikowany rekord revisit, zamiast powodować awarię.

Plusy i minusy

Plusy

• Przechwytuje linki do DOM wstrzyknięte runtime’owo oraz wywołania fetch() wysyłane przez stronę — oba przypadki potwierdzone w archiwum i po stronie serwera, na ścieżkach, które nigdzie nie występują jako literały.
• Statyczny HTML i przechodzenie wgłębień są kompletne: 4/4 linków, 3/3 łańcucha zagłębienia, bez pomyłek.
• Gdy Docker/Colima już działały, jedno docker run tworzyło WARC i WACZ; Chromium było spakowane w obrazie.
• Domyślny zakres prefix nie dopuścił do żadnych pobrań spoza zakresu; any rozszerzał zakres zgodnie z dokumentacją, więc przełącznik robi to, co obiecuje.
• Wynik to archiwum oparte na standardzie (WARC, spakowane jako WACZ z indeksem CDX i listą stron), a nie zamknięty, własnościowy blob.
• Archiwa są niemal deterministyczne: payload identyczny bajt w bajt przez trzy uruchomienia, a rozmiar na dysku zmieniał się o mniej niż 0,4%.
• Czyste zachowanie przy błędach: trasa 500 i uszkodzony link nie przerwały crawl’a.

Minusy

• Literały URL w niewykonanym JavaScript po prostu nie są wykrywane (0/2), nawet jeśli plik, który je zawiera, zostanie zarchiwizowany. To poprawne z założenia, ale nadal realna luka w pokryciu, jeśli celem jest odkrywanie endpointów.
• Ciężki footprint: ~1 GB do pobrania, 3,51 GB na dysku i katalogi wyjściowe, które szybko rosną.
• Narzut bajtowy jest znaczny przy małych stronach — same rekordy request i pageinfo przekroczyły rzeczywisty payload, a ~30% WACZ stanowił log crawl’a.
• AGPL-3.0 oznacza realną pracę nad zgodnością dla komercyjnego osadzania.
• To nie jest narzędzie do danych strukturalnych. Nie ma schematu, mapowania pól ani gotowych wierszy na końcu.
• Przepustowość na stronę jest z definicji umiarkowana, bo każda strona przechodzi przez prawdziwą przeglądarkę.

Dla kogo to jest, a dla kogo nie

Browsertrix jest przeznaczony dla zespołów, których potrzebnym artefaktem jest archiwum zasobów pobranych przez przeglądarkę, a nie wyekstrahowane wiersze danych. W tym fixture’ze odpowiedzi pobrane runtime’owo były obecne w WARC i spakowane do WACZ. Biblioteki, redakcje i badacze to sensowni użytkownicy, ale wdrożenie produkcyjne powinno osobno testować replay, uwierzytelnienie, service workery, przepływy zgody, opóźnione zachowania, zasoby streamingowe, kontrolę retencji oraz wszelkie wymagania dotyczące obsługi materiału dowodowego.

Pomiń to, jeśli tak naprawdę potrzebujesz danych. Jeśli celem jest „daj mi każdy produkt i cenę z tych 400 stron w arkuszu”, archiwizator to dziwna droga do tego wyniku — zarchiwizujesz gigabajty, a potem i tak będziesz musiał pisać kod ekstrakcji na plikach WARC. Pomiń też, jeśli mapujesz powierzchnię API aplikacji, bo wynik klasy B mówi wprost, że statyczny parser JavaScript znajdzie endpointy, których Browsertrix nigdy nie dotyka. No i jeśli nie znosisz Dockera albo pracujesz tam, gdzie obraz 3,5 GB stanowi problem, to nie jest narzędzie, które się dla Ciebie wygnie.

Autoryzacja i retencja

Kontrola zakresu nie jest zgodą. Zdefiniuj dozwolone hosty, retencję i dostęp do archiwum przed crawl’em, szczególnie jeśli trwałe capture’y mogą zawierać dane osobowe. Test prefix/any pokazuje, że zmiana konfiguracji zmienia zasięg sieciowy; nie ustanawia natomiast, jaki zasięg jest zgodny z prawem dla konkretnej kolekcji.

Powiązana analiza: aspekty prawne web scrapingu i archiwizacji.

Alternatywy według wymaganego wyniku

Wybieraj po artefakcie. Browsertrix celuje w zachowanie danych w WARC/WACZ. Biblioteka automatyzacji przeglądarki, taka jak Playwright, daje programowalną stronę, ale pakowanie capture’a zostawia Tobie. Crawlery do odkrywania endpointów wyliczają URL-e, a narzędzia do ekstrakcji zwracają tekst albo rekordy strukturalne. Te kategorie mogą korzystać z tej samej przeglądarki, ale rozwiązują różne zadania.

Powiązana recenzja: recenzja Heritrix.

Ujawnienie: Thunderbit jest produktem wydawcy i nie był testowany w tym fixture Browsertrix. Należy do kategorii zarządzanej ekstrakcji, tworząc tekst stron lub dane strukturalne, a nie archiwum zgodne ze standardem. Ta recenzja wspiera wyłącznie granicę wynikową, a nie porównanie wydajności czy możliwości.

Wypróbuj Thunderbit do ekstrakcji danych z WWW

Werdykt

Użyj Browsertrix Crawler, gdy wymaganym wynikiem jest capture WARC/WACZ, a kontenerowy Chromium pasuje do środowiska wdrożenia. W tym fixture’ze rekordy archiwum i trafienia po stronie serwera zgadzały się dla synchronicznego runtime-DOM i fetch() wysyłanych przez stronę, domyślny prefix scope wykluczał drugi host, a trasy błędów nie przeszkodziły w powstaniu poprawnego archiwum.

Przed produkcyjnym użyciem zweryfikuj replay, opóźnione zachowania, sesje uwierzytelnione, service workery, skład storage na reprezentatywnych stronach i obowiązki licencyjne. Zakres testu był węższy: odniesienia do kodu, które nigdy się nie wykonały, nie wygenerowały ani żądania, ani rekordu archiwum dla swoich celów, mimo że sam skrypt zawierający te odwołania został zachowany.

Wypróbuj Thunderbit do ekstrakcji danych z WWW Get Started Free

FAQ

Jaka jest tu różnica między WARC a WACZ? WARC zawiera przechwycone rekordy żądań, odpowiedzi i powiązanych danych. WACZ pakuje WARC wraz z indeksami, listami stron, metadanymi i logami na potrzeby dystrybucji i narzędzi odtwarzania. Ta recenzja sprawdziła oba pakiety, ale nie renderowała replay.

Jak oszacować potrzebne miejsce? Zmierz reprezentatywne strony i zachowaj w próbce pełny skład WACZ, łącznie z logami i indeksami. Proporcje w tym artykule pochodzą z wyjątkowo małych odpowiedzi i nie nadają się do mnożenia przez liczbę produkcyjnych URL-i.

Czy narzędzie wyjdzie poza stronę, którą mu wskażę? W moich testach — nie przy ustawieniu domyślnym. Przy --scopeType prefix link do innego hosta nie został pobrany ani razu; po przełączeniu na --scopeType any został pobrany dwa razy, co potwierdza, że link był osiągalny, a zero w domyślnym trybie prefix było prawdziwą dyscypliną zakresu. Istnieje otwarty upstreamowy raport o wyjściach poza zakres w innych konfiguracjach, którego nie odtworzyłem przy domyślnych ustawieniach, więc sprawdź własną konfigurację zakresu zamiast zakładać.

Co trzeba sprawdzić przed uznaniem replay za wierny? Załaduj WACZ w docelowym systemie odtwarzania i porównaj wyrenderowane strony, interakcje oraz wymagane subzasoby z żywym źródłem lub referencyjnym capture. Obecność ciała w WARC jest konieczna, ale sama w sobie nie potwierdza poprawności wyrenderowanego replay.

Czy Browsertrix zamienia zarchiwizowaną stronę w uporządkowane wiersze danych? Nie. Jego wynik to pakiet archiwalny, a nie tabela wybranych pól. Jeśli dostarczanym rezultatem mają być produkty, ceny, kontakty albo inny schemat, po capture nadal potrzebujesz etapu ekstrakcji — albo innego narzędzia, którego głównym wynikiem są dane strukturalne.