Playwright Review: JavaScript Rendering on Chromium, With the Crawl Layer Left to You

Playwright is Microsoft's browser-automation framework: an Apache-2.0, TypeScript-first library that launches a real browser, drives it through one API, and hands back the page after its JavaScript has run. It's marketed as an end-to-end testing framework, but the engine underneath is what a lot of people quietly reach for when an HTTP request returns an empty shell where the data should be. In shape it competes with Puppeteer and Selenium — real browsers you script, not HTTP clients you parse.

I ran microsoft/playwright 1.56.0 through a fixed set of scraping tests — a static catalog with pagination, an article, a JavaScript-rendered catalog, a JSON API, a broken 500, a small crawl graph, and two public practice sites — on Node v22.22.3, macOS arm64, Chromium only. The rendering half came back clean. The crawling half doesn't exist, and that gap is the most useful thing to understand about the tool before you commit to it.

What stood out

Two results sit at the top of the pile, and they point in slightly different directions.

The first is the expected browser result, bounded to the waits I used. After page.goto(..., { waitUntil: 'domcontentloaded' }), the dynamic fixture test waited for #dynamic-products article.product-card, and the public Quotes to Scrape test waited for .quote. Those application-specific selectors appeared, after which the runs returned 8/8 fixture items and 10 public-site quotes; the fixture result was recall 1.0 against its eight-item ground truth. No custom polling loop was needed, but Playwright did not eliminate the readiness problem—the test supplied the completion condition. A full-page screenshot also saved on the first call.

The second result used browserContext.request: specifically, ctx.request.get(...) after Chromium had already launched and a browser context existed. It called the fixture's JSON endpoint directly and returned 8/8 products without creating or rendering a page. That skips DOM work, not the browser-process cost in this harness. The context-associated request client can share cookie state with browser pages; a standalone playwright.request.newContext() avoids requiring a browser context but does not automatically share that session. The test covered the former path only.

Playwright also supplies no crawl queue, dataset writer, or automatic throttling. My crawl-graph test — walk internal links, track depth, and avoid revisits — reached 12 pages across depths {0:1, 1:4, 2:7}, but the breadth-first traversal was test code I wrote. Playwright opens and inspects pages; frontier persistence, URL policy, retries, and scheduling belong to another layer.

What Playwright actually is

The tool — microsoft/playwright on GitHub — is written in TypeScript, Apache-2.0 licensed, and maintained by Microsoft. The build tested here was 1.56.0 on July 9, 2026. Results are reported for that build rather than treated as a compatibility statement about later versions.

The official positioning is precise: a framework for web testing and automation that drives Chromium, Firefox, and WebKit through a single API. Playwright's main path is a test runner with fixtures, assertions, and a trace viewer. Using it as a scraping primitive means following the documented Library mode: chromium.launch(), then a context, then a page, outside the test harness. Everything in this review used that public API surface. I did not run a cross-version compatibility test, so this is not a claim that every exercised behavior is stable across releases.

The documented breadth is the headline feature everywhere else, so I'll state it carefully. Playwright drives three browser engines — Chromium, Firefox, and WebKit — through one API, and ships first-class clients in Python, Java, and .NET on top of JavaScript. That is documented, and it's genuinely the tool's widest differentiator in shape. What this pass actually exercised is narrower:

If a target renders differently under Safari's WebKit, or your team writes Python, that breadth is Playwright's argument — just don't take my results as proof of Firefox or WebKit parity, because I didn't test them.

How it works under the hood

The mental model is a browser engine you script. chromium.launch() starts a browser process. A context is an isolated session with its own cookies, storage, and cache; a page is a tab inside that context. You call page.goto(url), wait for the condition that represents application readiness, and read the resulting DOM with helpers such as page.$$eval. This is closer to a user-facing browser than parsing an HTTP response, but it is not environmental parity: headless signals, viewport, locale, fonts, profile state, TLS/network path, and site defenses can still change what is served. This review did not test anti-bot behavior or production-browser parity.

page.screenshot() captures the rendered page, full-page or clipped, which came back working on the first call in my run. And the request API I mentioned — context.request.get — rides the same context's cookies but skips the render, so you can mix "load the page and read the DOM" with "just hit the JSON endpoint" in one script without switching tools.

What isn't under the hood is crawling machinery. There is no request scheduler, persisted visited-set, politeness policy, or export pipeline. A bounded traversal is easy to sketch, but reliable frontier work also needs URL normalization, redirect handling, retries, scope rules, throttling, and recovery. You build that layer or use a framework that wraps the browser engine.

Setup and install reality

Installation is two steps, and the second one carries most of the deployment weight. npm install playwright pulls the library; a separate npx playwright install downloads browser builds (Chromium in my case). Budget disk, download time, browser caching in CI, and process cleanup rather than treating the npm package as the whole runnable system.

If you install Playwright expecting a scraper and follow the testing tutorial, you will start with test files and expect() assertions. Scraping code instead uses the library API directly. Both are documented, but the distinction matters when searching examples and choosing deployment commands.

In this run, the useful ergonomics were concrete: browser contexts isolated session state, async calls composed cleanly, a screenshot took one call, and an HTTP 500 remained inspectable through the response object. The rough edge was operational rather than syntactic: the browser build had to be installed and its lifecycle managed separately from the library.

Hands-on results

Every local number ran against a fixture server on 127.0.0.1 with ground truth written down before the crawl. The exact harness is in run_playwright_material_tests.mjs, and the committed raw artifacts include the ground truth and per-test outputs. These remain author-run observations from one machine and one run; the links expose the reproduction surface rather than turning them into a broad benchmark.

The pagination loop followed the next link explicitly; Playwright did not discover pages on its own. The article selector kept navigation and footer text outside the body result. On the failure route, navigation returned a response object with status 500 instead of throwing, leaving the caller to decide whether to log, retry, or continue. The two public practice targets returned the counts shown in the table.

A boundary worth stating plainly: everything here ran on Chromium, on one machine, once. The capability table marks documented breadth separately from exercised behavior. I did not rerun the suite on another Playwright build, so no cross-version conclusion follows. Per-test timings are also omitted as benchmarks; a single stopwatch pass on one laptop cannot support a speed comparison.

Readiness is part of the extraction contract

The dynamic results depended on waits that represented the data I wanted, not merely browser navigation. For the local catalog, the harness navigated with waitUntil: 'domcontentloaded' and then called waitForSelector('#dynamic-products article.product-card') with a 15-second timeout. The public Quotes JS run used the same navigation state and waited for .quote with a 20-second timeout. Extraction happened only after those selectors appeared.

That distinction matters when adapting the script. domcontentloaded says the initial document was parsed; it does not say that a delayed API response arrived, hydration finished, an infinite list stopped growing, or a virtualized row entered the viewport. A selector is useful when the presence of one matching element is sufficient. If completeness depends on a known response, item count, application state, or quiet network window, wait for that condition instead. The condition should be tied to the output contract: “at least one card exists” and “all expected pages have loaded” are different assertions.

Timeout handling also belongs to the caller. The test used finite selector timeouts, but it did not study retry policy or distinguish a slow page from a permanently changed selector. A production wrapper should record which readiness condition failed, capture enough page state to diagnose it, and decide whether another navigation attempt is safe. Playwright gives you the events and DOM; it cannot infer what “complete data” means for your job.

That boundary should be documented beside every extractor, not left as an implicit timeout.

The API path has a parallel contract. ctx.request.get was appropriate because the browser context already existed and session sharing can be useful. If a job discovers that its data endpoint works without any browser session, a standalone request context is a different architecture with different lifecycle and cookie behavior. This run did not compare the two. Treat “no DOM rendered” as the measured fact, then decide separately whether a browser process is needed by the wider workflow.

The crawl question

The crawl-graph result is the one that decides how you should think about Playwright. Twelve pages, three depths, correct — and every bit of the walking logic was mine. Playwright supplied the "open this URL and read it" half; I supplied the queue, the visited-set, and the depth tracking.

For small, bounded jobs that's a non-issue. For crawl-scale work it means you're either writing a crawler on top of a browser library or pairing Playwright with something that already did. The documented pattern is Crawlee, which wraps Playwright (and Puppeteer) with a real request queue, dataset storage, and auto-throttling — you keep Playwright's rendering and borrow the orchestration. If you want the queue built into the framework itself rather than bolted on, that's Scrapy's whole design, though Scrapy is HTTP-first and doesn't render JavaScript on its own. The point isn't that Playwright falls short; it's that "browser automation" and "crawling" are two jobs, and Playwright only claims one of them.

The twelve-page BFS makes the ownership boundary concrete. It supplied a queue, a visited set, and depth tracking for a controlled graph. A production frontier still has to define URL canonicalization, redirect handling, allowed hosts, duplicate keys, retries, concurrency, per-host delay, persistence, and restart semantics. Export is another choice: the fixture wrote JSON and CSV because the harness did so, not because Playwright provides a dataset abstraction.

Session design also affects the wrapper. One browser can contain multiple contexts with isolated cookies and storage, but this review did not measure parallel-context scale or failure isolation. Reusing a context may preserve a login and reduce setup work; creating separate contexts may prevent state leakage between jobs. Those are crawler-level policies even though Playwright supplies the context primitive. Benchmark the chosen lifecycle with the browser build and deployment environment you will actually run.

Pros and cons

Pros:

• JavaScript execution through a real Chromium engine; both dynamic targets reached the selectors used as readiness conditions.
• Full-page screenshot captured on the first call.
• Selectors extracted the expected static catalog and article fields from the controlled fixtures.
• browserContext.request reached the JSON endpoint without rendering a page, while the already-launched browser process remained part of the harness.
• Robust on a bad response: HTTP 500 was inspectable and navigation didn't throw.
• Documented three-engine support (Chromium, Firefox, WebKit) through one API, plus Python, Java, and .NET clients (documented; only Chromium exercised here).
• Apache-2.0 and maintained by Microsoft.
• Clean developer experience once you're in library mode: one API across engines, first-class async, trivial screenshots.

Cons:

• No built-in crawl queue, dataset, or auto-throttle — crawl-scale work is your code or a wrapper like Crawlee.
• Browser weight: the binary download and per-page cost are the real tax versus an HTTP-only tool.
• The default framing is the test runner; scraping means knowing the library mode exists and stepping off the marketed path.
• Only Playwright 1.56.0 and Chromium were exercised; cross-version and cross-engine parity were not tested.
• No structured-JSON-by-schema output of its own; you write the selectors and shape the data.

Who it's for, and who should skip it

If your problem is rendering pages whose data appears after JavaScript runs, or collecting screenshots alongside DOM data, Playwright is a reasonable candidate to reproduce against your targets. Teams already using Playwright tests can reuse the same concepts and selector skills in library mode. Python, Java, and .NET clients are documented options, but this review exercised only Node and Chromium.

Consider another layer in three cases. If the required data is already present in an HTTP response, an HTTP-first tool avoids browser startup and rendering overhead; Colly is a crawler library in that category, while Trafilatura targets article extraction. If you need queueing, persistence, and throttling, use a crawler framework or Playwright wrapper. If you need schema-shaped output without maintaining selectors, compare managed extraction services. None of those alternatives was benchmarked in this review.

If you're specifically deciding between Playwright and Puppeteer, that's its own head-to-head; our side-by-side comparison runs both through the same fixtures and covers where the choice actually lands.

Alternatives, and where managed extraction fits

Playwright is free, Apache-2.0, and self-hosted. You own browser deployment, selectors, readiness conditions, crawl code, updates, and failure handling. This review did not measure anti-bot performance or compare total operating cost with a managed service.

Within open source, the useful comparisons are by job. For crawl-scale work over a browser, Crawlee adds the queue and dataset Playwright leaves out. If your output goal is LLM-ready Markdown from a real browser rather than hand-shaped rows, Crawl4AI runs a browser and produces Markdown for that pipeline. And if you're weighing several of these at once, our open-source scraper roundup lays the categories out side by side.

Disclosure: Thunderbit is the publisher's product and was not run through this Playwright fixture. It represents the managed extraction category: the service operates the rendering and returns page text or schema-shaped records, while Playwright leaves browser operation and selector logic with the developer. The comparison is therefore hosting model, output shape, and cost model—not a performance result from this review.

Try Thunderbit for Web Data Extraction

Verdict

Use Playwright when your target needs a browser engine and you are prepared to own readiness conditions, selectors, and crawl orchestration. The result table shows that its Chromium library mode handled the controlled static, dynamic, API, screenshot, and failure fixtures as expected in this author-run pass.

Keep the evidence boundary intact: only Chromium and Node were exercised, the 12-page walk depended on a hand-written BFS, browserContext.request skipped page rendering but not the already-running browser process, and every dynamic extraction used a stated readiness selector. Those constraints make Playwright a browser primitive in this review, not a measured end-to-end crawling system.

Try Thunderbit for Web Data Extraction Get Started Free

FAQs

Do I still need waits when scraping with Playwright? Yes. Browser execution does not tell your script when application data is ready. These tests navigated to domcontentloaded and then waited for a target-specific selector before extraction. Production pages may need a different signal, such as a response, locator state, or application event.

Can Playwright crawl an entire website on its own? Not out of the box. There's no built-in request queue, dataset writer, or auto-throttle — my crawl-graph test reached 12 pages across depths {0:1, 1:4, 2:7} only because I wrote the breadth-first search by hand. For crawl-scale work, pair Playwright with Crawlee, which wraps it with a real crawling layer, or use a crawler framework instead.

When should I use browserContext.request versus a standalone request context? Use browserContext.request when HTTP calls should share cookies with pages in an existing browser context. Use playwright.request.newContext() when you want an API-only context without launching a browser and do not need automatic cookie sharing with browser pages. Only the first path was tested here.

Were Firefox and WebKit tested here? No. Every test ran on Chromium, on one machine, single-run. Playwright's three-engine support (Chromium, Firefox, WebKit) and its Python, Java, and .NET clients are documented capabilities I'm reporting as stated, not verified — Firefox and WebKit parity, proxying, parallel scale, and network interception are all outside what these numbers cover.

Which environment did this review cover? Playwright 1.56.0, Node v22.22.3, macOS arm64, and Chromium only. Firefox, WebKit, proxying, parallel scale, anti-bot behavior, and later Playwright versions were outside the run. Installation required the library plus a separate browser-build download.