Recenze Browsertrix Crawler: Archivuje to, co udělal prohlížeč, ne to, co říká kód

Browsertrix Crawler je archivační crawler od Webrecorderu: jeden Docker image, který řídí skutečný Chromium přes Puppeteer, zaznamenává všechno, co prohlížeč stáhl, a ukládá to do WARC — standardního formátu webových archivů — volitelně zabaleného do balíčku WACZ s indexem, seznamem stránek a logy. Právě jeho účel ho odlišuje od nástrojů na scraping, s nimiž si ho člověk může na první pohled splést. Scraper si jde pro data a stránku po získání polí zahodí; archivátor si ponechá samotnou návštěvu — bajty, hlavičky, pořadí, v jakém dorazily — aby šla stránka znovu otevřít i dlouho poté, co se web změnil nebo zmizel. Webrecorder tuhle vrstvu webové infrastruktury, včetně formátů a replay stacku, udržuje dávno předtím, než se archivace začala tvářit jako produktová kategorie, a používají ji knihovny, redakce i výzkumníci.

Spustil jsem verzi v1.14.0 v Dockeru proti lokálnímu fixture se čtyřmi záměrně odlišnými typy endpointů a měřil jsem obě strany crawlu: WARC záznamy pro obsah archivu i serverový čítač zásahů pro skutečné requesty. Důležitý rozdíl nebyl jen statický versus dynamický. Browsertrix zachytil odkaz vytvořený za běhu a page-issued fetch(), ale nepožádal o dvě doslovné URL uvnitř nevolané JavaScriptové funkce.

Propojený soubor app.js byl archivován celý, včetně obou doslovných cest, ale ani jeden z těchto endpointů nevytvořil response record, request record ani serverový zásah. Funkce, která je obsahovala, se nikdy nespustila. Tento článek proto hodnotí Browsertrix jako archivátor browser session, ne jako inventář všech URL zmíněných ve zdrojovém kódu.

Co Browsertrix Crawler ve skutečnosti je

Spousta lidí sem přijde s očekáváním scraperského nástroje a odchází zklamaná. Nic v defaultním pipeline vám nedá CSV s cenami produktů — a čekat to je asi jako čekat, že palubní kamera napíše dopravní hlášení. Výstupem je záznam prohlížecí session, který lze znovu přehrát, a každé rozhodnutí v návrhu tomu odpovídá.

Testoval jsem v1.14.0 dne 27. července 2026: webrecorder/browsertrix-crawler:latest s digestem sha256:9d6800a8…, přičemž crawl --version potvrdil build. Projekt je pod licencí AGPL-3.0. Všechna měření běžela v Dockeru přes Colima na macOS arm64 proti řízenému lokálnímu fixture; serverový čítač poskytl důkaz nezávislý na logách Browsertrixu i parsování archivu.

AGPL-3.0 si zaslouží samostatnou poznámku. Silný copyleft s podmínkami pro síťové použití. Pokud má Browsertrix Crawler sedět uvnitř komerčního produktu, a ne běžet jen jako samostatný nástroj, nechte si licenci před nasazením pořádně projít. To je upozornění, ne právní rada.

Archiv zachycuje session, ne zdrojový kód

Moje fixture servírovala čtyři typy endpointů, záměrně oddělené, protože archivační nástroj s nimi zachází naprosto odlišně:

• Třída A — obyčejný <a href> v HTML. Čtyři stránky plus řetězec do hloubky tří úrovní. Najde je každý crawler na světě.
• Třída B — doslovné URL uvnitř funkce, která se nikdy nespustí. Dvě cesty, /api/js-endpoint-7 a /api/js-endpoint-8, uložené jako stringy v nevolané loadData() v připojeném app.js.
• Třída C — odkaz sestavený za běhu. <a href> složený z fragmentů v JavaScriptu ('endpoint' + (6 * 7)) a přidaný do DOMu. Souvislá cesta /runtime-only/endpoint42 neexistuje v žádném servírovaném bajtu.
• Třída D — fetch(), které stránka skutečně provede. Cesta složená stejným způsobem ('runtime-xhr-' + (33 * 3)), a pak opravdu vyžádaná při načtení.

U tříd C a D chyběly celé cesty jako souvislé stringy v servírovaných souborech. Serverové zásahy a response records jsou proto důkazem, že v této fixture došlo ke konstrukci za běhu i k request cestám.

Co se zachytilo a co ne

Dva nástroje, ověřované proti sobě v každé buňce: WARC response records (co je v archivu) a serverový čítač zásahů fixture, klíčovaný podle (Host header, path) (co bylo skutečně vyžádáno). Ve všem se shodly.

Třída C je ta, která odděluje skutečný browser od statického crawl. Výchozí extrakce odkazů čte renderované DOM (a[href]->href, podle dokumentace common options), takže odkaz, který vznikne až po běhu JavaScriptu, se stejně zařadí do fronty, stáhne a archivuje. Třída D dopadla z jiného důvodu — stránka sama request skutečně poslala a archivátor seděl na síťové cestě a zapisoval vše, co prošlo.

Jeden poctivý limit u třídy C: můj odkaz byl vložen synchronně při načtení stránky. Odkazy, které se objeví později během Browsertrix behaviors, jsou jiný případ a existuje na to otevřený issue — #723, "Links on pages that are discovered during behaviors are not extracted". Ten scénář jsem netestoval, takže o něm netvrdím nic ani jedním směrem.

Soubor byl archivován. Endpoints ne.

Ověření, že třída B opravdu chybí, vyžadovalo projít WARC záznam po záznamu, ne jen spočítat souhrn.

app.js v archivu je — jeden response record, JavaScriptové tělo o velikosti 222 bajtů — a obě doslovné hodnoty třídy B jsou v něm vidět přesně tak, jak byly. Zato /api/js-endpoint-7 ani /api/js-endpoint-8 nejsou cílovým URI ani jednoho záznamu v celém souboru: nula response records, nula request records. Každý z těchto stringů se v celém archivu vyskytuje přesně jednou a pokaždé je to uvnitř uloženého těla app.js.

To vyvrací nudné vysvětlení („app.js se nikdy nestáhl“). Archivátor soubor, který na tyto endpointy odkazuje, uložil, ale o ty endpointy si nikdy neřekl, protože loadData() se nespustila. Výchozí behaviors Browsertrixu běžely — autoplay, autofetch, autoscroll, siteSpecific — a autofetch je nezachránil, což dává smysl, jakmile si přečtete, co autofetch dělá: jde po img srcset položkách, stylesheetech a data-* URL, ne po string literálech schovaných v tělech funkcí.

Pro srovnání jsem ve stejné fixture spustil i Katana v1.6.1 jako katana -u <seed> -jc -silent -nc -d 4. Jeho syrové discovery summary ukazuje opačný výsledek u dvou záměrně vytvořených JavaScriptových tříd:

Oba příkazy používaly stejnou fixture i stejná jména endpointů. Tabulka není obecné pořadí browser a statických crawlerů; ukazuje, proč inventář endpointů a zachování session vyžadují různé testy pokrytí.

„Skutečný browser, takže zachytí všechno, co dělá JavaScript“ je věta, kterou u takových nástrojů uvidíte pořád. Je přehnaná. Zachytí jen provoz, který se opravdu vykonal. Kód, který na URL jen odkazuje, ale nikdy ji nezavolá, nevytvoří žádný traffic, a bez trafficu není co zaznamenat.

Replay body tam jsou, jednu věc jsem ale neověřil

U dvou endpointů vzniklých za běhu jsem z WARC vytáhl archivovaná HTTP response bodies a potvrdil, že obsahují servírované JSON: 206 bajtů pro cíl runtime-injected odkazu a 201 bajtů pro cíl runtime fetch(). Nejde tedy o indexové stuby odkazující na prázdno — obsah je skutečně v archivu, což je podmínka pro replay, aby je mohl zobrazit.

Co jsem neudělal, bylo postavit pywb nebo replayweb.page a archiv opravdu přehrát. Tělo v archivu a správný vykreslený replay jsou dvě různé věci a tento test pokrývá jen první z nich. Chování replaye, kontrola autenticity, chain of custody a použitelnost jako důkaz vyžadují samostatné ověření.

Produkční capture potřebuje širší akceptační test

Tahleta fixture odpovídá na úzkou otázku jasně: stal se synchronní runtime odkaz a request vyvolaný stránkou skutečným network trafficem a archivními záznamy? Produkční archivační úloha ale obvykle umí selhat ještě řadou dalších způsobů, a přitom pořád vyprodukuje platný WACZ.

Začněte replayem. Otevřete balíček v replay systému, který se skutečně bude používat, a porovnejte pevně daný soubor stránek s referencí z času capture. Zkontrolujte renderovaný text, obrázky, styly, navigaci i interakce, které jsou pro záznam důležité. Pak se podívejte do network panelu replay browseru, jestli nechybí subresource. Response body může ve WARC existovat, ale replay přesto selže, protože přepisování URL, indexy, timing, původ nebo závislosti nesedí. Tahle recenze tu hranici nepřekračovala.

Dynamické chování si zaslouží vlastní sadu fixture. Odkaz třídy C se tady objevil synchronně při načtení stránky. Reálné aplikace ale mohou obsah odhalovat až po timerech, scrollování, zavření consent dialogu, změnách route, custom elementech nebo dlouhých API řetězcích. Umístěte známý cíl za každé chování, na kterém závisíte, a ověřte serverový zásah i archivované tělo. Defaultní behaviors Browsertrixu jsou pro takový test užitečným vstupem, ne důkazem, že se každé opožděné stavové zobrazení skutečně objevilo. Issue #723 je obzvlášť relevantní, pokud se odkazy objevují během behaviors, ne během prvního průběhu stránky.

Autentizované capture přidávají otázky kolem session. Ověřte, že se login stav dostane do browser profilu, přežije potřebné navigace a neunikne do kolekcí, které mají zůstat izolované. Otestujte obnovu tokenu i logout cestu. Pokud archiv obsahuje soukromý nebo osobní materiál, zahrňte do stejného akceptačního plánu i kontrolu přístupu a retence výsledných souborů. Technicky kompletní capture se i tak může po dokončení špatně zacházet.

Service workers, streaming media, WebSockets, stahování souborů, cross-origin iframy a signed URL si zaslouží reprezentativní stránku, pokud jsou pro cíl důležité. Jedenáctistránkové fixture o nich nic neříká. Stejně tak neprokazuje, co crawler udělá, když stránka zůstane aktivní několik minut, posílá requesty po běžném settle okně nebo vyžaduje uživatelské gesto. Nedělejte z „real Chromium“ univerzální tvrzení o pokrytí; definujte chování browseru, která musí být zachována, a udělejte je měřitelná.

A nakonec si uchovejte důkazy, podle kterých půjde chyby diagnostikovat. Uložte přesný image digest a příkaz, logy Browsertrixu, seznamy stránek, indexy, checksums WARC/WACZ, serverové důkazy requestů tam, kde jsou k dispozici, a malý ground-truth manifest. U opakovaných capture zaznamenávejte čas, konfiguraci a prostředí spolu s artefaktem. Tyto záznamy samy o sobě nevytvoří právní průkaznost, ale umožní technické tvrzení zopakovat a ukážou, zda pozdější rozdíl vznikl na straně cíle, crawleru, nebo replay stacku.

Co tahle fixture s malými body stála v bajtech

Tahleta fixture servíruje jen pár stovek bajtů na stránku, takže její poměry overheadu nelze přenášet na weby s těžkými assety. V tomto úzkém režimu jsem měřil složení archivu, ne jen jeho výslednou velikost:

Počty a součty bajtů podle typu jsou ve veřejném capture-summary.json; podíly používají jako základ celkový obsah záznamů 17,024 bajtů.

V tomto běhu s malými body převažovaly request records nad response obsahem a bajty za requesty plus urn:pageinfo: byly asi 2,1× větší než samotný response payload. To popisuje mix záznamů v této fixture, ne obecný poměr WARC.

Na disku, napříč třemi izolovanými běhy:

Z mediánů z toho vyjdou čtyři poměry:

A přímo uvnitř WACZ:

Právě ten poslední řádek mě překvapil nejvíc. Téměř třetina archivačního balíčku je v malém crawl záznam o crawl, ne o webu.

Měření bylo stabilní: response payload se ve všech třech bězích vrátil bajtově identický (vždy 5,339 B), zatímco WARC.gz a WACZ kolísaly pod 0,4 %.

Tyto poměry nelze přenášet na skutečné stránky s obrázky, fonty a velkými JavaScript bundle. Strukturální pointa ale platí: request a page-info záznamy vytvářejí overhead nezávisle na velikosti payloadu. Pro plánování produkčního úložiště měřte reprezentativní vzorek; nemnožte fixture poměr 10× jen podle odhadu počtu URL.

Setup a kolik disku si připravit

Jakmile máte nainstalovaný a spuštěný Docker nebo Colima, nastavení specifické pro Browsertrix je docker pull webrecorder/browsertrix-crawler:latest a potom docker run … crawl --url … --generateWACZ. Image už obsahuje Chromium, takže nebyl potřeba žádný samostatný browser ani Python prostředí.

Kolik pohodlí to stojí, podle měření v těchto bězích:

Kontejner je místo, kde se skrývá tření, a právě tahle dvojice download + unpack ukazuje cenu zabaleného browseru. Spouštěl jsem to s --shm-size 1g a protože moje fixture běžela na hostiteli, zatímco crawl běžel v kontejneru, potřeboval jsem --add-host=host.docker.internal:host-gateway a fixture navázanou na 0.0.0.0 místo loopbacku. Pokud crawlujete veřejný internet, tenhle síťový krok vynecháte; pokud ale archivujete něco na vlastním stroji nebo na interním staging hostu, vyhraďte si na to odpoledne.

Output directory je řádek, který se nejčastěji podceňuje. Když ten růst přenesete na reálný crawl, plánujte úložiště před startem, ne až ve chvíli, kdy vám ve tři ráno dojde místo.

Start browseru pravděpodobně výrazně přispívá k crawl trvajícímu 28–30 sekund i pro pouhých jedenáct stránek, ale neoddělil jsem startup od navigace ani od času balení. Z tohoto běhu nelze vyvozovat žádný závěr o průchodnosti na stránku.

Plánování úložiště bez zneužití poměrů z této fixture

Správný způsob, jak velikost kolekce odhadnout, je empirický. Vyberte stránky, které odpovídají skutečné distribuci cíle: tenké aplikační shell stránky, landing pages s množstvím obrázků, stahování dokumentů, dlouhé články i autentizované pohledy, pokud jsou ve scope. Každou třídu zachyťte s chováním a packaging nastavením, které chcete používat. Změřte response payload, WARC, WACZ, indexy, logy, zbytky browser profilu i dočasný workspace, který po běhu zůstává. Na špičkovém využití disku záleží stejně jako na výsledném balíčku, pokud se při balení dočasně drží několik kopií najednou.

Oddělte fixní a proměnné komponenty. Container image o velikosti 3,51 GB je nasazovací režie, kterou může jeden worker sdílet mezi mnoha capture. Request records, page-info records, indexy a seznamy stránek rostou s aktivitou crawlů. Response těla silně závisí na cíli, zatímco logy závisí na délce běhu a úrovni verbosity. Retence a replikace pak výslednou kolekci násobí nezávisle na chování crawl. Kapacitní model, který to všechno shrne na „bajty na stránku“, bude křehký.

Komprese a deduplikace také potřebují reprezentativní obsah. V této fixture byl response payload napříč třemi běhy bajtově identický, ale to nepopisuje stránky se střídajícími se reklamami, timestampy, personalizovanými odpověďmi nebo asset URL, které obcházejí cache. Pokud jsou opakované capture součástí programu, měřte po sobě jdoucí capture stejných stránek a kontrolujte revisit records, ne jen předpokládejte, že stránky, které vypadají stejně, se dobře deduplikují. Stejně tak ověřte, zda jsou logy a indexy uchovávány na stejné úrovni replikace jako samotný preservation payload.

Provozní praxe: nastavte varovné limity ještě před startem kolekce. Sledujte volné místo, růst jednotlivých kolekcí, neúspěšné balení i velikost browser profilů nebo dočasných adresářů. Udělejte si restore cvičení ze stored WACZ, nejen checksum kontrolu. Výše uvedené poměry jsou užitečné proto, že ukazují, které komponenty existují; reprezentativní vzorek zase říká, jak velké budou pro váš web.

Tyto předpoklady si napište vedle kapacitního odhadu a po pilotním crawl se k nim vraťte.

Disciplína ve scope, ověřená dvěma kontrolami

Archivační crawlery, které se rozutíkají mimo zadaný rozsah, jsou reálné provozní riziko — můžete skončit zároveň s právním problémem i s účtem za úložiště. Moje home page odkazovala na http://outofscope.test:<port>/page/out, tedy na jiné hostname mířící na stejnou fixture, takže zásah s tímto Host headerem by prokázal out-of-scope fetch bez jakéhokoli provozu na skutečném internetu.

Druhý řádek je to, co dává prvnímu smysl. Pod any byl odkaz dosažen dvakrát, takže byl dosažitelný — nula u výchozí prefix scope je skutečná disciplína, ne odkaz, který crawler jen přehlédl. Existuje otevřený report o out-of-scope návštěvách v jiných konfiguracích, #788, který jsem na této fixture s výchozí prefix scope nereprodukoval. Je dobré o něm vědět; nestojí za to tvrdit, že jsem ho viděl.

Odolnost byla v dobrém slova smyslu nevýrazná. Route vracející HTTP 500 i mrtvý odkaz byly vyžádány, crawl skončil čistě s platným WARC i WACZ a mrtvý odkaz byl uložen jako deduplikovaný revisit záznam místo toho, aby cokoli shodil.

Klady a zápory

Klady

• Zachytí odkazy vložené do DOM za běhu i page-issued fetch() volání — obojí potvrzeno v archivu i na serveru, na cestách, které nikde jinde jako literály neexistují.
• Statické HTML i průchod do hloubky jsou kompletní: 4/4 odkazů, 3/3 hloubkový řetězec, žádné missy.
• Jakmile běžel Docker/Colima, jeden docker run vytvořil WARC i WACZ; Chromium bylo součástí image.
• Výchozí prefix scope udržel nulu out-of-scope fetchů; any se rozšířil přesně podle dokumentace, takže ovládací prvek dělá to, co slibuje.
• Výstup je archiv podle standardu (WARC, zabalený jako WACZ s CDX indexem a seznamem stránek), ne proprietární blob.
• Téměř deterministické archivy: payload byl ve třech bězích bajtově identický, velikost na disku kolísala pod 0,4 %.
• Čisté chování při chybě: route s 500 a rozbitý odkaz crawl neukončily.

Zápory

• Doslovné URL v neprovedeném JavaScriptu se prostě neobjeví (0/2), i když je soubor, který je obsahuje, archivován. Správně podle návrhu, ale pokud chcete inventář endpointů, je to reálná mezera.
• Velká režie: pull asi 1 GB, 3,51 GB na disku a výstupní adresáře, které rychle rostou.
• Byte overhead je u malých stránek značný — request + pageinfo záznamy převýšily skutečný payload a asi 30 % WACZ tvořil crawl log.
• AGPL-3.0 znamená skutečnou compliance práci, pokud to chcete komerčně embedovat.
• Není to nástroj na strukturovaná data. Není tu schema, mapování polí ani čisté řádky na konci.
• Průchodnost na stránku je záměrně spíš nižší, protože každá stránka jde přes skutečný browser.

Kdo by ho měl použít a kdo ne

Browsertrix je určen pro týmy, jejichž požadovaný artefakt je archiv browserem stažených zdrojů, ne vytažených řádků. V této fixture byly response body stažené za běhu přítomné ve WARC a zabalené do WACZ. Knihovny, redakce i výzkumníci jsou realistickými uživateli, ale produkční nasazení by mělo zvlášť ověřit rendered replay, autentizaci, service workers, consent flow, opožděná chování, streaming assety, retenci a jakékoli požadavky na práci s důkazy.

Vynechte ho, pokud ve skutečnosti potřebujete data. Když je cíl „dej mi všechny produkty a ceny z těchto 400 stránek do spreadsheetu“, je archivátor podivná cesta k výsledku — archivovali byste gigabajty a pak stejně museli psát extrakční kód nad WARC soubory. Vynechte ho také, pokud mapujete API surface aplikace, protože výsledek třídy B říká jasně, že statický JavaScript parser najde endpointy, kterých se Browsertrix vůbec nedotkne. A pokud nesnášíte Docker nebo pracujete někde, kde je image o velikosti 3,5 GB problém, není to nástroj, který se vám přizpůsobí.

Oprávnění a retence

Kontrola scope sama o sobě nedává oprávnění. Před crawl definujte povolené hosty, retenci i přístup k archivu, zvlášť pokud trvalé capture mohou obsahovat osobní údaje. Test prefix/any ukazuje, že konfigurace mění síťový dosah; neurčuje ale, který dosah je pro konkrétní kolekci legální.

Související recenze: právní stránka web scrapingu a archivace.

Alternativy podle požadovaného výstupu

Volte podle artefaktu. Browsertrix cílí na zachování do WARC/WACZ. Knihovna pro automatizaci browseru, jako je Playwright, nabízí programovatelnou stránku, ale balení záznamu je na vás. Crawlery zaměřené na objevování endpointů vypisují URL, zatímco extrakční nástroje vrací text nebo strukturované záznamy. Tyto kategorie mohou sdílet browser, ale stále řeší různé úlohy.

Související recenze: recenze Heritrix.

Zveřejnění: Thunderbit je produkt vydavatele a v této fixture Browsertrixu nebyl testován. Patří do kategorie spravované extrakce a produkuje text stránky nebo strukturovaná data, nikoli archiv podle standardu. Tato recenze podporuje pouze hranici výstupu, ne srovnání výkonu nebo schopností.

Vyzkoušet Thunderbit pro extrakci webových dat

Verdikt

Browsertrix Crawler použijte tehdy, když požadovaným výstupem je capture ve formátu WARC/WACZ a containerizovaný Chromium odpovídá vašemu nasazení. Na této fixture se archivační záznamy a serverové zásahy shodly u synchronního runtime DOM i page-issued fetchů, defaultní prefix scope vyloučil druhý host a chybové route nebránily vytvoření platného archivu.

Před produkčním použitím ověřte replay, opožděná chování, autentizované session, service workers, složení úložiště na reprezentativních stránkách a licenční povinnosti. Testovaná hranice je užší: kódové reference, které se nikdy nespustí, nevytvořily žádný request ani archivní záznam pro své cíle, i když byl obsahující skript zachován.

Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free

Často kladené otázky

Jaký je tady rozdíl mezi WARC a WACZ? WARC obsahuje zachycené requesty, response a související záznamy. WACZ balí WARC spolu s indexy, seznamy stránek, metadaty a logy pro distribuci a replay nástroje. Tahle recenze zkontrolovala oba balíčky, ale žádný replay nevykreslovala.

Jak mám odhadnout úložiště? Změřte reprezentativní stránky a v sample zachovejte celé složení WACZ, včetně logů a indexů. Poměry v tomto článku vycházejí z nezvykle malých response bodies a nejsou vhodné pro násobení počtem URL v produkci.

Nebude se to toulat mimo web, na který jsem to nasměroval? Při mém testování ne na výchozím nastavení. S --scopeType prefix byl odkaz na jiný hostname stažen nula krát; přepnutí na --scopeType any ho stáhlo dvakrát, což dokazuje, že odkaz byl dosažitelný a nula u defaultu byla skutečná disciplína scope. Existuje otevřený upstream report o out-of-scope návštěvách v jiných konfiguracích, který jsem na výchozím nastavení nereprodukoval, takže si raději zkontrolujte vlastní scope nastavení, než budete jen předpokládat.

Co musím otestovat, než prohlásím replay za věrný? Načtěte WACZ v cílovém replay systému a porovnejte renderované stránky, interakce i potřebné subresources s live nebo referenčním capture. Přítomnost těla ve WARC je nutná, ale sama o sobě replay ještě nepotvrzuje.

Přemění Browsertrix archivovanou stránku na strukturované řádky? Ne. Jeho výstupem je archivační balíček, ne tabulka vybraných polí. Pokud potřebujete produkty, ceny, kontakty nebo jiné schema, budete po capture pořád potřebovat extrakční krok — nebo jiný nástroj, jehož primárním výstupem jsou strukturovaná data.