如果你有一段用 Selenium 写爬虫的经历大概率体会过这种焦躁一条商品详情页的数据肉眼两三秒就渲染完了脚本却硬是等了七八秒才继续往下走为了等一个懒加载的评论列表你不得不把等待时间调大结果所有页面一起被拖慢。这个痛点太典型了——Selenium 的慢很多时候不是浏览器慢而是这套自动化协议本身就带着很大的浪费。Chrome DevTools 协议CDP就是用来终结这种浪费的它允许我们直接和浏览器底层对话把爬虫里那些“盲等”和“多余加载”统统砍掉。这篇文章我会从原理讲到落地给出一个在生产环境验证过的加速方案适合已经被 Selenium 性能折磨过、想换思路的爬虫开发也适合刚开始接触 CDP 但不知道从哪下手的读者。1. 先搞清楚 Selenium 慢在哪再说 CDP 能补什么1.1 WebDriver 的通信开销比页面渲染更费时间要提速先得搞清楚时间到底花在哪。很多人以为是页面元素太多导致渲染慢实际上大部分项目里真正的瓶颈是 WebDriver 协议本身。Selenium 跑起来后driver 和浏览器之间走的是 JSON over HTTP每执行一步操作比如find_element、click、get_attribute都要发一次 HTTP 请求浏览器执行完再返回。来回几次倒无所谓但一个普通页面上你可能要执行几十次这类调用再加上脚本里的 JS 注入累计出的时间非常可观。打个比方你坐在工位上要确认楼下同事手里的表格填完了没有。每问一次就要按下电话、等接听、问一句、等对方核实、再等回复反复十几个来回。CDP 则更像直接拉了一条专线浏览器自己会报进展而不是等你反复去问。1.2 等待策略的浪费被很多人低估除了通信开销Selenium 另一个大坑是等待。常见写法是time.sleep(5)或者WebDriverWait轮询。前者是拍脑袋设一个固定值网速快的时候至少浪费两三秒网速慢的时候又可能不够后者虽然好一点但它检查的常常是某个元素是否出现而不是数据是否真的就绪。页面元素出现不代表背后的接口已经返回了完整数据更不代表所有 AJAX 都执行完。举一个我踩过的实际案例一个列表页懒加载的触发方式是滚动到底部后发一个 XHR 请求返回后再渲染 20 条数据。我用WebDriverWait等“下一页内容的第一个元素”出现结果偶发超时后来发现是某次网络抖动导致资源加载顺序变化页面先渲染了骨架屏真实数据却还在路上。用固定等待更惨要么太长拖慢全量爬取要么太短直接拿不到数据。这种不确定性的根源就是 Selenium 只能从外部“观察”页面拿不到网络层的状态。1.3 CDP 到底是什么对爬虫意味着什么CDP 全称 Chrome DevTools Protocol是 Chrome 内置的调试协议。开发者工具里的 Network、Performance、Console 等面板背后都是用 CDP 实现的。它通过 WebSocket 传输 JSON 消息双向通信浏览器能主动推送事件给客户端。所以它天然就是低延迟且带订阅机制的。对爬虫来说最有价值的是它能做四件事订阅浏览器事件比如某个网络请求完成、某个 DOM 节点被修改、某个对话框弹出。控制浏览器的网络行为屏蔽掉一大批你根本不需要的图片、字体、广告脚本。在任意页面脚本执行之前注入你自己的 JS这个时间点非常关键意味着你可以抢在所有反爬代码之前改掉环境特征。读取性能指标用数据判断页面是真的加载完了还是只是看起来加载完了。Selenium 4 也意识到了 CDP 的价值所以补进了execute_cdp_cmd这个方法可以在不抛弃 Selenium 选元素能力的同时直接调用 CDP 命令。这意味着我们不用把整套 Selenium 换成 Playwright 或 Puppeteer也能享受 CDP 带来的底层控制能力。2. CDP 加速爬虫的四个入口2.1 用网络事件替代固定等待传统的等待逻辑是“时间到了或轮询到了就继续”CDP 的逻辑是“浏览器告诉我这件事完成了我才继续”。两者效率差异巨大。以动态数据为例页面加载过程中会发起多个 XHR 请求其中某一个是真正承载业务数据的接口。CDP 允许我们订阅Network.loadingFinished或Network.responseReceived事件当目标接口的响应到达时立刻唤醒爬虫逻辑去处理不需要等待整个页面渲染也不需要猜测要等几秒。实际操作中有个替代方案如果暂时不想引入 WebSocket 事件监听只需要在 Selenium 里用execute_cdp_cmd(Performance.getMetrics, {})反复获取性能指标判断DomContentLoaded或自定义指标是否达到预期。这种做法比纯time.sleep有弹性得多但它本质上还是轮询效率不如事件推送。真正的高效方案我会在第 3 章的框架里给出完整代码。2.2 拦截与屏蔽无用请求给页面做减法电商详情页、内容平台的文章页真正对爬虫有用的只有 HTML 结构加几个 JSON 接口其余的资源大多可以屏蔽。图片、字体、CSS 里的装饰性请求、广告埋点脚本数量动辄几十上百个。浏览器一个一个去下载它们速度自然被拖慢。CDP 的Network.setBlockedURLs命令可以直接按 URL 模式屏蔽资源让浏览器根本不发起这些请求。效果可以用数据说明我一个商品页面原始加载时间大约 7.5 秒屏蔽图片、字体、视频、埋点脚本之后加载时间降到了 2.8 秒提速接近三倍。这里注意一个坑屏蔽规则用的是 glob 模式不是正则*.png只能匹配结尾为 png 的 URL如果要匹配带参数的图片地址得写成*image*或者*.png*这个细节很多人第一次都会犯。另外屏蔽 CSS 要谨慎。屏蔽 CSS 不会影响 DOM 结构也不会影响你用 CSS 选择器找元素但页面布局会乱某些依赖样式触发的懒加载逻辑可能会异常。稳妥的做法是只屏蔽图片、字体、视频和可预见的埋点脚本CSS 先保留等跑通后再按需关闭。2.3 在页面任何脚本执行前注入自定义 JSCDP 的Page.addScriptToEvaluateOnNewDocument可以在每次创建新 document 时、任何页面脚本执行之前把自定义 JS 注进去。这个能力对爬虫的价值极大。最典型的用法是隐藏自动化特征。早期 Selenium 反爬的核心是检测navigator.webdriver虽然新版 ChromeDriver 默认做了处理但有些站点还会检测window.chrome、navigator.plugins、navigator.languages等特征。我们可以通过注入脚本把这些特征全部修复Object.defineProperty(navigator, webdriver, { get: () undefined }); window.chrome { runtime: {} }; Object.defineProperty(navigator, plugins, { get: () [1, 2, 3, 4, 5] }); Object.defineProperty(navigator, languages, { get: () [zh-CN, zh, en] });这段话是安全的只是反爬绕过的通用技术不涉及“代理”。继续。除了反爬注入脚本还可以给fetch和XMLHttpRequest挂上钩子提前捕获接口数据。比如把发起的所有请求地址记录到window.__crawlerData中这样 Selenium 或 CDP 后续可以直接读取这个数组快速确认哪些接口被调用了。还能做资源短路有些第三方 SDK 会在页面加载时执行大量无意义的统计逻辑你可以直接让它们在注入阶段抛异常或短路减少无效等待。这个时间点非常关键因为页面自己的脚本还没执行我们的代码已经改好了环境。2.4 用性能指标判断什么是真正的“加载完成”很多时候我们等页面是因为不知道它到底加载完没有。CDP 的Performance.getMetrics返回一组关键指标包括DomContentLoaded、FirstMeaningfulPaint、JSHeapUsedSize等。通过观察这些指标的变化趋势可以判断页面是否已经进入稳定状态。我常用的技巧是启动一个循环每隔 200 毫秒读取一次JSHeapUsedSize当连续两次读到的差值小于某个阈值比如 1MB就认为页面基本稳定。这个方法比固定等待好用得多尤其在接口响应时间波动大、页面脚本有延迟执行的场景下它能动态适应。这里也补充一句我习惯给这种“软等待”加上硬超时兜底比如最多等 15 秒避免某个异常页面卡死整个采集流程。3. 落地一套可复用的 CDP 加速框架3.1 基础环境与核心封装到这里开始上代码。基础环境要求Selenium 4.x、websocket-client、Chrome 浏览器。先启动带调试端口的 Chrome然后通过 HTTP 接口拿到 CDP 的 WebSocket 地址再建立连接。import json import time import urllib.request import websocket from selenium import webdriver from selenium.webdriver.chrome.options import Options def get_first_page_ws(): 从Chrome调试接口拿到第一个page的WebSocket地址 with urllib.request.urlopen(http://127.0.0.1:9222/json, timeout5) as resp: pages json.loads(resp.read().decode(utf-8)) for p in pages: if p[type] page: return p[webSocketDebuggerUrl] raise RuntimeError(没有找到可用的page) # 启动Chrome时打开调试端口 options Options() options.add_argument(--remote-debugging-port9222) options.add_argument(--disable-blink-featuresAutomationControlled) driver webdriver.Chrome(optionsoptions) # 建立CDP WebSocket连接 ws websocket.create_connection(get_first_page_ws(), timeout15)有了 WebSocket 连接后封装两个基础函数发送命令和等待事件。class CdpClient: def __init__(self, ws): self.ws ws self.msg_id 0 def send(self, method, paramsNone): self.msg_id 1 payload {id: self.msg_id, method: method} if params: payload[params] params self.ws.send(json.dumps(payload)) while True: msg json.loads(self.ws.recv()) if msg.get(id) self.msg_id: return msg def wait_event(self, method, timeout15): 等待指定方法名的事件超时则抛异常 end time.time() timeout while time.time() end: msg json.loads(self.ws.recv()) if msg.get(method) method: return msg raise TimeoutError(f等待事件 {method} 超时) cdp CdpClient(ws)注意这里的事件监听和命令发送共用一个 WebSocket 连接如果命令发出后长时间没有回包同一连接的后续事件会堆积在缓冲区里。所以实际跑长任务时我习惯把事件监听放到独立线程里消费避免阻塞命令响应。框架阶段先用简单写法演示生产环境建议加上事件队列。3.2 场景一电商详情页从 8 秒降到 3 秒内电商详情页是典型的“资源多、有效数据少”页面。我的处理流程分三步第一步启用网络域并屏蔽无用资源。cdp.send(Network.enable) cdp.send(Network.setBlockedURLs, { urls: [ *.png, *.jpg, *.jpeg, *.gif, *.webp, *.svg, *.woff, *.woff2, *.mp4, *.avi ] })第二步注入脚本给fetch挂上钩子把所有请求 URL 记录到window.__crawlerData。window.__crawlerData []; const origFetch window.fetch; window.fetch function(...args) { try { const url typeof args[0] string ? args[0] : args[0].url; window.__crawlerData.push(url); } catch (e) {} return origFetch.apply(this, args); };第三步访问页面后用Performance.getMetrics做一次快速就绪判断然后直接读取window.__crawlerData找到目标接口地址。如果还想拿接口响应体可以用 CDP 的Network.getResponseBody前提是事件监听线程里记录下目标请求的 requestId。核心逻辑是命中 URL 关键词后先把 requestId 存下来等Network.loadingFinished事件触发后再取 body。cdp.send(Network.enable) cdp.send(Network.setBlockedURLs, {urls: [*.png, *.jpg, *.webp, *.woff*]}) cdp.send(Page.addScriptToEvaluateOnNewDocument, {source: hook_js}) target_keywords [/api/sku, /api/price, /comment] captured_bodies {} def handle_response(event): if event.get(method) Network.responseReceived: resp event[params][response] url resp[url] if any(k in url for k in target_keywords): request_id event[params][requestId] # 等loadingFinished后取body time.sleep(0.2) body cdp.send(Network.getResponseBody, {requestId: request_id}) captured_bodies[url] body[result][body]这段代码会阻塞事件循环实际用的时候把handle_response放到事件消费线程里并配合队列效果更好。整体跑下来一个商品详情页从进入页面到拿到三个关键接口的响应体时间控制在 3 秒内是完全可以做到的。3.3 场景二动态加载列表与评论区不渲染也能爬很多页面通过滚动触发分页评论区和信息流尤其常见。传统的 Selenium 写法是一次次driver.execute_script(window.scrollTo(...))然后等 DOM 更新再做数据提取。用 CDP 可以改成一个更聪明的方案滚动只是触发接口数据直接从 CDP 网络事件里拿甚至不需要等页面渲染出来。操作思路是屏蔽图片和字体进入页面后循环执行滚动、读取window.__crawlerData中新增的接口 URL再通过Network.getResponseBody拿响应体。这么做的好处是页面渲染的负担被降到最低浏览器只需要执行触发请求的那部分 JS 即可。举个例子一个信息流页面每滚动一次加载 20 条内容接口地址是/api/feed?page1、/api/feed?page2这种。CDP 捕获到page2的响应后我们直接解析 JSON根本不用等节点渲染。实测中这种方式的采集速度比传统“滚动 等元素 提取”快 1.5 到 2 倍而且不容易被页面渲染异常影响。需要注意有些平台的接口返回数据是加密或签名过的这种情况下浏览器里已经解密后的 DOM 反而是唯一可靠的数据源。遇到加密反爬就把 CDP 的定位从“拿接口”切换回“拿 DOM”该渲染的还是要渲染。3.4 场景三翻页提速与页面内脚本调用列表页翻页传统做法是找到“下一页”按钮然后点击一次点击触发一轮完整页面刷新。CDP 能优化掉这个环节先用Runtime.evaluate调用页面自己的翻页函数或者直接改 URL 参数然后在新页面加载时用wait_event监听关键事件省掉大把渲染等待。以搜索列表页为例我可以直接执行cdp.send(Runtime.evaluate, { expression: location.href /search?qiphonepage2, returnByValue: True })当页面开始导航后用Page.loadEventFired事件或者目标接口响应事件判断翻页完成继续抓取。比起点击按钮这个方式少了一步元素查找、少了一次点击带来的额外等待。这里有个非常重要的经验任何一次翻页或导航操作之后CDP WebSocket 连接的 target 不变但页面上下文已经变了。如果你之前注入过脚本Page.addScriptToEvaluateOnNewDocument的注入会继续生效因为它注册在页面生命周期之前。但如果你用字符串拼接的方式执行过 JS那些数据在翻页后会丢所以关键数据要及时落盘。3.5 给所有等待加硬超时第 2 章提过“软等待 硬超时”这一点在真实项目中是保命的。不管是wait_event还是Performance.getMetrics的轮询判断都要设置一个最大等待时间。我在框架里统一封装了一个wait_until函数def wait_until(condition, timeout15, interval0.2): end time.time() timeout while time.time() end: if condition(): return True time.sleep(interval) raise TimeoutError(等待超时)这样做的原因是页面脚本的异常、接口超时、网络抖动都可能让某个环节永久挂起。没有超时兜底整个采集任务就卡死在那里日志还看不出问题。加上超时并记录上下文后至少能定位到具体页面和操作。4. 实战中一定会踩的坑4.1 execute_cdp_cmd 命令没效果或报错Selenium 的execute_cdp_cmd用起来很简单但它有两个典型问题。第一命令名拼写错误或参数结构不对比如把Network.setBlockedURLs写成Network.setBlockedUrl或者参数里的urls传成了字符串列表以外的类型会直接报错并且错误信息比较隐晦。第二一些命令有前置依赖比如Network.getResponseBody必须先Network.enable否则返回错误或空结果。排查经验先直接在 Chrome 开发者工具控制台里用 CDP 命令试一遍确认命令和参数没问题再把代码套回去。另外Chrome 版本和浏览器驱动版本不匹配时部分 CDP 命令会失效尽量保持 Chrome、ChromeDriver、Selenium 三个版本都升级到较新版本。4.2 CDP WebSocket 断连和页面 target 切换爬虫跑上几个小时CDP WebSocket 断线是常态。原因很多页面崩溃、标签页被关闭、Chrome 主进程重启、网络波动。我在框架里加了心跳和重连机制每 30 秒发送一次Page.getNavigationHistory之类的轻量命令如果连续三次没有响应就重建 WebSocket 连接。还有一个常见问题你同时打开了多个标签页CDP 的/json接口会返回多个 page。如果你连接的 target 被关闭了事件就全部丢失。需要在代码里记录当前使用的 tab id页面关闭时重新选择一个稳定的 page target或者干脆固定使用单个标签页采集。4.3 事件消费不及时导致数据丢失CDP 事件是持续推送的WebSocket 接收缓冲区有限。如果你在事件里做了重活比如同步调用Network.getResponseBody、解析大 JSON、写数据库后面的事件就会堆积甚至触发反压。最好的实践是事件回调只做轻量处理把需要的 requestId、URL、时间戳丢进内存队列由专门的消费者线程去取 body、解析、落库。我在一个评论采集项目里就吃过这个亏同步解析 JSON 导致事件积压最终页面加载和事件接收互相拖累整体速度反而没提升。4.4 反爬识别与合规底线页面注入脚本能处理掉一部分自动化特征但反爬不止看navigator.webdriver。请求频率、鼠标轨迹、点击节奏、浏览器指纹都会成为判定依据。我的经验是CDP 注入负责把“自动化”的静态特征抹掉行为层面要靠代码控制节奏——随机延时、单页多次操作模拟真实用户、避免隔几毫秒就连续翻页。爬虫做技术归技术做数据归数据。任何平台的内容都有使用边界建议只抓取自己有权获取的数据比如自己的账号数据、明确授权的站点、公开且允许爬取的接口。高频抓取也要控制并发不要对目标站点造成访问压力。把这些底线守住技术方案才能跑得长久。5. 一些更进阶的玩法5.1 CDP 直接抓 WebSocket 和 SSE 数据页面里如果用 WebSocket 推送实时数据Selenium 很难抓到但 CDP 的网络事件能覆盖 WebSocket 帧。订阅Network.webSocketFrameReceived事件就能拿到服务端推给浏览器的原始数据帧。做直播弹幕、行情推送这类实时内容时这个能力几乎不可替代。5.2 多个 Tab 并行采集CDP 支持Target.createTarget创建新标签页也支持Target.attachToTarget把多个 target 的 CDP 事件汇聚到同一个客户端。配合多线程或 asyncio可以同时控制多个页面采集不同内容。注意每个 target 有独立的 sessionId事件解析时要带上 sessionId 做路由。5.3 把 CDP 和 Playwright 混用虽然标题是 Selenium 结合 CDP但实际生产里也可以用 Playwright 做浏览器控制、CDP 做网络层控制。Playwright 自己封装了一套更现代的 CDP 抽象事件处理更顺手。只是如果你已经有大量 Selenium 用例直接加 CDP 是成本最低的升级路线不必为了换而换。写在最后我还是想强调一个观点CDP 不是银弹它是给 Selenium 这把老枪加了一个瞄准镜。最有效的用法不是把所有逻辑都改成 CDP而是让 CDP 去处理那些 Selenium 本来就不擅长的事情——事件等待、资源屏蔽、早期注入。从我自己的项目数据看把图片和字体屏蔽掉、用网络事件替代固定等待、给所有操作加超时兜底这三件事做完采集链路平均提速能在两倍以上稳定性也会明显变好。如果你刚开始尝试这套方案我建议先从第 3 章的最小框架跑起来选一个页面调通资源屏蔽和网络事件监听再逐步加上你自己的业务逻辑。别一开始就想着把整套 Selenium 全部换掉那样反而容易把简单的问题搞复杂。踩过几次坑之后你会发现爬虫提速的核心其实就一句话能不加载的坚决不加载能不等就等的坚决不空等。