用Selenium写爬虫的人迟早会碰上一件事脚本逻辑没问题选择器全写对了可就是慢。慢到什么程度几年前我跑一个资讯类站点的采集任务一个页面从加载到拿到数据要10秒出头两万条数据放那儿得整整跑一天中途还时不时弹出一个预期外的元素把脚本卡死。当时我第一反应是自己代码写得烂后来把等待策略、选择器、数据提取全部优化了一遍也就快了两三秒治标不治本。问题的根源不在代码而在Selenium的执行模型你每操作一步浏览器都像真人一样完整走完HTML解析、CSS渲染、JavaScript执行、字体图片加载这一整套流程而爬虫真正需要的往往只是那几行DOM节点。为了拿到一个目标数据白白伺候了整个浏览器。后来我换了个思路能不能直接绕过这套“真人模式”让Chrome只用它真正需要的资源答案就是Chrome DevTools协议CDP。Selenium 4原生支持调用CDP命令这意味着不用换框架直接在现有Selenium脚本里注入加速能力。这篇文章我就把这几年的实操经验拆开讲从CDP的基础认知、Selenium里的接入方式到屏蔽资源、直取响应体这些加速手段再到稳定性踩坑和合规边界一次说透。1. 先说痛点Selenium爬虫慢在哪又为何难提速1.1 一次driver.get背后浏览器替你做了多少事很多人优化Selenium时有个错觉觉得慢是代码的问题其实不是。你用driver.get(url)打开一个普通网页浏览器从头到尾做了这些事DNS解析、TCP建连、TLS握手、下载HTML主文档然后在解析HTML的过程中发现几十个外链资源——CSS、JS、字体、图片、iframe还有各种统计脚本和广告脚本。接下来逐一下载这些资源下载完还要逐条执行JS、渲染样式、加载字体。等这些全部忙完浏览器才会触发load事件Selenium的get方法才返回。一个实际数据只有几十KB的页面可能连着几MB的图片、字体、埋点文件一起加载了大部分时间都在干无关的活。我在Chrome的Network面板里统计过几次一个普通新闻列表页HTML主体只占全部网络流量的3%左右图片占50%以上剩下的是各种JS和CSS。也就是说你每打开一个页面97%的带宽和时间都花在了爬虫并不需要的东西上。1.2 常见“提速”手段为什么治标不治本Selenium社区里流传的提速方法我几乎都试过逐一说下效果隐式等待设置driver.implicitly_wait(5)之后find_element找不到元素时会轮询最多5秒。它解决的是“元素还没出现就去找”的问题但浏览器该加载多少资源还是加载多少。显式等待WebDriverWait配合expected_conditions能精确控制等到目标元素出现就动手不再额外地睡满几秒。这一招能把固定睡眠浪费的时间省下来但是页面加载本身的耗时一点没少。关闭图片加载options.add_experimental_option(prefs, {profile.managed_default_content_settings.images: 2})确实能省流量但很多页面的布局依赖图片尺寸图片一关连带着点击位置、滚动位置都飘了乱报错的频率反而变高。无头模式省掉了显卡渲染开销实测快20%-30%但JS执行和网络加载依然是全额支出提速天花板很低。这些方法共同的问题是都在“省等待”没有在“省浏览器干活”。真正想提速应该从两个方向同时下手——让浏览器少下载资源让脚本少等渲染。这两个方向恰好都是Chrome DevTools协议的主场。2. 为什么选CDP它到底给爬虫带来了什么新能力2.1 CDP是一张操作Chrome的总控面板Chrome DevTools协议Chrome DevTools Protocol是Chrome从很早的版本就开放的一套远程调试协议基于WebSocket传输JSON消息。你平时按F12看到的那些调试功能——查看网络请求、断点、改DOM、模拟设备——底层全都是通过CDP在跟浏览器对话。这套协议按“域Domain”组织命令比如Network域管理网络请求Page域管页面生命周期Runtime域执行JavaScriptEmulation域模拟设备和环境。每个域下面有几十个具体命令比如Network.enable、Page.setVirtualTimePolicy、Runtime.evaluate。真正关键的是Selenium从4.0开始内置了execute_cdp_cmd方法直接把这个“总控面板”开放给了普通脚本。这意味着你不用新学一套Playwright API可以在现有Selenium项目里用一行driver.execute_cdp_cmd(Network.setBlockedURLs, {...})就让浏览器按你的规矩去加载。2.2 对爬虫最有用的几个域及它们如何配合提速把CDP所有域过一遍后爬虫场景下真正高频用到的就这几个CDP域核心命令对爬虫的价值NetworksetBlockedURLs, enable, getResponseBody, setUserAgentOverride屏蔽资源、直取响应体、伪装请求头是加速最直接的手段PageaddScriptToEvaluateOnNewDocument, setVirtualTimePolicy导航前注入脚本清理特征虚拟时间能加速定时器Runtimeevaluate, compileScript不通过Selenium的find/click直接执行JS拿数据EmulationsetDeviceMetricsOverride, setUserAgentOverride伪装移动端或指定设备适配不同类型的反爬页面PerformancegetMetrics测量页面加载耗时用于测试对比这几个域不是孤立用的。我常用的一套组合是Network.setBlockedURLs屏蔽图片字体Network.setUserAgentOverride换掉User-AgentPage.addScriptToEvaluateOnNewDocument清掉自动化特征然后正常get页面配合Network.getResponseBody直接读HTML。整个过程浏览器只下载必要的HTML和JS页面加载速度肉眼可见地上一个台阶。有人可能会问既然CDP这么强为什么不直接上Playwright这个后面会展开先记住结论如果你已经有大量Selenium脚本切成CDP的组合拳改造成本远低于换框架收益却不比换框架差。3. 落地第一步在Selenium里接通CDP并验证连通性3.1 最小可行示例两条命令验证CDP已通理论说再多不如先跑通一个最小示例。Selenium 4及以上版本有execute_cdp_cmd用法如下from selenium import webdriver driver webdriver.Chrome() # 第一条CDP命令取浏览器版本信息 result driver.execute_cdp_cmd(Browser.getVersion, {}) print(result)如果控制台输出了类似{browser: Chrome/120.0.0.0, protocolVersion: 1.3, ...}的内容说明CDP已经接上了。execute_cdp_cmd的第一个参数是命令名第二个参数是命令参数字典哪怕没有参数也要传一个空字典{}。我见过不少人在这步卡住报unknown command或者Cannot call non-JSON-RPC command。绝大多数原因是Selenium版本低于4或者用了老旧的第三方驱动包。建议直接把Selenium升到最新pip install -U seleniumSelenium 4.6以上版本自带Selenium Manager会自动给当前Chrome下载匹配的驱动这步能省掉手动配driver的麻烦。3.2 用事件监听拿到浏览器的主动上报execute_cdp_cmd是“发一条命令拿一个结果”属于一问一答。但CDP里还有一大类能力是“浏览器主动上报事件”比如每个HTTP响应到达时浏览器会发一个Network.responseReceived事件。要拿到这类事件Selenium 4.13以上版本提供了add_cdp_event_listener。下面这段代码演示怎么监听网络响应事件并顺手收集所有响应体的长度from selenium import webdriver from selenium.webdriver.common.devtools import network # 注意网络事件必须先在Network域开启enable driver webdriver.Chrome() driver.execute_cdp_cmd(Network.enable, {}) response_sizes [] def on_response(event): if isinstance(event, network.ResponseReceived): response_sizes.append(event.response.encoded_data_length) driver.add_cdp_event_listener(on_response) driver.get(https://example.com) print(response_sizes)这里有几个细节提醒一下事件监听器必须在导航发生之前注册否则get之后的事件全都会漏掉。回调里的event对象类型来自selenium.webdriver.common.devtools这个模块按Chrome DevTools协议版本划分不同Chrome版本可能要导入不同的子模块比如selenium.webdriver.common.devtools.v85。实际遇到版本不匹配时优先升级Selenium。事件回调默认在同一个线程里执行不要在回调里做耗时操作否则会拖慢浏览器响应。3.3 这些场景别用execute_cdp_cmdexecute_cdp_cmd不是万能的我在项目里碰过几类情况直接用它反而吃亏需要持续监听事件时execute_cdp_cmd发完命令就返回了事件得靠add_cdp_event_listener才能收到。某些命令依赖具体的CDP协议版本比如Performance.getMetrics在不同Chrome版本里返回字段就有差异。跨版本调试时宁可少用冷门命令也别把代码绑死在某个版本。命令名拼写错误不会在IDE里报错只有运行时才爆。建议把高频的CDP命令封装成函数配上注释至少出错时能快速定位。跑通最小示例之后下面这些加速手段才有承载的基础。4. 三个加速杀手锏从减少加载到直取响应体4.1 屏蔽无关资源一行代码砍掉一半加载量网络请求是爬虫等待时间的最大头。要减少加载量最直接的办法是让浏览器按你的规则屏蔽无用的资源类型。CDP里对应的命令是Network.setBlockedURLs它支持通配符匹配URL。from selenium import webdriver driver webdriver.Chrome() driver.execute_cdp_cmd(Network.enable, {}) driver.execute_cdp_cmd(Network.setBlockedURLs, { urls: [ *.jpg, *.jpeg, *.png, *.gif, *.webp, *.svg, *.ico, *.woff, *.woff2, *.ttf, *.mp4, *.mp3 ] }) driver.get(https://example.com)这段代码把图片、字体、视频全部屏蔽。对于一个数据列表页流量能下降60%以上加载速度提升非常明显。我自己实测过同一个站点的翻页采集任务从每页7秒掉到3秒左右。但这里有一个非常重要的经验不要盲目屏蔽CSS更不要屏蔽JS。很多页面是前端渲染的数据写在JS里你屏蔽JS就等于什么都拿不到。字体和图片偶尔也要留因为某些网站的懒加载机制依赖图片的占位尺寸全屏蔽后有滚动位置错乱的风险。建议屏蔽列表里先不加CSS和JS跑一轮看效果再决定要不要收紧。还有个小技巧可以在同一个会话的不同阶段动态调整屏蔽规则。比如首页需要一次完整加载后续翻页就不需要了那就在翻页前重新setBlockedURLs一次把上次的规则覆盖掉。4.2 用Network.getResponseBody直接拿数据把渲染这一步整个跳过屏蔽资源只是减少了加载量但页面还是要等JS执行完、DOM稳定下来才能提取数据。如果目标数据本来就在服务器返回的HTML里最省事的办法是绕过渲染直接读取HTTP响应体。这就是Network.getResponseBody的用途。思路是这样的先开启Network.enable监听responseReceived事件收集所有请求的requestId访问目标页面后用这些requestId逐个调Network.getResponseBody拿HTML源码。import time from selenium import webdriver from selenium.webdriver.common.devtools import network driver webdriver.Chrome() driver.execute_cdp_cmd(Network.enable, {}) request_ids [] def collect_response(event): if isinstance(event, network.ResponseReceived): request_ids.append(event.request_id) driver.add_cdp_event_listener(collect_response) driver.get(https://example.com/list) # 等0.5秒让响应到达即可不需要等页面完整渲染 time.sleep(0.5) target_body None for rid in request_ids: try: body_result driver.execute_cdp_cmd(Network.getResponseBody, { requestId: str(rid) }) body body_result.get(body, ) if 目标栏目名称 in body: target_body body break except Exception: continue if target_body: # 直接交给BeautifulSoup或lxml解析 print(len(target_body))这个方案的提速效果是最夸张的。拿我之前跑的一个列表页为例原本要等整个页面渲染平均8秒换成响应体直取之后页面还在加载图片的时候我已经拿到HTML开始解析了单页耗时压到1.5秒左右。需要注意的是getResponseBody读的是Chrome内部缓冲区里保存的响应数据如果请求本身被重定向或者内容过大可能拿不到。遇到拿不到的情况不要硬抢退回常规的页面解析即可这个我在第6节会细说。4.3 注入脚本清理自动化特征降低被识别概率爬虫场景里Selenium被网站识别是个绕不开的话题。很多网站会在JS里检查navigator.webdriver这个属性只要值是true基本就可以断定你在用自动化工具。这类检查在普通模式下很难绕过但CDP提供了一个很优雅的入口Page.addScriptToEvaluateOnNewDocument。这个命令的作用是在每次页面导航开始之前、任何页面脚本执行之前先注入一段自定义JavaScript。利用这个时机可以把自动化特征抹掉from selenium import webdriver driver webdriver.Chrome() driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, { source: Object.defineProperty(navigator, webdriver, { get: () undefined }); }) driver.get(https://example.com)注意Page.addScriptToEvaluateOnNewDocument必须在get之前执行否则这次导航不会生效。它处理的是后续所有的导航包括页面内部的跳转和刷新。类似的思路还能用在User-Agent上。Network.setUserAgentOverride可以在CDP层面改掉请求头里的User-Agentdriver.execute_cdp_cmd(Network.setUserAgentOverride, { userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/120.0.0.0 Safari/537.36 })这里我强调一句这些手段是让正常自动化测试和合规数据采集不被误伤不是说让你去对抗什么防盗机制。我自己做项目的原则是只采公开数据不碰登录后的私有内容不碰付费墙后面还会专门讲这个边界。5. 实测对比同一采集任务四种方案的耗时差异5.1 测试环境和测量方式讲再多原理不如看一组手测的数据。我在一个标准的动态渲染列表页上跑过对比测试目标网站的特点是列表数据由前端JS渲染有大量图片和埋点脚本每次翻页需要点击一个“下一页”按钮。测试环境如下机器普通办公笔记本8G内存浏览器Chrome 120独立用户数据目录目标采集20个列表页取每页从点击到数据可解析的平均耗时测量方式每次操作前后用time.time()记点循环20次去掉最高最低各2次取中位数我比较了四种方案原始Selenium默认加载所有资源、Selenium无头模式、无头CDP屏蔽图片字体、无头CDP屏蔽资源响应体直取。测量代码大概长这样import time from selenium import webdriver def measure(url, setup_funcNone): driver webdriver.Chrome() if setup_func: setup_func(driver) start time.time() driver.get(url) # 等一个稳定的目标选择器出现 driver.find_element(css selector, .list-item) elapsed time.time() - start driver.quit() return elapsed # 每种方案跑20次 results [] for i in range(20): results.append(measure(https://example.com/list))5.2 关键数据与结论方案单页耗时中位数相对原始方案的提升说明原始Selenium10.6秒-图片、字体、广告全部加载无头模式8.2秒22%省掉渲染开销无头 CDP屏蔽图片字体4.1秒61%网络流量大幅下降无头 CDP屏蔽资源 响应体直取1.9秒82%不等渲染直接读HTML最直观的结论是方案三和方案四的提升主要来自“少加载”和“少等待”这跟我反复强调的两个方向完全吻合。方案四虽然快但也有前提目标数据必须落在初始化HTML的响应体里或者搭上接口请求。如果页面数据要经过复杂的多次交互才能出现方案四就不适用这时候老老实实用方案二加方案三的组合。另外提一句无头模式在方案四里反而不重要了因为响应体直取本身就不关心页面是否渲染完成。我在实际项目中通常不开无头因为有些网站会检测无头模式反而更容易被拦。6. 提速之外稳定性才是爬虫的命脉6.1 事件丢失和连接重置最容易踩的CDP坑CDP提速效果明显但稳定性问题也真不少。我踩过的坑排第一的是“事件丢失”。有一次我写好了responseReceived监听器自信满满地跑批量任务跑到第100页的时候突然解析不到数据了。定位了半天才发现add_cdp_event_listener只对注册之后的导航生效而我在某次条件分支里先执行了driver.get、后注册监听器导致那一页的所有网络事件全部错过。解决办法很简单把监听器注册放在所有导航操作之前最好放在创建driver之后的第一件事。第二个坑是连接重置。Chrome在某些极端条件下尤其是内存不足或者页面崩溃会主动断开调试连接CDP命令会直接抛异常。我做了一个简单的重试包装核心逻辑是捕获异常后重建driver重新注册监听器再重新发起导航。def safe_get(driver, url, retries3): for attempt in range(retries): try: driver.get(url) return except Exception as e: print(f第{attempt 1}次重试: {e}) time.sleep(2) # 这里可以重建driver raise RuntimeError(连续多次加载失败)第三个坑是事件回调查内存只增不减。request_ids列表如果只追加不清理跑几千页之后内存占用会非常难看。我在实际代码里做了限制每个页面最多保留最近50个requestId拿到响应体后立即清空。6.2 版本兼容性问题Selenium的execute_cdp_cmd对命令名和参数字段的校验很宽松所以你直接传字符串命令通常没问题。但一旦用到add_cdp_event_listener就会接触到selenium.webdriver.common.devtools里的类型对象这些对象跟CDP协议版本强相关。我遇到过的情况是本机Chrome 119Selenium装的是4.15一切正常部署到另一台服务器上Chrome是126同样的代码导入from selenium.webdriver.common.devtools import network结果事件回调类型比对不上了。解决思路有两个方向一是升级Selenium到最新版Selenium Manager会自动匹配最接近的CDP协议描述二是自己写一个轻量的WebSocket客户端直接连Chrome的调试端口手工解析CDP事件。第二种门槛高一些我不建议新手一上来就搞。对绝大多数场景老老实实升级Selenium就够了。6.3 并发场景下CDP的正确打开方式爬虫跑到后期一定会想到并发。这里的核心建议是一个driver实例配一个线程或进程绝对不要多个线程共享同一个driver去发CDP命令。原因在于CDP命令走的是同一条WebSocket通道多个线程同时发命令响应顺序乱掉是小事通道状态被搞坏是大事。我早期图省事用一个driver开了四个线程跑翻页采集结果就是各种奇怪的超时和连接问题。推荐的做法是每个worker进程持有独立的driver通过队列下发任务。粗略的伪代码如下import multiprocessing as mp def worker(task_queue): from selenium import webdriver driver webdriver.Chrome() # 每个worker独立注册一遍CDP监听器 setup_cdp(driver) while True: url task_queue.get() if url is None: break crawl_one(driver, url) driver.quit() if __name__ __main__: queue mp.Queue() # 往队列里丢URL processes [mp.Process(targetworker, args(queue,)) for _ in range(4)] ...并发的数量要按机器的CPU和内存来调。每开一个driver都要吃几百MB内存8G内存的机器开4到5个就已经很极限了别贪多。7. 从哪来回哪去这套能力的边界与合理使用7.1 什么场景该用CDP什么场景不该用了这么久我对CDP的适用场景有了比较清晰的判断。适合用CDP的场景数据依赖前端JS渲染、需要真实浏览器环境才能拿到页面里有无用的图片字体拖慢加载需要频繁翻页或滚动触发的列表页目标站点对自动化工具本身没有极端的对抗策略。不适合用CDP的场景如果目标站本身就是纯API返回JSON直接用requests拿数据连浏览器都不用开如果目标站对自动化检测到了指纹级别会检查Canvas、WebGL、字体列表这种CDP层面的基础手段已经不够用了如果目标站对请求频率极其敏感优先控制频率而不是靠CDP硬冲。有一个判断标准我很推荐先看一眼目标站点的加载瀑布图如果HTML里就已经有目标数据走CDP响应体直取一定是最优解如果目标数据依赖单独的XHR接口直接用requests模拟那个接口比任何浏览器方案都快只有当数据藏在JS渲染后的DOM里、没有独立接口时SeleniumCDP的组合才真正值回票价。7.2 合规使用别把自己的路走窄最后必须说点实在的。CDP这层能力本质上是给开发者调试用的拿来提速爬虫是效率技巧不是拿来突破边界的工具。我自己定的三条铁律也建议所有做爬虫的朋友参考只采集公开可见的数据不采登录后才能看到的私有内容。控制请求频率不暴力压榨目标服务器毕竟别人的带宽也是真金白银。尊重目标站点的robots约定和使用条款做一个合格的数据使用者。一个爬虫项目能不能长期跑下去靠的不是单一的反反爬技巧而是对整个采集节奏、目标站容错和自身稳定性的把握。CDP给Selenium开的这扇门用好了是效率提升用歪了就是给自己找麻烦甚至惹来法律层面的风险。我现在的所有采集任务里SeleniumCDP已经成了标配骨架但它始终只是工具。判断什么数据该采、什么不该采、采到什么程度该停下这才是比任何协议命令都重要的判断力。这行摸爬滚打这些年最大的感受是技术方案总有解法但边界感不是一个脚本能给你的得靠自己守住。