最近在網絡上看到一篇文章：puppeteer vs selenium vs playwright, a speed comparison，作者是 Checkly 團隊, 他們對 puppeteer、playwright 和 selenium 的執行速度做了量化的比較，得出的結論是 puppeteer 和 playwright 比 selenium 快了大概 20% 左右，有興趣的同學可以看看。
受此啓發，我對 playwright 和 playwright-python 也做了同樣的測試。playwright 是微軟開源的瀏覽器自動化操作的 node.js 庫，playwright-python 是它對應的官方 python 版本。
測試方法
如果你想直接瞭解測試結果，請跳過這一節。不過我仍然建議你繼續閱讀，以便於更好的理解測試結果的確切含義。
基本條件
爲了使測試對象儘可能的在相似的環境中運行，我們約定了以下基本條件：
- 資源平等：每個測試都是在同一臺“靜止的”機器上依次執行的，也就是說，在測試期間，後臺沒有發生繁重的工作負載。
- 簡單執行：腳本的執行方式如每個工具的“入門”文檔所示。例如：playwright 的
node script.js，並且儘量使用默認的命令行選項。 - 相似的腳本：儘量減小測試中不同工具之間編寫腳本的差異。
- 最新版本：測試對象都使用目前爲止發佈的最新版本。
- 相同的瀏覽器：所有的腳本都在無頭模式的 Chromium 瀏覽器上執行。
所有條件的細節，請參閱下一節。
測試參數
每個測試腳本都成功的連續執行1000次。
測試對象的版本信息如下：
- playwright：1.8.0
- playwright-python：1.8.0a1
衡量指標
對每個測試都衡量以下幾個指標，它們都是從這1000次的執行結果中計算出來的：
- 平均執行時間（秒）
- 標準差（秒）：方差的算術平方根，反應執行時間的離散程度。
- 相對標準偏差：標準差除以平均值再乘以100%，反應執行時間相對於平均值的波動程度。
- P95：丟棄最慢的5%的數據，剩下的耗時最長的結果，反應非極端情況下仍然較長的執行時間。
尚未衡量的指標
- 可靠性：不可靠的腳本即使執行的再快也是毫無意義的。
- 並行執行：對自動化工具而言，並行執行是一個很重要的概念。但是，本次測試首要關注的是單個腳本的執行速度。
- 非本地執行：和並行化一樣，腳本的遠程執行也是一個重要的話題，但同樣不在本文的討論範圍之內。
- 資源耗用：執行測試耗用的內存和 CPU 計算同樣未予考慮。
測試結果
爲了避免網絡延遲帶來的影響，腳本操作的是我之前在本地的樹莓派上搭建的 pihole 服務。
簡單的場景
在這個場景中，腳本執行一個 pi-hole 的快速登錄操作，預計只需要幾秒鐘，這可以明顯的區分出測試對象啓動速度之間的差異。
以下是我們的彙總測試結果：
在這種場景下，playwright 比 playwright-python 的速度快了20%以上，但是 playwright-python 擁有更低的離散度和變異性。
複雜的場景
在這個場景中，我們登錄 pihole 添加一個黑名單和白名單，然後再刪除它們。我們來看看在這種稍微複雜的場景中，是否還能得到上面的結論。
以下是我們的彙總測試結果：
這裏 playwright 相對於 playwright-python 的速度優勢降到了10%左右，但同時它們的離散度和差異性趨於重合。
結論
playwright 確實相對於 playwright-python 有執行速度上的優勢，在一些腳本操作簡單，執行時間短的場景中有20%以上的優勢，但是對於一些複雜的、執行時間較長的場景，優勢大概在10%左右。
其實，不管是對於 playwright、puppeteer 還是 selenium，速度永遠都不是在選擇工具時的第一考慮要素，更要考慮到自身的需求、腳本開發的效率等等。
以上結論僅供參考。
其它
本文所有的測試腳本、測試結果都可以在這個倉庫中找到，包括自動計算結果，並生成本文所有表格、圖片的一個腳本，在寫這個腳本的時候，還發現了 rich 的一個 BUG，也算是一個意外的收穫吧。
rich 是一個 python 庫，能夠在終端打印漂亮的輸出，Github 上超過2萬 star，有興趣的可以試試。