规模化 SERP 抓取：浏览器要求

SERP 抓取的规模化处理是一项负载规划问题：浏览器必须在启动、渲染或内存不成为隐藏瓶颈的前提下，维持要求的每小时页面数目标。该测量计划使用自有 fixture 或明确获授权的目标/API，不提供实时 SERP 采集说明。BotBrowser 提供可配置的浏览器运行时用于受控比较，但不调度任务、不判断采集是否获准，也不保证第三方的响应。采购比较将浏览器工作与网络等待分开测量。

TL;DR

• 用每小时完成页面数设定目标，并设定可接受的最大延迟，然后分别测量两者，不要根据启动时间推断容量。
• 在两个计划并发级别上比较同一组代表性页面，记录浏览器启动、页面就绪时间、内存和失败。
• 测量网络等待时保持浏览器配置固定，然后每次只改变一个浏览器侧变量。
• 将下述工作表和公式视为测量计划，而不是 BotBrowser 基准结果。
• 只测量自有 fixture 或明确获授权的目标/API；不包含实时采集流程。

目录

• 将负载转换为浏览器要求
• 将浏览器时间与网络时间分开
• 可复用的测量计划
• 团队常见问题
• 实践结论

将负载转换为浏览器要求

“规模化”本身并不隐含单一的浏览器数量。规划目标至少需要页面量、观察窗口、页面就绪定义和可接受的完成时间范围。如果一项作业需要在 4 小时内完成 12,000 个页面，算术目标就是每小时 3,000 个页面。这是示例计算，不是实测浏览器容量，也不是对采集量的建议。

每小时页面数比每小时浏览器启动次数更有用，因为启动只是准备阶段。工作负载还要承担创建上下文、导航、执行页面脚本、等待所选就绪条件以及存储结果的开销。一个启动很快、但大部分作业时间都耗在页面工作上的浏览器，仍可能无法达到目标。反过来，如果受支持的设计复用浏览器进程或上下文，较慢的初始启动可被摊薄。性能优化文档介绍运行时调优；负载要求属于采购前比较。

延迟也需要定义。记录从导航开始到工作负载所需确切就绪信号之间的时间，而不是一个未明确指定的“页面已加载”事件。SERP 可能在所有图片或延迟资源完成前已有有用内容，但选择不同的就绪条件会改变结果。比较之间应保持该条件相同，并在结果旁记录该条件。

要求字段	示例值	说明
已完成页面	12000	总工作量，不是启动次数
观察窗口	4 h = 14400 s	可用经过时间
就绪信号	所需内容出现后的 page-ready	必须保持固定
平均目标	12000 / 14400 * 3600 = 3000 pages/h	仅是算术要求
延迟目标	同一就绪事件的 p95 <= 20 s	尾延迟限制，不是平均值

公式将请求的平均值明确化；它不预测浏览器、主机、路线或响应容量。启动、计划暂停、重试和持久化会占用窗口的一部分时间，因此应记录这些开销，而不是将它们隐藏在汇总中。一组浏览器可达到每小时 3,000 个页面，而其中一部分页面的耗时超过 20 s，这正是速率和 p95 目标应属于同一项要求的原因。

在比较产品前定义“已完成页面”。浏览器可以报告所选就绪事件何时发生，而浏览器外部的校验或存储可能稍后完成。应分别保留这些时间戳：下游瓶颈不应被误标为浏览器延迟，更快的结果处理也不应被计为更快的导航。

在观察候选配置前，固定样本和停止规则。选择一组有代表性的 fixture 页面，记录页面数量和复杂度构成，并确定每个并发级别需要多少次重复。例如，每次重复使用 500 pages、3 repetitions 以及两个计划级别，如 4 contexts 和 8 contexts；这些是工作表输入，不是实测上限。每次重复都从已记录的浏览器状态开始，并将失败或超时的页面保留在计数中。

还要确定如何采集资源样本。记录主机 CPU 和内存分配、采样间隔、浏览器构建、配置文件标识符、启动模式和自动化库版本。如果候选配置需要不同的代理路线，只将其与运营方获授权使用的路线进行比较。测试一个浏览器侧变量时，保持 fixture 内容、就绪事件、主机和路线不变。在每个结果旁包含准确的 fixture 标识符、设置字段和样本数，以便重复执行时使用相同输入。

当工作负载从搜索结果转向按雇主组织的列表时，同样的授权规则仍然适用；招聘网站抓取的浏览器边界规定了公开页面允许列表，以及遇到已认证数据时的停止条件。

将浏览器时间与网络时间分开

一次观察到的持续时间会合并多项成本：浏览器启动和上下文工作、代理初始化、导航、本地渲染和脚本执行、网络连接和响应等待，以及工作负载中有意设置的页面等待。单次较慢的观察无法识别应由哪一层负责。浏览器无法让上游响应更早到达，路线变更也不能证明浏览器启动高效。这些比较只使用自有 fixture 或明确获授权的目标/API。

使用受控基线。保持浏览器构建、配置文件、自有 fixture 或获授权页面集、就绪条件、机器资源和网络路线不变。分别记录浏览器启动、代理初始化、导航和页面等待等阶段。然后只改变一个因素：例如，在路线不变的情况下比较进程复用与全新启动。要检查路线影响，应保留浏览器设置，只使用运营方获授权测试的路线和目标。代理配置文档说明网络路线是一个独立的配置表面。

上下文复用和所选页面就绪条件可能改变浏览器侧工作，而不改变路线。性能文档介绍已运行部署的运行时调优；该计划则在受控 fixture 上采集采购前的各个计时阶段。比较之间应保持 fixture 行为和就绪条件一致，并记录一次执行中改变的任何浏览器侧选项。测量不包含选择器、爬取逻辑、实时 SERP 流程或访问控制规避工作。

性能优化文章介绍部署存在后的运行时调优，而浏览器上下文容量规划说明实测内存曲线如何设定准入边界。该测量计划将这些层分开：浏览器启动和页面工作与路线、响应等待分别记录，因此采购比较不会把每个缓慢结果都归因于浏览器。

阶段	开始事件	结束事件	能支持什么
browser_startup	请求启动	浏览器可接受工作负载操作	冷启动与复用比较
proxy_initialization	配置路线	首个请求可使用该路线	设置成本
navigation	导航开始	所选就绪事件	完整页面区间
response_wait	请求开始	响应头或正文可用	观察到的网络行为
completion	就绪事件	下游接受	非浏览器成本

这些阶段可能重叠：浏览器工作继续进行时，多个请求可能正在处理中。将所有请求持续时间都加到页面就绪延迟中，可能造成时间重复计算。应将表格视为成本归属边界，而不是证明某个运行时具有一项完全可分离的浏览器成本和一项网络成本。

资源采样需要固定间隔，例如 sample every 5 s，并记录峰值内存时活动上下文的数量。处理器使用情况应来自同一窗口。如果主机达到 CPU 100% 或耗尽内存，即使浏览器配置未改变，浏览器也可能变慢；主机容量属于测试记录的一部分。

冷启动和热启动工作不应混合成一个无法解释的平均值。第一个页面可能包含进程启动、配置文件加载和后续页面不会重复的初始设置。如果预期工作负载为每个单元启动一个新进程，该冷启动成本具有代表性。如果预期设计复用进程，热路径也同样重要。两种部署模式都在考虑范围内时，应报告两种情形，并说明采购决策要支持哪一种。热路径更快并不能证明冷路径也能适应同一时间表。

可复用的测量计划

该工作表是一份计划，用于填入自有 fixture 或明确获授权目标/API 的观察结果；这些值为空，因为此处没有代表任何执行。

计划字段	每次比较记录	重要性
工作负载	自有 fixture/API 标识符和页面就绪条件	让被比较的执行等价
浏览器	构建、配置文件、启动模式、复用选择	识别浏览器侧变化
阶段 1	浏览器启动持续时间	隔离进程初始化
阶段 2	代理初始化持续时间	将路线设置与页面工作分开
阶段 3	导航持续时间	记录完整导航区间
阶段 4	到固定就绪条件前的页面等待	让完成规则保持明确
负载	计划并发：级别 A 和级别 B	显示测得速率是否变化
结果	已完成页面、经过时间、失败	支持每小时页面数计算
成本	峰值内存和观察到的响应等待	暴露容量和网络压力

该工作表应视为最低记录，而不是完整测试规格。当候选配置之间存在差异时，加入主机 CPU 和内存分配、操作系统、浏览器构建标识符以及任何自动化库版本。记录浏览器是无头运行还是使用可见显示环境，因为只有模式与预期部署一致时，比较才有意义。如果候选配置需要不同的主机形态，应明确记录这一事实，而不是将结果单独归因于浏览器。四个计时阶段是观察分桶，不保证每个自动化库都暴露四个不重叠的测量值；应说明每个分桶使用的事件边界。

规划时，可用一张紧凑的决策表让结论与证据保持关联：

计划比较中的观察	待调查的解释	下一步测量
启动或代理初始化在级别 B 增加	设置工作可能正在与并发作业争用	在固定 fixture 和路线的情况下重复 A 和 B
导航增加，而其他阶段保持相似	完整导航区间需要更细致的归属	保持浏览器固定，并复查响应等待观察结果
页面等待增加，但导航稳定	就绪时序或页面工作可能解释差异	在同一 fixture 上复查同一就绪事件
每小时页面数变化很小，而峰值内存上升	主机或浏览器工作负载可能受到资源限制	重复两个级别并检查主机资源样本
浏览器各阶段保持相似，而响应等待变化	网络条件可能解释差异	保持浏览器配置固定，并复查获授权路线比较

这些是解释提示，而不是基准结果。每一行说明未来观察可能意味着什么，以及下一步应检查哪个变量；它并不断言某次 BotBrowser 执行产生了该模式。采购总结同样适用这一原则：在每个结果旁包含配置和测量窗口，并区分观察到的差异与因果解释。

对每次执行计算 pages_per_hour = completed_pages / elapsed_seconds * 3600。该公式将一次完成的执行标准化；它不预测下一次执行。在两个并发级别上比较相同字段，例如低负载基线和较高的计划级别，而不是将单个结果当作上限。如果吞吐量停止增长，同时浏览器内存或就绪延迟上升，浏览器或主机可能已经饱和。如果浏览器侧指标保持稳定而响应等待变化，应单独调查网络路径。

应重复该计划足够多次以观察变化，并报告样本数和离散程度，而不只是最快的一次执行。将失败和超时的 fixture 页面保留在记录中：移除它们会让表面速率看起来更好，同时隐藏运维成本。这是一种测量设计，不承诺两个并发点就能确立通用容量上限。

自有 fixture 应代表相关页面复杂度，同时让敏感查询数据不进入共享报告。稳定的 fixture 可以使用中性标签，同时保留不同的渲染和脚本负载。记录其标识符以及对浏览器工作重要的特征，例如脚本活动、布局和就绪时预期出现的内容。不要用少量轻量 fixture 页面的结果声称适用于所有工作负载。候选配置之间应保持准确 fixture 不变，避免将浏览器差异与内容差异混在一起。如果目标是获授权 API，应说明 API 操作、其文档化响应条件，以及省略敏感输入的公开安全样本。

失败应计入分母，并进入单独的失败汇总。导航超时、从未发生的就绪条件和下游持久化错误是不同事件。按发出事件的状态标记它们，保留计数，并说明这些页面是否计入完成输出。报告每小时页面数时若不附失败计数，可能隐藏较低的完成率。测量记录应保留足够细节，使另一名复核者能够理解候选配置是否完成了定义的任务，而不只是它是否产生了浏览器活动。

测试窗口还需要停止规则。短时间执行可能主要在测量启动，而很长时间的执行可能混入无关的主机或路线变化。观察结果前选择持续时间或页面数，在相同条件下重复，并注明任何中断。不要只延长最初看起来较慢的候选配置，除非随后一致地将修订计划应用于所有候选配置。这样可避免在看到哪个结果更方便后改变比较。

最后，分别汇总三个量：请求的平均吞吐量、观察到的完成吞吐量以及观察到的延迟分布。第一个是要求；第二个是一次已记录设置的结果；第三个描述这些完成时间周围的时序变化。其中任何一项单独都不能确立通用浏览器容量。采购决策还应保留设置记录、资源分配、失败计数和页面 fixture 的限制，以便后续变化可与同一基线比较。

团队常见问题

仅凭启动时间足以估计容量吗？

不能。启动时间遗漏了导航、就绪、页面执行和结果处理。它是一个有用的组成部分，尤其是在启动频繁时，但每小时完成页面数才是工作负载层面的指标。

每个页面都应使用同一就绪条件吗？

在一次比较内使用同一条件，以便各次执行可以比较。该条件应与工作负载实际需要的结果一致；等待无关资源可能夸大浏览器工作，而过早停止可能遗漏必需内容。

更高并发总能提高吞吐量吗？

不能。额外的并发页面会增加对 CPU、内存、浏览器进程或网络资源的争用。应在计划级别测量，并将平台期或延迟上升视为需要调查的证据，而不是通用容量上限。

BotBrowser 决定 SERP 工作负载是否成功吗？

不能。BotBrowser 为受控比较提供浏览器运行时和可见的浏览器结果。工作调度、网络质量、第三方响应以及授权决策仍在该能力边界之外。

实践结论

为规模化 SERP 抓取选择浏览器设置前，应将工作负载转换为每小时页面数和已定义的就绪延迟。使用自有 fixture 或明确获授权的目标/API，在两个并发级别上执行可重复计划；分别记录启动、代理初始化、导航和页面等待。保持浏览器变量与网络变量彼此独立，并使用比较结果识别需要关注哪项资源。下一步是定义获准使用的 fixture 和就绪条件；通用浏览器数量无法替代该基线。所需范围不涉及采集实时 SERP、选择页面元素、实现爬取逻辑或绕过 CAPTCHA、速率限制或访问控制。

来源

• Playwright：BrowserType API
• Playwright：测试超时
• BotBrowser：Playwright 入门
• BotBrowser：性能优化
• BotBrowser：代理配置