乐闻世界logo
5月28日 07:18

Puppeteer 性能优化有哪些核心策略？

Puppeteer 在爬虫和自动化测试场景下，性能瓶颈主要来自 Chromium 的资源消耗——每次启动一个浏览器实例就要占 50-100MB 内存，每个 Page 再加 30-80MB，而页面加载时的网络 I/O 和 DOM 渲染又是时间上的最大开销。理解哪些环节最耗资源，才能对症下药。核心优化方向有三个：减少浏览器开销、降低页面加载成本、合理管理并发与内存。

浏览器启动与实例管理

每次 puppeteer.launch() 都会启动一个完整的 Chromium 进程，开销约 50-100MB 内存。批量任务中复用浏览器实例是最基本也最有效的优化：

javascript
const browser = await puppeteer.launch({
  headless: 'new',
  args: [
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--disable-dev-shm-usage',
    '--disable-accelerated-2d-canvas',
    '--disable-gpu',
    '--window-size=1920,1080'
  ]
});

// 复用同一个 browser，每次任务只开新 page
for (const url of urls) {
  const page = await browser.newPage();
  await page.goto(url);
  // ... 执行任务
  await page.close();
}
await browser.close();

启动参数中几个关键项的作用：

  • headless: 'new' — 使用 Chrome 的新版 Headless 模式，比旧版 headless 快约 20-30%，因为它不再走单独的渲染路径，而是和有头模式共享同一套代码
  • --disable-dev-shm-usage — 在 Docker 等共享内存受限的环境中必不可少，否则 Chromium 会因 /dev/shm 空间不足而崩溃，改用 /tmp 目录
  • --no-sandbox — 在容器内运行时需要关闭沙盒，因为容器通常没有足够的权限创建命名空间
  • --disable-gpu — 无头模式下不需要 GPU 加速，关闭后可减少一个 GPU 进程的内存开销

对于长时间运行的任务，Chromium 存在内存泄漏倾向，运行上千次后内存占用可能翻倍。建议定期重启浏览器实例：

javascript
let browser;
let taskCount = 0;
const RESTART_THRESHOLD = 500;

async function getBrowser() {
  if (!browser || taskCount >= RESTART_THRESHOLD) {
    if (browser) await browser.close();
    browser = await puppeteer.launch({
      headless: 'new',
      args: ['--no-sandbox', '--disable-dev-shm-usage']
    });
    taskCount = 0;
  }
  taskCount++;
  return browser;
}

重启阈值需要根据实际内存监控数据调整。一个实用的监控方式是在每次任务后检查进程内存：

javascript
const used = process.memoryUsage();
if (used.rss > 1024 * 1024 * 1024) { // 超过 1GB
  await browser.close();
  browser = await puppeteer.launch({ headless: 'new', args: ['--no-sandbox'] });
}

页面加载策略

页面加载是时间消耗最大的环节。默认的 waitUntil: 'load' 会等待所有资源（图片、CSS、字体、JS）加载完成，对爬虫来说往往不必要。

javascript
// 爬虫场景：DOM 就绪即可开始提取数据
await page.goto(url, { waitUntil: 'domcontentloaded' });

// 需要 JS 渲染完成后提取动态内容
await page.goto(url, { waitUntil: 'networkidle2' });

// 需要确保所有异步请求都完成（如懒加载图片）
await page.goto(url, { waitUntil: 'networkidle0' });

四种策略的耗时对比：domcontentloaded 比 load 快 2-5 倍，比 networkidle0 快 5-10 倍，具体差距取决于页面资源量。选择策略时遵循一个原则：能用 domcontentloaded 就不用 load，能用 networkidle2 就不用 networkidle0。

还有一种更精细的做法：先用 domcontentloaded 完成初始加载，再手动 waitForSelector 等待关键元素出现：

javascript
await page.goto(url, { waitUntil: 'domcontentloaded' });
await page.waitForSelector('.data-table', { timeout: 5000 });
// 比直接用 networkidle0 更精准，不会浪费时间等无关请求

拦截不必要的网络请求可以进一步降低加载时间和内存占用：

javascript
await page.setRequestInterception(true);
page.on('request', (request) => {
  const blocked = ['image', 'font', 'media', 'stylesheet'];
  if (blocked.includes(request.resourceType())) {
    request.abort();
  } else {
    request.continue();
  }
});

这个优化在抓取纯文本数据的场景下效果显著——页面加载速度可提升 50% 以上，内存占用降低 30-40%。但如果需要截屏或分析页面视觉布局，图片和样式表不能拦截，需根据场景灵活调整拦截列表。

设置合理的超时时间同样重要，避免因个别慢页面拖垮整体效率：

javascript
await page.goto(url, {
  waitUntil: 'domcontentloaded',
  timeout: 15000 // 15 秒超时，不给慢页面无限等待
});

并发控制与连接池

Promise.all 可以并行处理多个页面，但无限制的并发会导致内存飙升和 CPU 争抢，甚至触发系统 OOM Killer。实际生产中必须控制并发数：

javascript
async function processWithConcurrency(urls, concurrency = 3) {
  const browser = await puppeteer.launch({ headless: 'new' });
  const results = [];

  for (let i = 0; i < urls.length; i += concurrency) {
    const batch = urls.slice(i, i + concurrency);
    const batchResults = await Promise.all(
      batch.map(async (url) => {
        const page = await browser.newPage();
        try {
          await page.goto(url, { waitUntil: 'domcontentloaded' });
          return await page.evaluate(() => document.body.innerText);
        } finally {
          await page.close();
        }
      })
    );
    results.push(...batchResults);
  }

  await browser.close();
  return results;
}

并发数的选择取决于机器配置：每打开一个 Page 大约需要 30-80MB 内存。一台 4GB 内存的机器，并发 5-10 个 Page 就接近极限。8GB 内存可以开 10-20 个并发，但还要考虑 CPU 核心数——Chromium 每个渲染进程都会占一个核心，并发数超过核心数时进程切换开销会抵消并发收益。

更推荐的做法是使用 puppeteer-cluster 库，它内置了并发控制、自动重试和错误处理：

javascript
const { Cluster } = require('puppeteer-cluster');

const cluster = await Cluster.launch({
  concurrency: Cluster.CONCURRENCY_CONTEXT,
  maxConcurrency: 5,
  puppeteerOptions: { headless: 'new' }
});

await cluster.task(async ({ page, data: url }) => {
  await page.goto(url, { waitUntil: 'domcontentloaded' });
  const data = await page.evaluate(() => document.body.innerText);
  return data;
});

urls.forEach(url => cluster.queue(url));
await cluster.idle();
await cluster.close();

puppeteer-cluster 的 CONCURRENCY_CONTEXT 模式使用 BrowserContext 而非新 Page 来隔离任务。Context 的创建和销毁比 Page 更轻量，且不会共享 Cookie 和存储——这对爬虫场景很关键，避免不同任务的登录态互相干扰。如果需要更强的隔离（不同 User-Agent、不同代理），可以用 CONCURRENCY_BROWSER 模式，每个任务一个独立的浏览器实例，代价是内存开销更大。

对于更大规模的爬虫系统，可以实现一个浏览器连接池：

javascript
class BrowserPool {
  constructor(maxSize = 3) {
    this.maxSize = maxSize;
    this.browsers = [];
    this.queue = [];
  }

  async init() {
    for (let i = 0; i < this.maxSize; i++) {
      this.browsers.push(await puppeteer.launch({
        headless: 'new',
        args: ['--no-sandbox', '--disable-dev-shm-usage']
      }));
    }
  }

  async acquire() {
    if (this.browsers.length > 0) {
      return this.browsers.pop();
    }
    return new Promise(resolve => this.queue.push(resolve));
  }

  release(browser) {
    if (this.queue.length > 0) {
      this.queue.shift()(browser);
    } else {
      this.browsers.push(browser);
    }
  }

  async closeAll() {
    await Promise.all(this.browsers.map(b => b.close()));
  }
}

内存泄漏防治

内存泄漏是 Puppeteer 长时间运行的最大敌人。常见的泄漏源有三类：未关闭的 Page、未关闭的 BrowserContext、事件监听器未移除。

务必在 finally 块中关闭资源：

javascript
async function safeScrape(url) {
  const page = await browser.newPage();
  try {
    await page.goto(url);
    return await page.evaluate(() => document.title);
  } finally {
    await page.close(); // 无论成功还是异常，都关闭 page
  }
}

使用 BrowserContext 隔离任务：

javascript
const context = await browser.createIncognitoBrowserContext();
const page = await context.newPage();
try {
  await page.goto(url);
  // ... 执行任务
} finally {
  await context.close(); // 关闭 context 会同时关闭所有属于它的 page
}

context.close() 比 page.close() 更彻底，它会清理该上下文下的所有页面、Cookie、LocalStorage 和缓存，防止跨任务数据污染。特别是当一个任务的 Cookie 会影响另一个任务的结果时（比如不同账号登录态），Context 隔离是必须的。

通过 CDP 定期清理浏览器数据：

javascript
const client = await page.target().createCDPSession();
await client.send('Network.clearBrowserCache');
await client.send('Network.clearBrowserCookies');

相比 Puppeteer 的 page.deleteCookie() 和 page.evaluate(() => localStorage.clear())，CDP 方式更高效——一条命令就能清空所有缓存和 Cookie，而不需要逐个删除。

移除不再需要的事件监听器：

javascript
const handler = (request) => { /* ... */ };
page.on('request', handler);
// 任务完成后移除
page.off('request', handler);

未移除的监听器会持有对 page 对象的引用，阻止垃圾回收，是隐蔽但常见的泄漏源。

选择器与执行效率

Puppeteer 的 Node.js 进程和 Chromium 进程是分离的，page.$()、page.evaluate() 之间的每次调用都需要跨进程通信（IPC），涉及数据的序列化和反序列化。减少 IPC 调用次数是提升执行速度的关键：

javascript
// 低效：3 次 IPC 调用
const title = await page.$eval('.title', el => el.textContent);
const price = await page.$eval('.price', el => el.textContent);
const desc = await page.$eval('.desc', el => el.textContent);

// 高效：1 次 IPC 调用完成所有提取
const data = await page.evaluate(() => ({
  title: document.querySelector('.title')?.textContent,
  price: document.querySelector('.price')?.textContent,
  desc: document.querySelector('.desc')?.textContent
}));

一次性提取所有数据比多次 $eval 快 3-5 倍，因为只产生一次 IPC 开销。这条规则在实际优化中经常被忽略，但对高频调用场景影响显著。

另一个常见的低效模式是反复查询同一个元素：

javascript
// 低效：每次都重新查找 DOM
for (let i = 0; i < 10; i++) {
  const text = await page.$eval('.item', (el, i) => el.children[i].textContent, i);
}

// 高效：一次提取所有子元素文本
const texts = await page.evaluate(() =>
  Array.from(document.querySelectorAll('.item')).map(el => el.textContent)
);

选择器本身的效率也有差异：ID 选择器 > Class 选择器 > 标签选择器。但在爬虫场景下，选择器通常由目标页面的 DOM 结构决定，优化空间有限。真正值得投入精力的是减少 IPC 调用次数。

CDP 进阶：性能监控与分析

CDP（Chrome DevTools Protocol）是 Puppeteer 的底层协议，通过 createCDPSession() 可以访问比 Puppeteer API 更底层的功能，获取更详细的性能数据：

javascript
const client = await page.target().createCDPSession();

// 获取页面性能指标
await client.send('Performance.enable');
const { metrics } = await client.send('Performance.getMetrics');
// 关键指标：
// - JSHeapUsedSize：JS 堆已使用大小
// - Nodes：DOM 节点数量（过多说明可能有泄漏）
// - LayoutCount：布局重排次数（过多说明 DOM 操作低效）

Performance.getMetrics 返回的指标可以帮助判断瓶颈在哪：JSHeapUsedSize 持续增长说明有内存泄漏，Nodes 过多说明 DOM 操作需要优化，LayoutCount 高说明频繁触发了重排。

性能追踪：

javascript
await page.tracing.start({ path: 'trace.json' });
await page.goto(url);
await page.tracing.stop();
// 用 chrome://tracing 打开 trace.json 进行可视化分析

生成的 trace.json 可以在 Chrome 的 chrome://tracing 页面加载，直观看到每个阶段的耗时分布——脚本执行、布局计算、绘制、网络请求各占多少时间。这在定位"页面加载慢到底是卡在哪里"时非常有效。

网络监控：

javascript
await client.send('Network.enable');
client.on('Network.responseReceived', ({ response }) => {
  if (response.status >= 400) {
    console.log(`请求失败: ${response.url} - ${response.status}`);
  }
});

通过 CDP 监听网络事件，可以记录所有请求的状态码和耗时，帮助发现哪些第三方请求拖慢了页面，或者哪些接口返回了错误。

反检测与稳定性

频繁请求同一站点会触发反爬机制，导致性能骤降（验证码、封 IP、返回空白页）。虽然这不算传统意义上的"性能优化"，但反爬触发后带来的重试和超时会严重影响整体效率。几个基本措施：

隐藏 WebDriver 特征：

javascript
await page.evaluateOnNewDocument(() => {
  Object.defineProperty(navigator, 'webdriver', { get: () => false });
  // 修复 permissions.query 在 headless 中的异常
  const originalQuery = window.navigator.permissions.query;
  window.navigator.permissions.query = (parameters) =>
    parameters.name === 'notifications'
      ? Promise.resolve({ state: Notification.permission })
      : originalQuery(parameters);
});

evaluateOnNewDocument 在页面脚本执行前注入，确保页面检测时 navigator.webdriver 已经是 false。

随机化操作间隔：

javascript
const delay = Math.floor(Math.random() * 1000) + 500; // 500-1500ms 随机延迟
await new Promise(resolve => setTimeout(resolve, delay));
await page.click('.next-page');

匀速访问是最明显的机器特征。加入随机延迟后，请求模式更接近真实用户，降低被风控系统标记的概率。

设置合理的 User-Agent：

javascript
await page.setUserAgent(
  'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36'
);

默认的 User-Agent 包含 "HeadlessChrome"，是反爬系统最容易识别的特征之一。替换为真实浏览器的 UA 是最基本的反检测措施。

这些措施不能绕过所有检测（比如基于 TLS 指纹的检测），但能显著降低被初级反爬系统识别的概率，避免因触发反爬导致的重试和超时，间接提升整体效率。

核心优化优先级

按照投入产出比排序，从高到低：

  1. 复用浏览器实例 — 改动最小，收益最大，避免每次任务都启动 Chromium 进程
  2. 选择合适的 waitUntil — 一行代码的改动，可能节省数秒等待时间
  3. 拦截无用资源 — 爬虫场景下效果最显著，加载速度和内存双赢
  4. 控制并发数 — 防止资源耗尽导致整体性能下降甚至系统崩溃
  5. finally 中关闭 Page/Context — 防止内存泄漏，保证长时间运行稳定
  6. 合并 evaluate 调用 — 减少 IPC 开销，高频场景下效果明显
  7. 定期重启浏览器 — 兜底策略，解决 Chromium 自身的内存泄漏问题

面试中回答这个问题的关键不是罗列所有策略，而是说清楚每个优化解决了什么瓶颈，以及不同场景下的取舍——比如拦截资源在纯数据抓取中合适，但截屏场景下不行；domcontentloaded 快但可能拿不到 JS 渲染后的内容；并发数不是越多越好，要结合内存和 CPU 核心数综合考量。

标签：Puppeteer