Playwright vs CDP: A Comparison of Browser Control Approaches
Question
For OpenClaw, what’s the difference between controlling the browser via Playwright and via RDP (actually CDP) tools?
Answer
A quick clarification
RDP (Remote Desktop Protocol) is Windows’ remote desktop protocol. In the context of browser control, what’s actually meant is CDP (Chrome DevTools Protocol) — the Chrome remote debugging protocol that communicates over port 9222 (the Remote Debugging Port).
Core differences
1. Level of abstraction and control granularity
| Approach | How it works | Analogy |
|---|---|---|
| Playwright (high-level wrapper) | Sends commands like “click the Login button,” automatically locating elements, waiting, computing coordinates, and simulating the mouse | An autonomous driving system |
| CDP (low-level protocol) | Sends raw JSON messages directly; you first fetch the DOM tree to find the node ID, then send Input.dispatchMouseEvent | Directly controlling the steering wheel and gas pedal |
2. Impact on AI “vision” and DOM parsing (the key difference)
- Playwright approach: Relies on injected JavaScript to traverse DOM elements and compute Bounding Boxes, easily blocked by complex CSS or Shadow DOM
- CDP approach: Directly calls Chrome’s underlying Accessibility Tree, precisely obtaining the coordinates and hierarchy of every interactive element, unaffected by front-end code
The most advanced Web Agents today (such as Claude Computer Use or MCP-based implementations) rely heavily on CDP to obtain spatial information about the page.
3. Browser takeover and stealth (anti-scraping)
| Approach | Characteristics |
|---|---|
| Playwright | Launches a clean new browser instance by default, carries the webdriver flag, easily detected as a bot |
| CDP connected directly to the host | Connects to a real Chrome Profile via host.docker.internal:9222, carrying long-lived cookies and a normal fingerprint — extremely stealthy |
4. Runtime overhead and dependencies
| Approach | Resource consumption |
|---|---|
| Playwright | Requires installing the bulky Playwright dependency libraries and browser engine packages inside the container — large container size, high memory usage |
| CDP | Only needs a lightweight WebSocket client (such as chrome-devtools-mcp); all rendering computation happens on the host |
Summary comparison
| Dimension | Playwright approach | CDP approach (DevTools MCP) |
|---|---|---|
| How it works | High-level API, automatically handles waiting, finding, and clicking | Low-level WebSocket, raw JSON messages |
| Best suited for | Fixed automation scripts, silent background operation | AI taking over the current screen, complex precise coordinate-mapping tasks |
| Taking over an existing browser | Supported (connectOverCDP), not the default design | A perfect fit — designed for exactly this |
| Container resource consumption | High | Very low |
| Anti-scraping risk | Relatively high (unless Stealth is specifically configured) | Relatively low (borrows a real user’s fingerprint) |
Conclusion
For the scenario where OpenClaw directly operates the host browser’s main Profile, connecting via the CDP (DevTools MCP) protocol to port 9222 is the optimal choice:
- Perfectly reuses existing cookies to skip login
- The Accessibility Tree lets the AI understand web page structure more accurately
- Extremely low resource usage, and the strongest stealth
In essence: Playwright is a high-level, ready-made tool, while CDP is the browser’s low-level “machine language.”