Playwright BiDi 大小報告：避免代理頻寬指標把回應標頭計入正文
一項於 2026 年 9 月 12 日提交的 Playwright 開放問題指出，Chrome 透過實驗性 BiDi 後端執行時，request().sizes() 可能高估 responseBodySize。重現中的正文是 2,000 位元組，BiDi 結果為 2,151 位元組；多出的 151 位元組與對照執行的回應標頭大小相符。
這是尚未關閉的問題報告，不代表已確認的普遍正式環境缺陷，也不表示代理本身出錯。它提醒代理採購及資料團隊：不同瀏覽器網路後端可能賦予遙測欄位不同語意，不能把單一自動化指標直接視為頻寬真值。
內部研究來源：Microsoft Playwright 問題「bidi reports transfer size as responseBodySize, so request().sizes() over-reports the body by the header size」，提交日期 2026 年 9 月 12 日。
報告顯示什麼
報告使用固定 2,000 位元組回應。CDP 路徑記錄 2,000 位元組正文，而 BiDi Chrome 專案記錄 2,151 位元組；壓縮及分塊回應也有相似偏高。報告推測同一協定值同時供應傳輸大小與編碼正文大小，但兩者在 Playwright 內應分開。
BiDi 後端仍屬實驗性，問題亦維持開放。實際影響必須在團隊自己的 Playwright 版本、瀏覽器通道和代理設定中重現。
為何影響代理決策
代理試用常以每 MB 成本、每個成功頁面位元組、壓縮節省或流量異常評分。若名為正文大小的欄位混入回應標頭，小型 API 回應受到的比例偏差更大。路由之間 Cookie、快取標頭或診斷標頭不同，也可能造成錯誤的效率差異。
建立確定性回歸測試
在自有或獲准夾具傳回 0、100、2,000 與 100,000 位元組的固定正文。先使用穩定標頭，再只增加一個已知長度的大型回應標頭。分別測試 identity、gzip 與分塊傳輸。
記錄 Playwright 版本、瀏覽器通道、網路後端、代理路由別名、狀態、宣告長度、解碼正文、編碼正文、回應標頭、報告正文大小、報告傳輸大小及正文摘要。不得記錄代理密碼、Cookie、授權值或私有負載。
對照四層證據
第一層是夾具已知長度和摘要；第二層是實際讀取正文位元組；第三層是自動化框架報告值；第四層是在獲准條件下取得的網路或來源端計數。
保持夾具相同，分別執行直連、代理、CDP 與 BiDi。隨後端改變的差異不能直接歸因於代理；隨路由改變的差異則需繼續拆分標頭、壓縮、快取及內容表示。
使用回應標頭增量挑戰
兩次傳回完全相同正文，第二次只增加已知長度標頭。若正文摘要和實際位元組不變，而 responseBodySize 按標頭長度增加，就證明指標混合了不同層。
應在多個負載大小重複，以量化小型物件成本模型的偏差。
清楚區分三種大小
- 解碼正文：內容解碼後應用取得的位元組；
- 編碼正文：壓縮表示的位元組；
- 傳輸總量：編碼正文、標頭及測量來源定義的協定開銷。
儀表板必須標示層級。代理帳單以供應商公開計費定義為準，再使用固定夾具和獨立計數核對。
上線檢查清單
- 每條結果固定 Playwright 版本、瀏覽器通道及後端；
- 使用多種已知正文長度；
- 只改變標頭並測量增量；
- 驗證適用的解碼與編碼摘要；
- 分開直連和代理；
- 不合併 CDP 與 BiDi 數值；
- 正文、標頭及傳輸總量分欄位；
- 從 trace 移除憑據和私隱資料；
- 升級後重新執行；
- 依已驗證完成結果作採購判斷。
常見問題
BiDi 一定會高估代理流量嗎？
不一定。報告針對特定 Playwright next 版本和實驗後端，必須在實際環境重現。
多出的位元組是代理加入嗎？
不一定。報告把差異指向遙測映射，只有直連及代理對照才能隔離路由影響。
代理成本應使用哪個數字？
使用供應商定義的計費層，並以已知負載核對；同時保留解碼正文、編碼正文和總傳輸三個欄位。
相關 98IP 指南
使用代理頻寬成本估算建立計費模型，並結合gzip 與 Brotli 完整性測試及Playwright keep-alive 問題報告。
合規說明
只在自有或明確授權系統測量流量，遵守速率限制、私隱承諾與平台規則。必須清除 trace 中的秘密資料，不得利用代理測試規避存取控制。
