Chrome headless mode: selecting implementation for zero‑downtime migration

Goal

Run smoke tests for a small web application in a CI pipeline while keeping user traffic uninterrupted.

Constraints

• CI images must pin a stable Chrome version to avoid surprises during a migration.
• Memory and CPU consumption are critical when scaling parallel test runs.
• Security isolation is required; containers may need --no-sandbox but this weakens protection.

Unresolved Decision

The new --headless=new implementation offers near‑headed fidelity but consumes more resources, whereas the legacy headless path (removed in recent releases) was lighter but lacked some rendering features. Chrome for Testing provides a pinned distribution aimed at automation but its behavior relative to the regular Chrome binary is still being clarified in the context of a zero‑downtime migration.

Questions

1. For a migration rehearsal that must avoid user‑visible downtime, should the CI pipeline use the new headless implementation or rely on Chrome for Testing to achieve the closest parity with production?
2. What flag combinations (e.g., --disable-gpu, --dump-dom, --remote-debugging-port) best balance fidelity, resource usage, and security in this scenario?
3. How can we validate that the chosen headless mode reproduces rendering and network behavior identical to a headed browser before traffic is switched?