4Playwright Architecture & Internals

typescriptawait page.click('#submit');

4.1 The big picture: client and server

Playwright is split into two pieces that talk to each other over a single, persistent connection:

1. The Playwright client (your test code) — a Node.js / Python / Java / .NET library that exposes a friendly API (page.click(), expect(locator).toBeVisible(), etc.).
2. The Playwright server (the driver) — a Node.js process bundled inside the same install that knows how to drive Chromium, Firefox and WebKit. It speaks each browser's own remote-debugging protocol.

When you write await page.click('#submit'), the client serialises that command and sends it to the server, which translates it into the browser's native protocol and waits for the result.

4.2 WebSocket + CDP vs Selenium's HTTP/JSON Wire

This is the single most important architecture point an interviewer will probe.

Why this matters for speed and flakiness

• Speed: No per-command TCP+HTTP handshake. A WebSocket frame is tiny (often < 100 bytes overhead).
• Real-time events: Playwright knows the instant a network request finishes, a DOM mutates, or a navigation starts — so its auto-wait has perfect information. Selenium has to poll the DOM.
• No mid-tier driver: Fewer moving parts = fewer version-mismatch failures (chromedriver too old, etc.).
• Isolation: Playwright creates a fresh BrowserContext per test in milliseconds — Selenium typically launches a whole new browser process, taking seconds.

4.3 The Browser → BrowserContext → Page hierarchy

This three-level model is what makes Playwright fast and isolated.

• Browser — the real OS process (Chromium etc.). You usually launch one per test worker. Heavy to start (~1 s).
• BrowserContext — a lightweight, fully isolated "profile" inside that browser. Like an incognito window: its own cookies, localStorage, cache, permissions, geolocation, viewport. Cheap to create (~10–50 ms) — Playwright spins one per test by default. This is why tests don't bleed into each other.
• Page — a single tab inside a context. A test can have multiple pages (multi-tab, popups). Each page has its own frame tree, console, network events.

Code: see the hierarchy

import { chromium } from '@playwright/test';

(async () => {
  // 1. Browser — one OS process, expensive to start
  const browser = await chromium.launch({ headless: false });

  // 2. Two isolated contexts — cheap, parallel-safe
  const userContext  = await browser.newContext({ storageState: 'auth/user.json' });
  const adminContext = await browser.newContext({ storageState: 'auth/admin.json' });

  // 3. Pages inside each context — each is a tab
  const userPage  = await userContext.newPage();
  const adminPage = await adminContext.newPage();

  await Promise.all([
    userPage.goto('https://app.example.com/dashboard'),
    adminPage.goto('https://app.example.com/admin'),
  ]);

  // Cookies / localStorage of the two users never collide.
  await browser.close();
})();

4.4 Auto-wait internals

"Playwright auto-waits" is the headline feature. Here is what actually happens when you call await page.click('#buy'):

1. Resolve the locator. Playwright re-queries the DOM (not a stale cached element) until exactly one matching element is found.
2. Run actionability checks on that element, in a tight loop, until all pass — or the action timeout (default 30 s) expires:
   • Element is attached to the DOM
   • Element is visible (non-zero size, not display:none or visibility:hidden)
   • Element is stable (not animating — same bounding box for two consecutive frames)
   • Element receives events (no other element on top via hit-testing)
   • Element is enabled (no disabled attribute on form controls)
3. Scroll into view if needed.
4. Perform the action at the element's center using real input events (CDP Input.dispatchMouseEvent — not JS click).
5. Wait for the event loop to settle (no pending navigation triggered by the click).

4.5 Why Playwright is faster and less flaky

4.6 Playwright vs Selenium vs Cypress (honest)

4.7 First test — proves the architecture

// tests/architecture.spec.ts
import { test, expect } from '@playwright/test';

test('one browser, two isolated users at once', async ({ browser }) => {
  // Two contexts share the same browser process — fast
  const ctxA = await browser.newContext();
  const ctxB = await browser.newContext();
  const pageA = await ctxA.newPage();
  const pageB = await ctxB.newPage();

  await pageA.goto('https://example.com');
  await pageB.goto('https://example.com');

  // Set cookies independently — they don't collide
  await ctxA.addCookies([{ name: 't', value: 'A', url: 'https://example.com' }]);
  await ctxB.addCookies([{ name: 't', value: 'B', url: 'https://example.com' }]);

  expect((await ctxA.cookies())[0].value).toBe('A');
  expect((await ctxB.cookies())[0].value).toBe('B');

  await ctxA.close();
  await ctxB.close();
});

typescript — wrong vs right// WRONG — no await, test races ahead
page.click('#submit');
expect(page.url()).toBe('/success'); // URL hasn't changed yet!

// CORRECT
await page.click('#submit');
await expect(page).toHaveURL('/success');

playwright.config.tsuse: {
  channel: 'chrome',   // uses installed Google Chrome
  // or:
  channel: 'msedge',   // uses installed Edge
}

typescript// page.evaluate — runs in the browser, returns a serialisable value
const title = await page.evaluate(() => document.title);

// locator action — runs via CDP, with actionability checks
await page.getByRole('button', { name: 'Submit' }).click();

playwright.config.ts — global defaultuse: {
  baseURL: 'https://staging.example.com',
}

tests/admin.spec.ts — override for this file onlyimport { test, expect } from '@playwright/test';

test.use({ baseURL: 'https://admin.example.com' });

test('admin dashboard loads', async ({ page }) => {
  await page.goto('/dashboard'); // resolves to https://admin.example.com/dashboard
  await expect(page).toHaveURL(/dashboard/);
});

4.9 Playwright versioning, release cadence & what's new (interview-ready)

4.9.1 Your version — 1.61.0 (Nov 2025)

Across this workspace, every Playwright project resolves @playwright/test to 1.61.0. Some package.json files declare older minimums (^1.43.0, ^1.45.0) but the caret allows minor/patch upgrades, so the lock files all settle on 1.61.0.

# Verify quickly
npx playwright --version          # Version 1.61.0
npm ls @playwright/test           # shows resolved version
node -p "require('@playwright/test/package.json').version"

4.9.2 Release cadence

• Minor releases roughly every 4–6 weeks (1.40, 1.41, 1.42 …). Each ships features + browser-binary updates.
• Patch releases (1.61.x) come for bug fixes / security only — safe to take automatically.
• No LTS branch — Playwright doesn't backport. If you find a bug, upgrade to the latest minor or use a workaround.
• Browser binaries are pinned to a Playwright version. npx playwright install downloads the exact Chromium/Firefox/WebKit builds the library was tested against.

4.9.3 Feature timeline (memorise the headline features per version)

4.9.4 What to do before upgrading (the checklist)

1. Read the release notes — github.com/microsoft/playwright/releases. Most upgrades are zero-change; some (1.40 → 1.41) tweaked default timeouts.
2. Match the Docker tag — bump mcr.microsoft.com/playwright:v1.61.0-jammy in your CI and the npm version in the same PR. Mismatched versions cause "works locally, breaks in CI" failures.
3. Pin exact in CI — drop the caret: "@playwright/test": "1.61.0" in package.json. Use npm ci, not npm install.
4. Re-run npx playwright install --with-deps — browser binaries are version-locked.
5. Re-record visual baselines if you have toHaveScreenshot snapshots — browser binaries changing pixel-shift fonts slightly is the most common silent breakage.
6. Run on one CI shard first, not all 8 simultaneously — to spot version-incompatibility before you waste a full pipeline.

4.9.5 Common interview prompts about version (and how to answer)