#3 - Playwright Architecture

Playwright Architecture (vs Selenium) — Key Tech Concepts

Selenium communication model (review / recap)

• Test code (e.g., Java/JS) sends actions to the Selenium server using HTTP requests.
• Each action like findElement, get, screenshot, etc. typically involves:
  • opening/using a request
  • receiving an HTTP response
  • effectively terminating the connection
• Result: many separate request/response cycles → overhead and slower performance for large test suites.

Playwright communication model

• Playwright still uses JSON as the message payload/protocol format (similar idea to Selenium).
• Instead of repeated HTTP request/response cycles, Playwright uses a persistent connection via WebSocket.
• After an initial handshake / connection establishment, the Playwright server stays up in the background.
• The client can send back-to-back commands without terminating the connection each time.
• The speaker argues this makes Playwright faster than HTTP-based automation tools (like Selenium).

Why WebSocket matters

• HTTP is described as request/response with connection termination after each request (introducing asynchronous overhead).
• WebSocket is described as long-lived and bi-directional, allowing continuous command/response flow over the same channel.
• WebSocket usage is compared to patterns like:
  • chat applications
  • long-lived real-time systems (examples mentioned: trading/mining-style live interactions)
• WSS is referenced as the secure WebSocket equivalent of HTTPS.

Remote execution mention

• Selenium remote drivers: includes using:
  • a hub URL
  • desired capabilities
  • (speaker also mentions remote using https in that context)
• Playwright remote execution: connects over a WebSocket URL (using wss) to a remote/cloud machine (example mentioned: “solenoid/moon or any other cloud machine”).

Browser side architecture

• Playwright supports multiple browser engines/vendors, including:
  • Chrome/Chromium
  • Firefox
  • WebKit
  • Safari
• The diagram described: one Playwright server communicates with the selected browser to perform actions.

Internal Playwright API flow (light internal reference)

• The example function playwright.firefox.launch() is said to:
  • start the Playwright side / establish the connection
• Internally, the speaker references a flow like:
  • sending a message via an internal sendMessage mechanism over the connection
  • receiving responses back as JSON
  • responses represented in code as waitable/promise-like results

---

What this video is emphasizing

Core architectural takeaway: Playwright uses WebSocket for a persistent, fast client-server channel while still using JSON message formats, reducing overhead compared to Selenium’s more HTTP request/response-heavy pattern.

---

Main speaker / sources

• Speaker: “navini” / “naveen automation labs” (the presenter calls themself Navini)
• External sources: Multiple diagrams are stated to be taken from Google.