ego (lite) é só um navegador, ego é o seu agente pessoal em qualquer dispositivo.
Entrar na lista de espera
PlaywrightPuppeteerWeb scrapingBrowser automationBenchmarks

Playwright vs Puppeteer for Web Scraping: Benchmarks and Verdict

13 de ago. de 20269 min read

The short answer, before anything else: neither tool is faster overall, and the speed debate shouldn't decide your scraping stack. What separates them is API design (Playwright's auto-waiting and 50x-faster typing), the stealth ecosystem (the current anti-detection forks support Playwright only), and browser coverage (three engines and five languages against Chrome-first JS).

On authenticated scraping both hit the same wall: fresh profiles and scripted logins. When the data sits behind your own accounts, that's the job ego (lite) covers, free: every site you've signed into stays signed in, and your agent scrapes from inside that state in an isolated Space that never touches your window.

Ask r/webscraping to pick between Puppeteer and Playwright and you get a genuine split: "for large-scale scraping, Puppeteer usually wins, for complex flows, Playwright" sits right next to "I'd lean toward Playwright, it's just more stable overall."

Both camps are reporting real experience. The tools are siblings (Playwright was started by ex-Puppeteer engineers), their APIs rhyme, and raw speed differences mostly cancel out.

What are Playwright and Puppeteer, and who's behind them?

Puppeteer is the Chrome DevTools team's browser automation library, shipped by Google in 2017: JavaScript/TypeScript, Chrome-first, with Firefox support in beta via WebDriver BiDi and no WebKit. It has 94K+ GitHub stars and the longest scraping track record in the category.

The puppeteer/puppeteer GitHub repository: JavaScript API for Chrome and Firefox, 95.5k stars, commits from yesterday
puppeteer/puppeteer at the time of writing: 95.5k stars, 6,472 commits, changes landing daily. The About line ('JavaScript API for Chrome and Firefox') is also the scope statement: no WebKit, no other languages.

Playwright is Microsoft's 2020 follow-up, built by engineers who previously built Puppeteer: Chromium, Firefox, and WebKit with full parity, official APIs in JavaScript, TypeScript, Python, Java, and C#, and 90K+ stars of its own. Same lineage, wider surface.

The microsoft/playwright GitHub repository: framework for Web Testing and Automation covering Chromium, Firefox and WebKit with a single API
microsoft/playwright, whose About line makes the opposite scope statement: Chromium, Firefox and WebKit with a single API. The three-engine claim is the durable difference; the star counts are within a few percent of each other.

That shared ancestry is why switching costs are low: practitioners point out the APIs are similar enough that a thin facade lets purpose-built scrapers swap between them cheaply. Which means the differences that remain are the ones that were designed on purpose, and those are the ones worth reading closely.

What do the timed benchmarks actually show?

The most useful public benchmark ran Puppeteer 24.43 and Playwright 1.59 through identical operations on identical cloud browsers, reporting medians over 10 runs. Read the bars, then the explanation, because the biggest number is misleading on its own.

Median operation times: Puppeteer vs Playwright (ms)

Lower is better; medians over 10 runs on identical remote browsers

Screenshot: Puppeteer
276 ms
Screenshot: Playwright
836 ms
Navigate + load: Puppeteer
945 ms
Navigate + load: Playwright
582 ms
Type 19 chars: Puppeteer
12,963 ms
Type 19 chars: Playwright
255 ms
Source: testmuai.com timed benchmark of Puppeteer 24.43.1 vs Playwright 1.59.1, medians of 10 runs per operation on identical cloud-hosted browsers, 2026. Connection setup (not shown): Puppeteer ~8.1s vs Playwright ~11.1s.

The benchmark's own verdict: neither is faster overall. Puppeteer connects about 3 seconds quicker and screenshots in a third of Playwright's time; Playwright navigates faster and wins interactions hugely. Medians over repeated runs matter here, because single-run comparisons in this space routinely flip on network noise.

And that 50x typing gap deserves its asterisk: it's API design, not engine speed. Puppeteer's page.type() sends one round trip per character (brutal against a remote browser), while Playwright's fill() sets the value in a single call. Local scraping shrinks the gap; remote browser farms amplify it. For scraping specifically, the lesson is that your operation mix and your browser's location matter more than the logo.

Benchmarks measure APIs, not brands.

Which differences decide scraping outcomes?

Three dimensions do the real deciding, and the table states each tool's limit alongside its strength.

DimensionPuppeteerPlaywright
Waiting behaviorExplicit: you write waitForSelector calls, and omissions become flaky scrapersAuto-waiting with actionability checks (attached, visible, stable, enabled) before every action
Stealth ecosystempuppeteer-extra-plugin-stealth is the mature classic; masks webdriver flags and headless markersplaywright-extra ports the classics, and the current generation (Camoufox, Patchright) supports Playwright only
CoverageChrome-first, JS/TS only; Firefox beta with incomplete parity, no WebKitThree engines, five official languages; Microsoft maintains patched Firefox/WebKit builds

One more scraping-relevant difference the table can't hold: parallelism. Playwright's browser contexts give you dozens of isolated, cookie-separated sessions inside one browser process, which is the cheap way to run a scraper fleet; Puppeteer has incognito contexts too, but the ergonomics and per-context isolation guarantees are a step behind, and most large Puppeteer fleets end up managing whole browser processes instead.

If your roadmap says "200 concurrent sessions," that's a Playwright point before you've written a line.

Which should you use for scraping?

By scenario, matching where each tool's design actually pays:

Pick Puppeteer when the job is Chrome-only, high-volume, and screenshot- or PDF-heavy: its connection speed and screenshot times compound at scale, and its stealth classic is battle-worn.

Pick Playwright when flows are complex or dynamic (auto-waiting removes the largest class of scraper flakiness), when you need Firefox or WebKit coverage, when your team writes Python or Java, or when your anti-detection plan involves the current fork generation.

If you're starting from zero in 2026 with no constraint pushing either way, Playwright is the safer default; the ecosystem's center of gravity, including the stealth tooling, has been moving its direction.

A worked example of the split: a price monitor screenshotting 500 product pages nightly on Chrome is a Puppeteer-shaped job (captures dominate, flows are trivial).

A job-listing aggregator navigating search filters, infinite scroll, and modal dialogs across 30 sites is Playwright-shaped (interaction-dense, flake-prone, benefits from auto-waiting and contexts). Most teams' scraping portfolios contain both shapes, which is why both tools are still here.

What about scraping behind logins?

Here both tools hand you the same homework: they launch clean browser instances, so authenticated scraping means scripting logins, persisting cookies, and re-doing it when 2FA or session expiry breaks the script. Correct for scraping other people's sites at scale with test accounts; pure overhead when the data you want sits behind your own logins (your vendor portals, your dashboards, your communities).

That second case is what ego (lite) is for. It's a free browser built for sharing your logged-in browser state with AI agents like Claude Code and Codex: every site you've signed into stays signed in, and your agent scrapes from inside that state by writing JavaScript through the ego-browser skill, whole workflows running outside the model's context, in an isolated Space that never touches your window.

Here's that CLI call run for real, against a live page, today: a task space opens, navigates, and hands back exactly the fields asked for, not a page dump. The page below is public rather than login-gated, so it can't show the session-inheritance part directly, but the shell call and the compact, targeted return are the same mechanism a scrape against a signed-in portal would use.

ego-browser nodejs <<'EOF'
const task = await egoBrowser.newTaskSpace('evidence-egobrowser-hn')
console.log({ taskSpaceId: task.id })

await task.page.goto('https://news.ycombinator.com/', { waitUntil: 'load', timeout: 20000 })
const title = await task.page.title()
const topStory = await task.page.locator('.athing .titleline > a').first().innerText()
const points = await task.page.locator('.subtext .score').first().innerText().catch(() => null)
console.log({ title, url: task.page.url(), topStory, points })
EOF

# Real output:
{
  "taskSpaceId": 13
}
{
  "title": "Hacker News",
  "url": "https://news.ycombinator.com/",
  "topStory": "Qwen 3.8 27B",
  "points": "412 points"
}

No login scripting, no cookie maintenance, and because it's a real daily browser rather than a fresh automation profile, the empty-profile and no-history signals that flag new automation browsers don't apply.

It won't replace Puppeteer or Playwright for scale-out public scraping in CI; it replaces the auth-maintenance half of your scraping life.

See ego (lite) vs Puppeteer or ego (lite) vs Playwright, or download ego (lite) for Mac, free.

FAQ

Is Playwright faster than Puppeteer?

Not overall. On timed medians, Puppeteer connects faster (~8.1s vs ~11.1s) and screenshots faster (276ms vs 836ms), while Playwright navigates faster (582ms vs 945ms) and completes form interactions dramatically faster. Your operation mix decides which wins for you.

Which is better for avoiding bot detection?

Puppeteer has the most battle-tested classic (puppeteer-extra-plugin-stealth); the newer anti-detection forks practitioners currently reach for, Camoufox and Patchright, support Playwright only. Neither escapes the shared ceiling: CDP-level detection by Cloudflare-class systems catches both.

Can I use Puppeteer with Python?

Not officially. Pyppeteer is an unofficial port that lags releases with inconsistent maintenance; Playwright ships an official Python API with full feature parity, which is the practical answer for Python scraping teams.

Which is better for large-scale scraping?

Practitioner opinion splits, and the honest synthesis is: Puppeteer for high-volume single-browser Chrome fleets where its lighter footprint and faster captures compound, Playwright when scale means many isolated parallel sessions (browser contexts) or many sites with complex flows. Measure your own bottleneck operation before committing either way.

Is Puppeteer still actively maintained?

Yes: it's maintained by Google's Chrome DevTools team and tracks Chrome releases closely, with 94K+ GitHub stars and steady releases. "Playwright is winning the agent-tooling layer" and "Puppeteer is dying" are different claims; only the first is true.

Do Playwright or Puppeteer work for scraping logged-in sites?

Yes, with scripted logins and persisted storage state that you maintain forever. For sites where the login is your own, inheriting a real browser's sessions (ego (lite)'s model) removes that maintenance; keep the scripted approach for test accounts and third-party targets.