Browsertrix Crawler 評測：它保存的是瀏覽器實際做了什麼，而不是程式碼寫了什麼

Browsertrix Crawler 是 Webrecorder 的封存型爬蟲：一個 Docker 映像透過 Puppeteer 驅動真正的 Chromium，記錄瀏覽器抓取的所有內容，並寫入 WARC——網頁封存的標準格式——也可選擇打包成包含索引、頁面清單與日誌的 WACZ 套件。它的用途，正是它與那些外觀看起來相似的抓取工具之間最大的差異。一般爬蟲是去拿資料，拿到欄位就把頁面丟掉；封存工具則會把整段瀏覽過程都留下來——位元組、標頭、資料到達的順序都保留——讓網站即使日後改版或消失，頁面仍能再次開啟。Webrecorder 一直維護著這層網際網路基礎設施，包含格式與 replay 技術堆疊，甚至早在封存還不像是一個產品類別之前就已經在做了，許多圖書館、新聞編輯室與研究人員都仰賴它。

我在 Docker 中以 v1.14.0 對一個本機測試環境進行測試，這個環境刻意包含四種不同的端點類型，並且同時監測爬取的兩端：一邊是用來檢查封存內容的 WARC 記錄，另一邊是伺服器端的實際請求計數器。真正有價值的區別不只是靜態與動態。Browsertrix 抓到了執行期間才建立的連結，以及頁面發出的 fetch()，但對於某個未被呼叫的 JavaScript 函式裡面的兩個 URL 字面值，卻沒有去請求。

被引用的 app.js 完整被封存了，裡面也包含了那兩個字面路徑；但這兩個端點都沒有任何回應記錄、請求記錄，伺服器端也沒有命中。因為持有它們的函式根本沒被執行。因此，本文評估的是 Browsertrix 作為「瀏覽器工作階段封存工具」的能力，而不是「把原始碼中提到的每個 URL 都列出來」的能力。

Browsertrix Crawler 到底是什麼

很多人帶著抓取工具的期待來，最後卻失望離開。預設流程裡不會直接給你一份產品價格 CSV；如果你期待它這樣做，就像期待行車紀錄器順手幫你寫交通報告一樣。它輸出的，是一份可重播的瀏覽工作階段記錄，後續所有設計決策都圍繞這個目標展開。

我於 2026 年 7 月 27 日測試 v1.14.0：webrecorder/browsertrix-crawler:latest，digest 為 sha256:9d6800a8…，並透過 crawl --version 確認版本。這個專案採用 AGPL-3.0。所有量測都在 macOS arm64 上透過 Colima 於 Docker 中執行，並在受控的本機測試環境下完成；伺服器端計數器提供了獨立於 Browsertrix 日誌與封存解析之外的證據。

AGPL-3.0 值得特別提一下。它是帶有網路使用條款的強烈 copyleft 授權。如果 Browsertrix Crawler 要被放進商業產品裡，而不是當作獨立工具來跑，在正式交付前請務必先讓人完整讀過授權。這是提醒，不是法律意見。

封存的是工作階段，不是原始碼

我的測試環境提供四種端點，刻意分開，因為封存工具會以完全不同方式處理它們：

• A 類 — HTML 裡直接寫的 <a href>。 四個頁面，加上一條三層深度鏈。地球上任何爬蟲都找得到這些。
• B 類 — 函式裡的 URL 字面值，但該函式從未執行。 兩條路徑，/api/js-endpoint-7 和 /api/js-endpoint-8，只是以字串形式存在於連結的 app.js 裡一個未被呼叫的 loadData() 中。
• C 類 — 執行時組出來的連結。 一個 <a href> 由 JavaScript 的片段 ('endpoint' + (6 * 7)) 拼接後再插入 DOM。完整路徑 /runtime-only/endpoint42 並沒有直接存在於任何已提供的位元組中。
• D 類 — 頁面實際發出的 fetch()。 路徑同樣是動態組合出來的 ('runtime-xhr-' + (33 * 3))，然後在載入時真的被請求。

對於 C 與 D 類，完整路徑都沒有以連續字串的形式出現在伺服器提供的檔案中。因此，它們的伺服器端命中與回應記錄，就是這個測試環境中「執行時組裝與請求路徑」確實被觸發的證據。

抓到了什麼，又漏了什麼

兩個量測工具在每個欄位都互相驗證：WARC 的回應記錄（封存裡面有什麼）以及測試環境伺服器端、以 (Host header, path) 為鍵的命中計數器（實際請求了什麼）。它們在所有地方都一致。

C 類是把真正瀏覽器和靜態爬取區分開來的關鍵。預設的連結擷取會讀取渲染後的 DOM（依照 common options 文件，是 a[href]->href），所以只要是 JavaScript 跑完才出現的連結，仍然會被排入佇列、抓取並封存。D 類則是另一回事——頁面自己送出了請求，而封存器正好位在網路路徑上，把經過的內容記錄下來。

關於 C 類有一個誠實的邊界：我的連結是在頁面載入時同步注入的。稍後才在 Browsertrix behaviors 過程中才出現的連結，是另外一個情境，且針對這點已有公開 issue——#723，「在 behaviors 中才發現的頁面連結不會被擷取」。我沒有測這個情境，因此不對它下任何結論。

檔案有被封存，端點卻沒有

要確認 B 類的遺漏，得逐筆檢查 WARC，而不是只看總數摘要。

app.js 確實在封存裡——一筆回應記錄、222 位元組的 JavaScript 內容，而 B 類的兩個字面值也都原封不動地出現在裡面。與此同時，整個檔案中沒有任何一筆記錄的目標 URI 是 /api/js-endpoint-7 或 /api/js-endpoint-8：零回應記錄，零請求記錄。這兩個字串在整份封存裡各只出現一次，而且都只存在於 app.js 儲存下來的內容中。

這就排除了最無聊的解釋（「app.js 根本沒被抓到」）。封存器存下了引用這些端點的檔案，卻沒有對它們發出請求，原因就是 loadData() 沒有被呼叫。Browsertrix 預設的 behaviors 仍然有啟用——autoplay、autofetch、autoscroll、siteSpecific——但 autofetch 也沒有幫上忙，這其實合理，因為一旦看過 autofetch 的說明，就知道它處理的是 img 的 srcset、樣式表與 data-* URL，而不是埋在函式主體裡的字串字面值。

為了做同一環境的對照，我也以 katana -u <seed> -jc -silent -nc -d 4 執行了 Katana v1.6.1。它的原始 discovery summary 對這兩個刻意設計的 JavaScript 類別，記錄出相反的結果：

兩個指令都使用相同的測試環境與端點名稱。這張表不是在做瀏覽器爬蟲與靜態爬蟲的整體排名；它要表達的是，端點盤點與工作階段保留需要不同的覆蓋測試。

「是真瀏覽器，所以 JavaScript 做的事都會被抓到」這種說法，在各種文章裡很常見。但這說法太誇張了。它捕捉的是實際執行後產生的流量。程式碼如果只是引用某個 URL，卻從未呼叫它，那就不會有流量，也就不會有記錄。

replay 內容有進來，但有一件事我沒驗證

對於這兩個由執行時產生的端點，我把 WARC 裡封存的 HTTP 回應內容拉出來看，確認裡面就是伺服器送出的 JSON：執行時注入連結的目標是 206 位元組，runtime fetch() 的目標是 201 位元組。所以它們不是空有索引、實際上什麼都沒有的 stub；內容本身確實在封存裡，這也是 replay 能正常提供它們的前提。

但我沒有把 pywb 或 replayweb.page 架起來去渲染這份封存。封存中有 body 與可正確渲染 replay，是兩件不同的事；這次測試只涵蓋前者。replay 行為、真實性控制、證據保管鏈，以及證據可採性，都需要另外驗證。

真正上線的封存，需要更完整的驗收測試

這個測試環境回答了一個很窄的問題：同步產生的 runtime 連結和頁面發出的請求，有沒有變成網路流量與封存記錄？但真實的保存任務，通常還有更多方式會失敗，即使最後仍產出一個有效的 WACZ。

先從 replay 開始。把封存套件開到實際會使用的 replay 系統裡，拿一組固定頁面對照抓取時的參考結果。檢查渲染後文字、圖片、樣式、導覽，以及記錄所需的任何互動。接著看 replay 瀏覽器的 network 面板，有沒有缺少的子資源。WARC 裡即使有回應 body，replay 仍可能失敗，原因可能是重寫、索引、時序、來源或依賴關係不一致。這次評測沒有跨過那道邊界。

動態行為值得有自己的測試組。這裡的 C 類連結是在頁面載入時同步出現的。真實應用可能要等計時器、捲動、同意彈窗消失、路由變更、自訂元素或一長串 API 才會顯示內容。把你依賴的每一種行為，都埋上一個已知目標，並驗證伺服器命中與封存 body 都有出現。Browsertrix 預設的 behaviors 很適合拿來做這種測試的輸入，但不能拿來證明每個延遲狀態都已經到達。若連結是在 behaviors 過程中才出現，而不是在初始頁面執行期間出現，issue #723 尤其值得注意。

若是需要登入的封存，還要驗證 session 的問題。確認登入狀態有進入瀏覽器 profile、能撐過必要的導覽，而且不會外洩到本該隔離的集合裡。也要跑過 token refresh 與登出流程。如果封存內容含有私密或個人資料，存取控制與保留政策也應該納入同一套驗收計畫。技術上完整的抓取，後續還是可能在資料保管上被搞壞。

如果目標網站重要的是 service worker、串流媒體、WebSocket、下載、跨網域 frame、簽名 URL，那就應該為每一項準備一個代表性頁面。這個 11 頁的測試環境對這些都沒有結論。它也沒有證明當頁面保持活動數分鐘、在常見的 settle 視窗之後才發出請求、或需要使用者手勢時，爬蟲會怎麼表現。不要把「真正的 Chromium」直接等同於全面覆蓋；請明確定義你要保留哪些瀏覽器行為，並讓每一項都可觀測。

最後，請保留能用來診斷遺漏的證據。保存精確的 image digest 與指令、Browsertrix 日誌、頁面清單、索引、WARC/WACZ checksum、可取得的伺服器端請求證據，以及一份小型的 ground-truth manifest。若要重複抓取，時間、設定與環境也應一併記錄在 artifact 旁。這些紀錄不會讓證據自動具備法律可採性，但它們能讓技術主張可重現，也能看出後續差異到底是來自目標、爬蟲，還是 replay 堆疊。

這個小內容測試環境的位元組成本

這個測試環境每頁只提供幾百位元組，因此其開銷比例不該拿去套用到資源很重的網站上。在這個狹窄範圍內，我量的是封存組成，而不只是最後的大小：

各類型筆數與位元組總數可在公開的 capture-summary.json 中查看；佔比則以 17,024 位元組的總記錄內容為分母。

在這次小內容測試中，request 記錄比 response 內容還重，而且 request 加上 urn:pageinfo: 的位元組數，大約是 response payload 的 2.1 倍。這描述的是這個測試環境的記錄組成，不是通用的 WARC 比例。

在磁碟上，經過三次獨立執行後：

取中位數後，可以得到四個比例：

而在 WACZ 內部：

最後那一行最讓我意外。在這種小型爬取中，將近三分之一的封存套件內容不是網頁本身，而是「這次怎麼爬」的紀錄。

這次量測很穩定：response payload 三次都完全一樣（每次都是 5,339 B），而 WARC.gz 與 WACZ 的波動都低於 0.4%。

這些比例不會直接套用到有圖片、字型與大型 script bundle 的真實頁面上。但結構性的重點不會變：request 與 page-info 記錄會產生與 payload 大小無關的額外負擔。要規劃正式儲存前，請先量一個有代表性的樣本；不要把這個 10× 的測試比例直接乘上整個資料集估算。

安裝與你應該預留的磁碟空間

只要 Docker 或 Colima 安裝完成並啟動，Browsertrix 的設定就很單純：先 docker pull webrecorder/browsertrix-crawler:latest，再 docker run … crawl --url … --generateWACZ。這個映像裡已經內建 Chromium，不需要另外裝瀏覽器或 Python 環境。

在這些量測中，這份便利的成本如下：

真正的摩擦點在容器裡，而下載與解壓那一行，就是把瀏覽器打包進來的代價。我用 --shm-size 1g 執行，而且因為我的測試環境在主機上、爬取在容器裡跑，所以我還需要 --add-host=host.docker.internal:host-gateway，並把測試環境綁定到 0.0.0.0，不能只綁 loopback。如果你是要爬公開網際網路，這一步的網路設定就可以省掉；但如果你要封存的是自己機器或內部 staging host 上的內容，最好預留半天處理這些細節。

輸出目錄通常最容易被低估。把這種成長速度外推到真實爬取時，請在開始前就先規劃好儲存空間，不要等到凌晨三點磁碟滿了才補救。

Browser 啟動很可能是這次 11 頁爬取花掉 28–30 秒的重要原因之一，但我沒有把啟動時間、導覽時間與打包時間分開。因此，這次結果不能推導出每頁吞吐量的結論。

不要濫用這個測試環境的比例，儲存規劃要靠實測

規劃一個封存計畫，最好的方式是實證。挑選能代表目標站實際分布的頁面：薄殼應用頁、圖片很多的登入頁、文件下載、長文內容，以及如果範圍包含它們，就加上登入後頁面。用你預計要採用的 behaviors 與打包設定，對每一種類型都抓一次。量測 response payload、WARC、WACZ、索引、日誌、瀏覽器 profile 殘留，以及執行過程中留下的任何暫存工作區。若打包期間會暫時保留多份副本，峰值磁碟用量和最後的封裝大小一樣重要。

固定成本與變動成本要分開看。3.51 GB 的容器映像是部署開銷，同一台 worker 上很多次抓取都可以共用。request 記錄、page-info 記錄、索引與頁面清單會隨抓取活動而成長。response body 很依賴目標站，而日誌則與執行時間和詳細程度有關。後續的保留與複製又會獨立於爬取行為，再把最終集合放大。一個把這些全混成「每頁多少位元組」的容量模型，會非常脆弱。

壓縮與去重也需要有代表性的內容。這個測試環境的 response payload 三次完全一致，但這不代表含有變動廣告、時間戳、個人化回應或 cache-busting 資產 URL 的頁面也會一樣。如果重複抓取是你的流程一部分，請量同一批頁面的連續抓取結果，並檢查 revisit 記錄，而不要假設「看起來沒變」就一定能很好去重。同樣地，也要測試日誌與索引是否會以和保存 payload 相同的複製層級保留。

在營運上，請在開始前先設定警戒閾值。監控可用空間、單一集合的成長、打包失敗，以及瀏覽器設定檔或暫存目錄的大小。從已儲存的 WACZ 做一次還原演練，不要只做 checksum 檢查。上面的比例有用，是因為它們揭示了有哪些元件；真正決定大小的，是有代表性的樣本。

在估算容量旁邊把這些假設寫下來，並在試點爬取後重新檢視。

用兩個控制組來測範圍紀律

會亂逛的封存爬蟲是真實的營運風險——你可能同時拿到法律問題和儲存費帳單。我的首頁連到 http://outofscope.test:<port>/page/out，這是指向同一個測試環境、但主機名稱不同的網址，因此如果看到帶著那個 Host header 的命中，就能證明有抓到範圍外的內容，而且不是因為真的接觸外網。

第二列之所以重要，是因為它讓第一列有意義。在 any 下，那個連結被抓了兩次，表示它確實可達——預設 prefix scope 下的 0 次，是真的範圍控制，不是爬蟲漏掉了連結。上游還有一則關於其他設定下範圍外訪問的公開報告，#788，但我沒有在這個測試環境的預設 prefix scope 下重現。知道它存在就夠了，不需要我說自己看到了。

穩定性表現得很好。回傳 HTTP 500 的路由和死連結都被請求到了，爬取正常結束，產出有效的 WARC 與 WACZ，而死連結則是以去重的 revisit 記錄存下來，沒有把任何東西弄爆。

優點與缺點

優點

• 能捕捉 runtime 注入的 DOM 連結與頁面發出的 fetch()；這兩者都在封存與伺服器端獲得確認，而且路徑在任何原始字面值中都不存在。
• 靜態 HTML 與深度遍歷都完整：4/4 連結、3/3 深度鏈，沒有漏抓。
• 只要 Docker/Colima 已啟動，一次 docker run 就能產出 WARC 與 WACZ；Chromium 內建在映像裡。
• 預設 prefix scope 沒有抓到任何範圍外請求；any 會如文件所述放寬範圍，所以這個開關真的照說明運作。
• 輸出是基於標準的封存格式（WARC，並以 WACZ 包裝，含 CDX 索引與頁面清單），不是專有格式。
• 封存結果近乎可重現：三次抓取的 payload 位元組完全一致，磁碟大小波動低於 0.4%。
• 錯誤處理乾淨：500 路由與損壞連結都沒有中止爬取。

缺點

• 未執行的 JavaScript 裡的 URL 字面值根本不會被發現（0/2），即使包含它們的檔案有被完整封存也是如此。這設計本來就沒錯，但如果你的目標是端點盤點，這仍然是實際覆蓋缺口。
• 檔案很重：下載約 1 GB、磁碟上 3.51 GB，而且輸出目錄成長很快。
• 小型頁面的位元組開銷相當大——request 加 pageinfo 記錄甚至超過實際 payload，而 WACZ 的約 30% 是爬取日誌。
• AGPL-3.0 代表商業內嵌時要做真正的授權合規功課。
• 它不是結構化資料工具。沒有 schema、沒有欄位對應、最後也不會直接產出整齊的資料列。
• 因為每一頁都得經過真正的瀏覽器，所以每頁吞吐量本來就不會太高。

誰適合用，誰不適合

Browsertrix 的目標對象，是那些真正需要的是瀏覽器抓取資源的封存，而不是抽出後的資料列的團隊。在這個測試環境中，執行時抓到的 response body 已經存在於 WARC，並被打包進 WACZ。圖書館、新聞室與研究人員都可能是適合的使用者，但正式導入仍應另外測試 rendered replay、驗證、service worker、同意流程、延遲行為、串流資產、保留控制，以及任何證據處理要求。

如果你真正需要的是資料，就別用它。若目標是「把這 400 個頁面裡所有產品與價格都抓成試算表」，封存器會是很繞遠路的做法——你會先封存好幾 GB，之後還是得另外寫 WARC 的抽取程式。若你的任務是描繪應用程式的 API 表面，也不太適合，因為 B 類結果已經很明白地說明：靜態 JavaScript 解析器會找到 Browsertrix 完全不會碰的端點。而如果你討厭 Docker，或 3.5 GB 映像對你來說就是麻煩，這也不是會為你彎腰的工具。

授權與保留

範圍控制不等於授權。開始爬取前，請先定義允許的主機、保留期限與封存存取權限，尤其是當長期保存的內容可能包含個人資料時。prefix/any 的測試說明了設定可以改變網路可達範圍；但它沒有告訴你，對某個特定集合來說，哪些範圍是合法的。

延伸閱讀：網頁爬取與封存的法律面。

依輸出需求選替代方案

請依你要交付的成品來選。Browsertrix 的目標是保存成 WARC/WACZ。像 Playwright 這類瀏覽器自動化函式庫，提供可程式化操作頁面的能力，但捕獲與打包要你自己處理。端點探索型爬蟲是列出 URL，而抽取工具則是回傳文字或結構化記錄。這些類別可能共用同一個瀏覽器，卻是在解不同的問題。

延伸閱讀：Heritrix 評測。

揭露： Thunderbit 是本篇作者所屬產品，且未在這個 Browsertrix 測試環境中進行測試。它屬於受控抽取類別，產出的是頁面文字或結構化資料，而不是基於標準的封存檔。這篇評測只支持輸出邊界的判斷，不構成效能或能力的比較主張。

試用 Thunderbit 進行網頁資料擷取

結論

如果你需要的是 WARC/WACZ 封存，而且容器化 Chromium 符合你的部署環境，就用 Browsertrix Crawler。在這個測試環境下，封存記錄與伺服器命中對於同步的 runtime DOM 與頁面發出的 fetch 都一致，預設 prefix scope 也排除了第二個 host，而錯誤路由沒有妨礙產出有效封存。

在正式使用前，請先驗證 replay、延遲行為、登入 session、service worker、代表性頁面的儲存組成，以及授權義務。這次測試的邊界比較窄：即使包含相關字串的 script 本身被保留了，凡是從未真正執行的程式碼引用，都不會對其目標產生請求，也不會留下封存記錄。

試用 Thunderbit 進行網頁資料擷取 Get Started Free

常見問題

這裡的 WARC 和 WACZ 差在哪？ WARC 裡包含被擷取到的請求、回應與相關記錄。WACZ 則是把 WARC、索引、頁面清單、metadata 和日誌一起打包，方便分發與 replay 工具使用。本篇評測檢查了兩種封裝，但沒有實際渲染 replay。

我該怎麼估算儲存空間？ 請量代表性頁面，並把完整的 WACZ 組成納入樣本，包含日誌與索引。本文的比例來自非常小的 response body，不適合直接乘上正式 URL 數量。

它會不會亂跑到我沒指定的網站？ 依我測試，預設不會。使用 --scopeType prefix 時，對不同 host 的連結一律沒有被抓取；切換到 --scopeType any 後則抓了兩次，證明那個連結本來是可達的，也證明預設設定下的 0 次是確實的範圍控制。上游確實有一則關於其他設定下出現範圍外訪問的公開報告，但我沒有在預設設定下重現，所以還是應該檢查你自己的 scope 設定，不要自行假設。

要宣稱 replay fidelity 前，我必須先測什麼？ 把 WACZ 載入你預計使用的 replay 系統，將渲染後頁面、互動和必要子資源與線上或參考封存做比對。WARC 內有 body 是必要條件，但本身不能驗證渲染 replay 是否正確。

Browsertrix 會把封存頁面直接變成結構化資料列嗎？ 不會。它的輸出是封存套件，不是挑選後欄位的表格。如果交付物是產品、價格、聯絡資訊或其他 schema，你仍然需要在抓取後再做抽取，或改用主要輸出就是結構化資料的工具。