很多人优化 Playwright 爬虫，第一反应是：
-
开更多进程
-
上 PM2 cluster
-
调线程、调并发
结果往往是：越开越慢、越开越抖、超时越来越多。
如果你也遇到过这种情况，我建议你先别改代码，先做一件事：
把带宽看清楚。****
因为 Playwright 的流量不是“持续型”，而是瞬时爆发型（burst） 。
而 burst，才是你爬虫抖动、超时、并发变慢的根源。
1. Playwright 的流量为什么是“瞬时爆发型”？
Playwright 的核心动作是 page.goto(url)。
但它不是“请求一个页面”这么简单，而是触发浏览器加载一整个网页生态：
-
HTML
-
CSS / JS
-
图片 / 字体 / icon
-
接口请求（XHR / fetch）
-
统计脚本 / 埋点 / 广告
-
iframe / 子资源 / CDN
这些资源会在很短的时间里并发发起请求，所以带宽呈现出的形态往往是：
0 → 瞬间拉满 → 降下来 → 再瞬间拉满****
它更像“秒杀抢购”式的爆发，而不是稳定下载。
2. 为什么 burst 会让爬虫变慢、变不稳定？
你真正遇到的问题通常不是“代码慢”，而是 burst 带来的系统级问题。
2.1 带宽瞬间触顶，导致请求排队
当 burst 把带宽打满时，所有连接都会变慢：
-
关键接口响应变慢
-
页面资源加载变慢
-
goto 时间被拉长
-
更容易触发 timeout
2.2 多实例 burst 叠加，直接变成抖动（jitter）
你开一个 Playwright 还好。
你开多个 Playwright，它们会同时 burst：
-
多个 Chromium 抢带宽
-
多个请求高峰叠在一起
-
系统出现明显抖动
结果就是：
-
爬虫吞吐反而下降
-
超时和失败率上升
-
稳定性变差
2.3 “不重要的资源”抢走了带宽
很多站点的图片、字体、统计脚本会非常重。
一旦它们占掉带宽，你真正需要的数据接口反而慢了。
所以优化 Playwright 的第一步，不是开更多进程，而是：
找出谁在抢你的带宽。****
3. 实时看带宽总趋势：nload
如果你想先确认：带宽是不是触顶了，用 nload 就够了。
安装并运行：
sudo apt install -y nload
nload
你在 nload 里重点看两件事：
-
带宽是否长期接近上限（例如 4M、10M、100M）
-
每次 goto 是否都会出现明显尖峰
如果你看到：
-
一打开 Playwright，流量就经常拉满
-
并发越高，尖峰越密集
那么可以直接下结论：
你的瓶颈不是 CPU，也不是 Node，而是带宽。
4. 看 burst + 找出“谁在抢带宽”：iftop（更适合 Playwright）
nload 只能告诉你“带宽有没有满”。
但它解决不了一个关键问题：
到底是谁把带宽抢走了？****
这时候就需要 iftop。
安装并运行（以 eth0 为例）：
sudo apt install -y iftop
sudo iftop -i eth0
你会看到每一个连接的实时带宽占用，以及 1s / 10s / 40s 的平均值。
这对 Playwright 特别有用，因为 Playwright 的流量是 burst：
-
你能看到每次 burst 的峰值
-
你能看到哪个 host 在短时间里抢占了大部分带宽
-
你能看到多实例并发时 burst 是否叠加
在 iftop 里，你重点看这几类连接：
-
图片域名（img / static / cdn）
-
字体域名（fonts / fontcdn）
-
analytics / tracking
-
视频 / 广告相关资源
很多时候你会发现：
真正抢走带宽的根本不是你要的数据接口，而是这些“无关资源”。
5. 找到“抢带宽的资源”之后，怎么优化？
Playwright 性能优化最值钱的一步就是：
最大限度削减网络负载。****
最常见、最有效、最应该做的优化是：
直接 abort 掉图片 / 字体 / 视频资源。
await page.route("**/*", (route) => {
const type = route.request().resourceType();
if (["image", "media", "font"].includes(type)) {
return route.abort();
}
route.continue();
});
这段代码的价值非常直接：
- 页面请求量明显下降
- 带宽峰值下降
- burst 抖动减少
- goto 速度提升
- 超时和失败率下降
- 并发更稳定
6. 用 nload + iftop 验证优化是否有效
优化 Playwright，最怕的是“感觉快了”，但其实只是偶然。
正确的验证方式是：
6.1 优化前
-
用 nload 看是否触顶
-
用 iftop 看 burst 峰值是谁造成的
6.2 加 abort 后
-
nload 的尖峰明显变小
-
iftop 里大流量连接减少
-
关键接口连接占比上升
6.3 再看结果
- timeout 是否下降
- 失败率是否下降
- 并发是否更稳
END：nload 让你看到“是否触顶”，iftop 让你看到“谁在抢”
如果你的 Playwright 爬虫：
-
越开越慢
-
并发一高就抖
-
经常 timeout
-
CPU 并不高
不要第一时间怀疑代码和框架。
先把带宽看清楚。
nload 负责告诉你：带宽是否触顶
iftop 负责告诉你：是谁把带宽抢走
Playwright 的性能优化，首先是网络优化，其次才是并发策略。
