16.4Era 3: Chrome DevTools Protocol — CDP (2017-present)

How It Worked

Chrome exposed its developer tools interface as a WebSocket API. Puppeteer (Google) and Playwright (Microsoft) built on this.

Test Script ──WebSocket──► Chrome (DevTools)

What CDP Enabled

// Bidirectional: Browser pushes events
{"method": "Console.messageAdded", "params": {"message": {"text": "error!"}}}

// Network interception
{"method": "Network.requestWillBeSent", "params": {"request": {"url": "..."}}}

// DOM manipulation
{"method": "DOM.getDocument", "params": {}}

// Performance profiling
{"method": "Performance.getMetrics", "params": {}}

Advantages Over WebDriver

• Bidirectional: Events push from browser to client
• Rich: Network, performance, DOM, coverage, accessibility
• Fast: WebSocket is lower overhead than HTTP

Problems

• Chrome-only: CDP is Chrome's internal protocol
• Unstable: Google can change it without notice (it's "internal")
• Browser-specific: Playwright had to write separate backends for Firefox, WebKit
• Vendor lock-in: Your tests depend on a Google-controlled protocol

Playwright's Workaround

Playwright abstracts CDP (Chrome), a patched Firefox protocol, and WebKit's debugging protocol behind a unified API. This is impressive engineering but creates a maintenance burden — Playwright must track internal changes in three browsers.