大多數寫「Playwright vs Puppeteer」的文章，一開始就先預設其中一個一定比較適合拿來做爬取。這種框架其實很站不住腳。我把兩個函式庫放進完全相同的一組頁面測試裡——靜態商品目錄、JavaScript 渲染的目錄、文章頁、損壞的 500 頁、小型爬行圖，以及兩個公開練習站——結果幾乎看不出差別。相同的召回率、相同的渲染結果、相同的截圖、相同的缺口。
所以這篇不是要加冕誰勝出。真正會影響你能不能用瀏覽器自動化工具抓到頁面的那些任務上，兩者都沒有誰明顯領先。接下來我會講清楚：唯一真正值得你拿來做選擇的差異、兩者都默默留給你自己補上的那一塊，以及我測試時的版本落差說明（截至 2026-07-09）。
為什麼這樣比較才算公平
比較文章常犯的一個毛病，就是拿不同頁面去測不同工具，最後再宣布勝負——但那其實更能說明頁面差異，而不是工具差異。我刻意避開這種做法，改用同一台本機 fixture 伺服器，以及相同的公開示範站 Books to Scrape 和 Quotes to Scrape，讓每個數字都能一欄對一欄地比較。
只有這樣，所謂「平手」才有意義。如果測試內容不同，那平手多半只是雜訊；當測試內容逐字節都一樣時，結果一致才足以反映工具本身的表現。
這兩個工具到底是什麼
Puppeteer 是一個用來控制 Chrome 的 JavaScript API，底層透過 Chrome DevTools Protocol 驅動。官方定位也很直接：「一個用來控制 Chrome（以及實驗性支援 Firefox）的 JavaScript API。」它成熟、以 Chrome 為中心，而且基於 Node。
Playwright 的定位則不同——它自稱是「Web 測試與自動化框架」，透過單一 API 驅動 Chromium、Firefox 和 WebKit，並提供 JavaScript、Python、Java 與 .NET 的官方客戶端。兩者其實同源（Playwright 起初來自 Google 的 Puppeteer 團隊，後來轉到 Microsoft），所以它們更像堂兄弟，而不是競爭對手。
不過，就爬取而言，它們的運作方式其實一樣：啟動真實瀏覽器、打開頁面、等腳本跑完，然後讀取渲染後的 DOM。這正是你會選擇它們，而不是 HTTP parser 的原因：你要的是 JavaScript 執行後的頁面，而不是執行前那個空殼。下面的所有結果都來自這個共同機制——也正因如此，它們很多表現才會剛好打平。
結果對照
這就是「其中一個明顯更強」這種說法悄悄破功的地方。相同測試頁、相同數字，全面一致。
| 測試 | Playwright | Puppeteer |
|---|---|---|
| 靜態商品目錄（12 個產品） | 12/12，召回率 1.0 | 12/12，召回率 1.0 |
| 文章頁（標題 + 3 段） | 3/3，已分離樣板內容 | 3/3，已分離樣板內容 |
| 動態 JS 頁面（原生渲染） | 8/8 + 截圖 | 8/8 + 截圖 |
| 動態 JSON API | 8/8，召回率 1.0 | 8/8，召回率 1.0 |
| HTTP 500 處理 | 可檢視回應，不拋例外 | 可檢視回應，不拋例外 |
| 爬行圖（手寫 BFS） | 12 個頁面，深度 {0,1,2} | 12 個頁面，深度 {0,1,2} |
| Books to Scrape | 20 個產品 | 20 個產品 |
| Quotes JS（公開站） | 10 則名言 | 10 則名言 |
兩者都能在不需要特別設定的情況下原生渲染 JavaScript。兩者都能抓取整頁截圖。兩者在遇到 500 狀態時，也都會回傳可檢查的 response 物件，而不是直接拋出例外——這件事看似小，卻很重要，因為你在大量爬取時，通常希望能記錄錯誤狀態，而不是讓整批任務中斷。
我再提醒一次這個限制，因為很容易被誤用：這些都是單機、單次觀察，不是正式 benchmark。我不是在說哪一個每頁快幾毫秒，因為在一台筆電上拿單頁碼表不算速度測試。我能主張的是更狹義、也更站得住腳的一點——在擷取召回率與渲染行為上，跨越八種不同頁型，兩者完全打平。如果你原本期待其中一個在真實頁面上拉開差距，這次並沒有。
真正該決定選擇的唯一差異
真正的分歧不在數字，而在範圍。
Playwright 透過單一 API 驅動三種引擎——Chromium、Firefox 和 WebKit——並在 JavaScript 之外，還提供 Python、Java 和 .NET 的一級官方客戶端。這是文件上明確寫出的優勢，我也想把「文件上」這件事說清楚：這次我只實際跑了 Chromium，所以我是在陳述 Playwright 的三引擎支援是官方宣稱、但我沒有親自驗證的能力，而不是我自己測出來的結果。如果你需要抓取在 Safari 的 WebKit 下表現不同的網站，或你的團隊是用 Python 開發，那這種廣度就是 Playwright 的賣點。
Puppeteer 則是以 Chrome 為優先，而且大家常用的簡化說法其實不太準。說它「只能抓 Chrome」已經不對了。自從 Puppeteer v23 起，它就透過 WebDriver BiDi 提供可上線使用的 Firefox 支援，同時在 Chrome 上預設仍走 CDP，以維持既有自動化流程不受影響——這個轉變 Chrome for Developers 和 Mozilla 都有說明。我測試的版本是 24.16.0，早已高於 v23，所以真正的差別不是「Chrome 對三引擎」，而是：Puppeteer 支援 Chrome（CDP）加 Firefox（BiDi），但不支援 WebKit，而且它的跨引擎故事比 Playwright 新。Playwright 有、Puppeteer 沒有的那個引擎，就是 WebKit。
這就是結論的精華：不是速度，不是準確度，也不是渲染保真度——這些都打平了。真正要問的是範圍：你需要 WebKit 覆蓋或非 JavaScript 語言客戶端嗎？還是只要 Node 裡的 Chrome + Firefox 就夠應付你的目標？對很大一部分爬取工作來說，兩者都夠格，你其實是在選技術棧是否合適，而不是在選誰能力比較強。
兩者都沒做的那件事
兩個工具都把同一項工作留給你：爬行流程控管。它們都沒有內建請求佇列、資料集寫入器或自動限速。我的爬行圖測試——追蹤內部連結、記錄深度、不重複拜訪同一個 URL——不管用哪一個，都得自己手寫 breadth-first search。12 個頁面、深度 {0,1,2}，兩次都靠我自己寫 BFS。
如果只處理幾個頁面，這完全沒問題；簡單的 BFS 也不過十幾行。可是一旦要大規模爬取——幾百或幾千個 URL，還要去重、重試與禮貌性延遲——你不是得自己搭這套機制，就是要找一個已經把這些能力包起來的工具。Crawlee 就是這類工具，它在 Playwright 和 Puppeteer 之上提供真正的爬行層。
這不是缺陷，我想把責任歸因說正確：Playwright 和 Puppeteer 是瀏覽器自動化框架，不是爬蟲框架。缺少佇列不是 bug，而是範圍邊界。正確的心智模型是：這兩個工具是爬蟲裡「看得到頁面」的那一半；你還得自己帶上「走訪網站」的那一半——自己寫，或接上一個已經內建這功能的 wrapper。
安裝方式與版本說明
安裝體驗幾乎一樣。npm install 會把函式庫和瀏覽器二進位檔一起拉下來，而真正佔重量的是瀏覽器本體——Puppeteer 會自動打包下載 Chrome（我這次是乾淨安裝，沒有回報任何漏洞），Playwright 則需要另外跑 npx playwright install 來安裝瀏覽器版本。兩者安裝都不痛苦，但你都要把下載時間算進去；真正付出的代價是瀏覽器重量和每頁成本，這也是相對於純 HTTP 工具所要付出的渲染稅。
接著說明我該交代的版本差異。我測的是 Playwright 1.56.0，對上最新的 1.61.1；Puppeteer 24.16.0，對上 npm latest 的 25.3.0——截至 2026-07-09，Puppeteer 整整落後一個 major version。因為我測試的 API 在這些版本差距中仍屬穩定，所以結果依然成立。但如果你是在文章發表一段時間後才讀到這裡，建議先用當前版本重跑，再決定是否要押注這些精確數字。再說一次：我只在 Playwright 上實測 Chromium，所以我不會對它的 Firefox 或 WebKit 等同性做超出「文件有寫」以外的主張。
Playwright 和 Puppeteer：優缺點整理
既然是平手，優缺點整理就不是在比誰贏，而是在看你各自要承擔什麼。
Playwright
- 優點：透過單一 API 提供官方文件化的三引擎支援（Chromium、Firefox、WebKit）；官方支援 Python、Java、 .NET 客戶端；原生 JavaScript 渲染可達完整召回率；持續擴展中。
- 缺點：沒有內建爬行佇列；瀏覽器重量與每頁成本；這次只實測 Chromium；我跑的版本落後最新 release。
Puppeteer
- 優點：成熟穩定的 Chrome 自動化，透過 CDP 運作；原生 JavaScript 渲染可達完整召回率；500 狀態處理乾淨（回傳 response 物件，不拋例外）；生態系深厚且實戰經驗多；自 v23 起官方文件化支援 Firefox 的 WebDriver BiDi。
- 缺點：以 Chrome 為優先、基於 Node，不支援 WebKit 引擎；沒有內建爬行佇列；有瀏覽器重量；我測試的版本比 npm latest 落後一個 major version。
誰該選哪一個
如果你平常就在 Node 裡工作，目標網站用 Chrome 渲染就沒問題（大多數都可以），而且你想要一個成熟、專注、社群生態深厚、需要思考的面向也少一點的函式庫，那就選 Puppeteer。等你之後真的需要時，再往 Firefox 的 BiDi 能力擴展就好。
如果你需要 WebKit 覆蓋、想用 Python 或 .NET 寫爬蟲，或是想押注在引擎與語言覆蓋面更廣的專案，那就選 Playwright。單是語言相容性這一點，往往就足以讓 Python 團隊毫不猶豫地選它。
還有一個比較文章常跳過的答案：如果你的頁面其實不需要 JavaScript 來載入資料，那就兩個都別選。只要 HTTP 請求加 parser 就拿得到內容，headless browser 反而是昂貴的過度設計——那屬於另一種工具類別，硬用真實瀏覽器只是在白白消耗記憶體和設定時間。
托管 API 的位置：也包含 Thunderbit
Playwright 和 Puppeteer 都是免費、開源，而且需要你自己安裝與維護的函式庫。瀏覽器環境、更新、你自己加上的爬行程式碼，以及反機器人攻防，全部都要你負責。對很多專案來說，這種掌控權正是最合理的做法，這裡也完全不是在反對它。
但仔細想想，真正的爬取工作有多少其實不在這兩個工具本身？它們確實能把頁面渲染好；但它們不會幫你排 URL、不會幫你處理封鎖輪替、不會直接給你結構化 JSON，也不會替你維持整個瀏覽器叢集。這已經是技術棧的另一層了，對正在評估 build versus buy 的開發者來說，值得直接講清楚。Thunderbit 自家的開發者技術棧就位在另一層：POST /distill 可以把頁面轉成乾淨、適合 LLM 使用的 Markdown，而 POST /extract 則能依照你定義的 schema 回傳結構化 JSON，JavaScript 渲染、反機器人處理與 CAPTCHA 都由伺服器端接手，不必在你的筆電上處理。我們也提供給 AI agent 與 coding assistant 使用的 Thunderbit MCP server（其中 thunderbit_suggest_fields 在你花任何費用前可先免費跑），以及可透過 npx @thunderbit/thunderbit-cli 使用的 CLI，方便接到 CI 和 cron。
我不會假裝這一定比較好——這只是不同形狀的取捨。用 Playwright 或 Puppeteer，你要自己掌控渲染，並把周邊全都自己搭起來，單次呼叫成本為零。用托管 API，你把渲染、反機器人與爬行管線外包出去，按請求付費（以 Thunderbit 來說是按次計費——distill 一個 credit、extract 二十個 credit，而不是按列數計費）。如果你規模小、想自架、又喜歡自己掌控瀏覽器，這些函式庫就是對的工具；如果你要擴大規模，又不想同時維運無頭瀏覽器叢集、爬蟲與封鎖輪替層，那托管方案就能直接移除這一整類工作。
至於更廣泛的領域，我們團隊也測過 Crawlee 的雙引擎方案 以及幾個以 HTTP 為主的框架，並用同一組 fixture 比較過；如果你已經判斷不需要完整瀏覽器，那就是下一個值得看的方向。
結論
Playwright 和 Puppeteer 該選哪個？如果是要渲染 JavaScript 頁面，兩個都可以——在這裡所有重要測試都打平，所以你不需要為了能力折損而做選擇。若你從 Node 出發，Chrome + Firefox 的組合就夠了，而且你重視成熟度與專注度，那選 Puppeteer。若你需要 WebKit 範圍，或需要非 JavaScript 客戶端，那選 Playwright。
比較文章常忽略的兩件事，其實更值得帶走：第一，在真實爬取任務上，這兩者真的平手，所以別為了一個根本沒出現的效能差距糾結太久。第二，兩者都不是爬蟲——它們負責渲染，而爬行要靠你自己，或靠像 Crawlee 這樣的 wrapper。把這兩點搞清楚，讓需求對上技術棧，選擇就會變得很小。引擎選擇的重要性，遠小於這兩個工具都沒替你做的那一半工作。
延伸閱讀
試試 Thunderbit 進行網頁資料擷取 Get Started Free
常見問題
Playwright 和 Puppeteer 哪個更快，適合網頁爬取？ 在相同測試頁上，兩者幾乎打成平手——靜態頁（12/12）、動態頁（8/8）與 JSON API 擷取的召回率都一樣，原生渲染表現也一致，500 錯誤的處理方式也相同。這些都是單次、單機觀察，不是正式 benchmark，所以每頁時間差不算真正的速度測量。選擇時應看範圍與語言支援，不要因為不存在的速度差距而糾結。
Playwright 和 Puppeteer 的實際差別是什麼？ 差在引擎與語言支援範圍。Playwright 透過單一 API 驅動 Chromium、Firefox 和 WebKit，並提供 Python、Java、.NET 客戶端。Puppeteer 則以 Chrome 為主，透過 CDP 運作，自 v23 起也有官方文件化的 Firefox WebDriver BiDi 支援，但沒有 WebKit，而且是 Node-based。兩者都能原生渲染 JavaScript，但都沒有內建爬行流程控管。
我可以直接用 Playwright 或 Puppeteer 爬完整個網站嗎？ 不能直接做到。兩者都沒有請求佇列、資料集寫入器或自動限速——我的爬行圖測試在兩邊都需要手寫 BFS，12 個頁面、深度 {0,1,2}。如果要擴大規模，請再加一層爬行框架，例如 Crawlee，它能把兩個引擎包成真正的爬行機制。
做爬取一定要用瀏覽器工具嗎？ 只有在頁面需要 JavaScript 才能把資料顯示出來時才需要。如果 HTTP 請求加 parser 就能拿到你要的內容，那 headless browser 其實太重了——這種情況直接用以 HTTP 為先的工具即可，完全不必承擔瀏覽器的重量。
Python 團隊應該選哪一個？ Playwright，因為它有一級官方 Python 客戶端。Puppeteer 是 Node-based，如果要在 Python 中使用，就得自己搭橋並維護那層整合。對很多團隊來說，這個語言相容性本身就是選 Playwright 而不是 Puppeteer 的最直接理由之一。
