Part 37: Playwright Internals

Test code passes instructions through Playwright’s client and driver to a real browser.

test → client → driver → browser → webpage

Series: Playwright Zero to Expert | Demo app used throughout this series: saucedemo.com

Part 6 promised this discussion would return once you had the foundation to appreciate it — and now, having built and reasoned about real fixtures, real network interception, and a real understanding of the browser/context/page architecture, you genuinely do. This part goes underneath everything you’ve used this entire series: how a line of your test code actually becomes a real action inside a real browser.

Revisiting Selenium’s WebDriver, Now With Real Context

Recall Part 6’s comparison: Selenium communicates through WebDriver, a protocol involving an extra translation layer.

Here’s what that concretely means, now that you understand HTTP properly from Part 17: WebDriver Classic defines command-and-response endpoints. A Selenium client sends commands through a WebDriver-compatible browser endpoint, which performs the browser operation and returns a response. Local and remote deployments can arrange the driver and browser differently, so the older “one separate executable translating every command” picture is useful history but not a universal description of every modern setup.

Each WebDriver Classic action still follows command-and-response semantics, but that does not mean a brand-new network connection must be created for every action. Modern Selenium also supports the evolving WebDriver BiDi standard, which adds bidirectional event streaming over WebSocket for supported capabilities.

Playwright’s Approach — Its Own Protocol and Browser-Specific Integrations

Playwright presents one high-level API while its driver handles browser-specific integration for Chromium, Firefox, and WebKit. It also has a high-fidelity Playwright protocol for client/server connections. CDP is important in the Chromium ecosystem, but Playwright’s official API describes connectOverCDP() as a separate, Chromium-only, lower-fidelity connection compared with the normal Playwright protocol connection.

The exact transport depends on how Playwright is run. A local client and driver can communicate through process pipes, while a remotely launched Playwright browser server can expose a WebSocket endpoint. The durable mental model is not “Playwright always uses one WebSocket”; it is that the Playwright client and driver exchange commands and events through a long-lived protocol channel while the driver manages the real browser processes.

Analogy: Two Interpreters with Different Rulebooks Imagine commanding a pilot to steer a plane:

WebDriver Classic: You speak through a standardized command desk. Each command receives a response, which makes implementations portable across compatible browsers. WebDriver BiDi adds an ongoing event channel for supported bidirectional features.

Playwright Protocol Channel (The Live Walkie-Talkie): You keep an ongoing command-and-event channel with the Playwright driver. The driver coordinates with the selected browser engine and reports relevant browser events back to the client. A remote Playwright server may expose this channel through WebSocket; local execution may use a process pipe.

📊 Visual Flowchart: Two Automation Stacks

Here is a simplified comparison of responsibilities, not a benchmark claiming that one fresh connection is created for every command:

graph TD
    subgraph ModelA ["Model A: Legacy WebDriver Communication Loop"]
        SpecA["1. Test Spec Action: click()"] --> ClientA["2. Send HTTP POST /session/:id/click"]
        ClientA --> Driver["3. WebDriver-compatible browser endpoint"]
        Driver --> EngineA["4. Browser performs operation"]
        EngineA --> ResA["5. Command response returns"]
    end

subgraph ModelB ["Model B: Playwright Client and Driver"]
        SpecB["1. Test Spec Action: click()"] --> Channel["2. Playwright protocol channel<br>(local pipe or remote WebSocket)"]
        Channel --> DriverB["3. Driver and browser-specific integration"]
        DriverB --> EngineB["4. Chromium, Firefox, or WebKit process"]
        EngineB -->|Events and results| Channel
    end

Why does this architectural difference genuinely matter, beyond being interesting trivia? Playwright owns a tightly integrated client, driver, test runner, and supported browser builds, allowing it to coordinate contexts, actions, events, tracing, and network features consistently. The benefit should not be explained as merely avoiding a fresh HTTP connection, because WebDriver implementations can reuse connections and Selenium’s WebDriver BiDi adds bidirectional streaming.

Playwright’s integration supplies the state needed by its actionability implementation. For a click, the locator is resolved and relevant conditions such as visibility, stability, enabled state, and event reception are checked before input is sent. Modern WebDriver tools can also receive events through WebDriver BiDi, so reliability still depends on the framework’s waiting logic and the quality of the test—not transport alone.

Browser Processes

Recall Part 6’s architecture diagram, and the hotel analogy for contexts. One more layer worth being precise about now: when Playwright “launches a browser,” it’s genuinely starting a real, independent operating-system process — the exact same kind of process you’d see if you opened Chrome yourself and looked at your system’s task manager.

This is worth stating directly because it demystifies something that might otherwise feel abstract: there is no meaningful sense in which Playwright is “faking” or “simulating” a browser at any level — it is quite literally running the real thing, as a genuine, real process on your machine (or the CI machine), and talking to it over a real, persistent protocol connection, the same class of connection real developer tools use.

How It Works in a Real Test Run

A Playwright call crosses layers: test code → Playwright client and driver → browser-specific automation transport → real browser process → page target. Events return through the transport so Playwright can coordinate actions, network observation, contexts, and pages.

Do not reduce the comparison to “HTTP is slow, WebSocket is fast.” WebDriver Classic uses command-response semantics, modern Selenium also supports bidirectional WebDriver BiDi, and Playwright’s normal high-fidelity protocol is distinct from the lower-fidelity connectOverCDP option that is available only for Chromium-based browsers.

Current official references

Interview Questions

Q: What is the fundamental architectural difference between how Selenium and Playwright communicate with a browser?

Ans: Selenium standardizes automation through WebDriver Classic and the newer WebDriver BiDi protocol. Playwright exposes its own API and protocol while maintaining browser-specific integrations and supported browser builds. CDP is not the universal Playwright transport: connectOverCDP() is a separate Chromium-only option with lower fidelity than the normal Playwright protocol connection.

Q: What is the Chrome DevTools Protocol, and how does it relate to Playwright?

Ans: CDP is Chromium’s protocol for browser inspection and control, and Chromium DevTools uses it. Playwright can attach to an existing Chromium browser with connectOverCDP(), but official Playwright documentation describes this as lower fidelity than the normal Playwright protocol connection, and CDP connections are not available for Firefox or WebKit.

Q: How does Playwright’s integrated architecture support auto-waiting?

Ans: The locator and action layers repeatedly evaluate the required actionability conditions through Playwright’s browser integration before sending the input action. Event-capable protocol communication helps the driver observe relevant browser state, but auto-waiting should be understood as implemented actionability logic—not as a magical consequence of WebSocket alone.

Q: When Playwright “launches a browser,” what is actually happening at the operating system level?

Ans: A real, independent operating system process genuinely starts — the same kind of process visible in a system’s task manager as if a person had manually opened that browser themselves. Playwright is not simulating or faking a browser in any sense; it launches and controls an entirely real browser process, communicating with it over a real, persistent protocol connection.

Q: Why might understanding this architectural difference matter in a real interview conversation?

Ans: It shows that you can separate protocol, browser integration, actionability logic, and test design instead of repeating “Playwright is faster because WebSocket.” That more accurate model helps you explain both Playwright’s strengths and modern Selenium’s WebDriver BiDi evolution without relying on an outdated comparison.

Exercises — Part 37

Understand: Explain, in your own words, how Playwright’s locator actionability logic, driver, protocol channel, and browser integration cooperate during an auto-waited click. Avoid reducing the explanation to “WebSocket is faster.”

Simple Practice: Draw the local Playwright stack and a remote Playwright-server stack. Mark where a process pipe may be used locally, where a WebSocket endpoint can be used remotely, and why neither drawing means that CDP is the universal protocol for all three browser engines.

Real-World Scenario: Explain, as if to a teammate coming from a Selenium background, why their existing intuition about needing frequent explicit waits might be less necessary in Playwright, tying your explanation directly to the architectural difference covered in this part, not just “Playwright is just better at waiting” as an unexplained assertion.

Challenge: Using Playwright’s official browser and BrowserType.connect() documentation, explain why its supported Firefox and WebKit builds may differ from branded Firefox and Safari, and compare the normal Playwright protocol connection with Chromium-only connectOverCDP().

Next: Part 38 — Custom Extensions

— building your own custom reporters and framework utilities, extending Playwright itself rather than just using it.

Author: TechByteByByte Editorial Team
Reviewed by: TechByteByByte Admin
Published: August 31, 2026
Last reviewed: August 31, 2026