Selenium and Playwright vs Request-Layer Automation

Where Selenium and Playwright shine

Browser automation tools are excellent at testing web applications. You own the application, you control its deployment, and you need to verify that your UI behaves correctly from the user's perspective. Selenium and Playwright excel here — they can drive any browser, simulate user interactions precisely, and integrate with CI/CD pipelines.

They're also good for scraping public websites where you don't control the output and need to parse rendered HTML. If the data is only accessible via JavaScript rendering and there's no underlying API to call, a browser automation tool is the right choice.

Where they break down

Enterprise portals are the hard case. Here's the specific failure pattern:

Bot detection. Enterprise portals — carrier systems, insurance platforms, government services, ERP web interfaces — increasingly deploy bot detection. Selenium-driven browsers have tell-tale signatures: navigator.webdriver is set to true, Chrome's automation-controlled banner appears, timing patterns differ from human behavior. Modern bot detection catches these. The portal blocks the automation, often without a clear error, and teams spend days troubleshooting what looks like a flaky test.

Dynamic element IDs. Many enterprise applications generate element IDs dynamically — the button you located by ID yesterday has a different ID today. CSS selectors break when developers rename classes for seemingly cosmetic reasons. XPath selectors break when the DOM structure shifts. The automation works in development, breaks in production after the next release.

SSO and MFA flows. Enterprise auth is hard for browser automation. SAML flows involve redirects, form posts, and token exchanges that Selenium can navigate but requires careful handling. MFA breaks unattended automation entirely — unless you maintain a session manually, which defeats the purpose.

Speed and scale. A headless browser still executes JavaScript, renders the DOM, and waits for visual completion. A 10-step workflow might take 45-90 seconds. Running this at scale requires managing a browser pool — memory-intensive, operationally complex.

The request-layer alternative

Every Selenium or Playwright script is ultimately trying to trigger the same HTTP requests the browser would send. The browser is the intermediary. When you click a button, Playwright clicks a button, which triggers an event handler, which sends an HTTP request. You could skip the browser and send the HTTP request directly.

This is request-layer automation: capture the HTTP traffic from a real user session, understand the sequence and the parameters, and replay that traffic directly without a browser. The server receives the same requests it always receives — it can't tell the difference.

The benefits are concrete: execution speed drops from 45-90 seconds to 3-8 seconds for the same workflow. Bot detection is bypassed entirely because there's no browser to fingerprint. Session management is explicit and reliable — you know exactly what cookies and headers the requests need. Scale is just HTTP concurrency, not browser pool management.

When to still use Playwright

Playwright remains the right choice when the application depends on client-side state that doesn't manifest in server requests — local storage interactions, canvas-based UIs, WebRTC applications. And for test automation of your own applications, Playwright's debugging tools and test report integration are worth the overhead.

For automating third-party enterprise portals at production scale, request-layer automation is almost always faster to build, faster to run, and cheaper to maintain.