Chrome headless mode: selecting implementation for zero‑downtime migration

Recommendation

Use Chrome for Testing as the distribution and run it with --headless=new as the mode. These are not competing choices: Chrome for Testing (CfT) is a version-pinned binary built for automation, while --headless=new selects the headless implementation that shares the full browser engine with headed Chrome. Together they give you the closest production parity your rehearsal can achieve, with a pinned version that will not shift mid-migration.

Why this combination

The legacy headless mode was a separate, lighter implementation with known rendering differences, and it has been removed from recent Chrome releases, so it is not a viable migration target. The new headless mode exercises the same rendering and network stack as headed Chrome, which is what "parity with production" actually means. CfT removes the other risk: a regular Chrome install auto-updates, and an update landing between rehearsal and cutover invalidates your validation. Pinning a CfT version in the CI image (verify with google-chrome --version or the CfT binary's equivalent) keeps the rehearsal and the cutover on identical bits.

Flag choices

• --headless=new — full-engine fidelity.
• --disable-gpu — standard in Linux containers without GPU access; historically required on some setups and still a safe default for headless CI. It does not change DOM or layout results in software rendering.
• --remote-debugging-port — needed if you drive the browser via CDP (Puppeteer/Playwright) or want to capture traces during rehearsal. Omit it for simple --dump-dom smoke checks.
• --no-sandbox — avoid if possible. Prefer a container runtime that allows the sandbox (unprivileged user namespaces enabled, or a seccomp profile permitting Chrome's syscalls). If your CI kernel forbids it, --no-sandbox is a common fallback, but only run tests against content you control, never arbitrary user-submitted pages.

Validating parity before switching traffic

1. Run the same smoke suite against a staging copy of production in both headed Chrome and --headless=new at the same pinned version.
2. Diff screenshots pixel-wise (with a small tolerance) and compare serialized DOM from --dump-dom for key routes.
3. Capture a network trace over CDP in both modes and compare request URLs, headers, and ordering; pay attention to anything driven by feature detection (WebGL, codecs, service workers).
4. Measure memory/CPU per parallel worker; the new headless mode is heavier than legacy, so resize CI concurrency limits before scaling up.

Assumptions and uncertainty

This assumes a current Chrome release (roughly 2024 or later) where legacy headless is gone and --headless=new is the default headless behavior. Flag names and defaults have shifted across releases, so confirm against the exact pinned version's --help output and release notes before locking the image. The one detail that could change this advice: if your production users are on a materially older Chrome, pin CfT to that version rather than the latest, since parity with your users matters more than parity with the newest release.