De fleste innlegg om «playwright vs puppeteer» tar utgangspunkt i at én av dem må være den beste løsningen for web scraping. Det er en antakelse som får mye mer kreditt enn den fortjener. Jeg kjørte begge bibliotekene mot nøyaktig de samme sidene — en statisk katalog, en JavaScript-renderert katalog, en artikkel, en ødelagt 500-side, en liten crawl-graf og to offentlige øvingssider — og resultatet var nesten helt identisk. Samme treffrate, samme rendering, samme skjermbilder, samme mangler.
Så dette er ingen kroningsseremoni. På de oppgavene som faktisk avgjør om et browser-automatiseringsverktøy kan scrape en side, skilte ingen av dem seg ut. Det som følger, er den ene reelle forskjellen som bør styre valget ditt, det begge egentlig overlater til deg å bygge, og en merknad om versjonsgapet jeg testet mellom (per 2026-07-09).
Hvorfor sammenligningen faktisk er rettferdig
Sammenligningsinnlegg har ofte en lei tendens til å teste hvert verktøy på ulike sider og deretter kåre en vinner — noe som sier mer om sidene enn om verktøyene. Jeg unngikk det ved å kjøre Playwright og Puppeteer mot den samme lokale fixture-serveren og de samme offentlige demomiljøene, Books to Scrape og Quotes to Scrape, slik at alle tall kunne sammenlignes direkte.
Det er den eneste måten et «uavgjort»-poeng faktisk betyr noe. Hvis testgrunnlaget er ulikt, er uavgjort bare støy. Når det er helt likt helt ned på byte-nivå, sier like resultater noe reelt om verktøyene.
Hva hvert verktøy egentlig er
Puppeteer er et JavaScript-API for å styre Chrome via Chrome DevTools Protocol. Den offisielle beskrivelsen er nettopp det: «a JavaScript API to control Chrome (and experimentally Firefox).» Det er modent, Chrome-fokusert og bygget på Node.
Playwright beskriver seg litt annerledes — som «a framework for Web Testing and Automation» som styrer Chromium, Firefox og WebKit gjennom ett API, med offisielle klienter i JavaScript, Python, Java og .NET. De to deler mye av arvestoffet sitt (Playwright kom fra teamet bak Puppeteer hos Google før prosjektet flyttet til Microsoft), og derfor føles de mer som slektninger enn som rivaler.
Når det gjelder web scraping, oppfører de seg likevel på samme måte. Start en ekte nettleser, åpne en side, la skriptene kjøre, og les deretter den renderte DOM-en. Det er hele grunnen til at du velger en av dem i stedet for en enkel HTTP-parser: du vil ha siden slik den ser ut etter at JavaScriptet er ferdig, ikke det tomme skallet før. Alt nedenfor følger av denne felles mekanismen — og det er også derfor så mye av det de gjør, ender med å bli det samme i praksis.
Resultatene side om side
Her kollapser fortellingen om at «den ene er klart bedre». Samme testgrunnlag, samme tall, på tvers av alt.
| Test | Playwright | Puppeteer |
|---|---|---|
| Statisk katalog (12 produkter) | 12/12, recall 1.0 | 12/12, recall 1.0 |
| Artikkel (tittel + 3 avsnitt) | 3/3, boilerplate separert | 3/3, boilerplate separert |
| Dynamisk JS-side (native rendering) | 8/8 + skjermbilde | 8/8 + skjermbilde |
| Dynamisk JSON API | 8/8, recall 1.0 | 8/8, recall 1.0 |
| Håndtering av HTTP 500 | inspiserbar, ingen exception | inspiserbar, ingen exception |
| Crawl-graf (manuell BFS) | 12 sider, dybder {0,1,2} | 12 sider, dybder {0,1,2} |
| Books to Scrape | 20 produkter | 20 produkter |
| Quotes JS (offentlig) | 10 sitater | 10 sitater |
Begge renderte JavaScript helt naturlig, uten noen spesiell konfigurering. Begge tok fullside-skjermbilder. Begge håndterte 500-feilen ved å returnere et inspiserbart responsobjekt i stedet for å kaste en exception — en liten detalj som betyr mye når du scraper i volum og heller vil logge en dårlig status enn å stoppe hele kjøringen.
En viktig presisering, fordi den er lett å misbruke: dette var observasjoner fra én maskin og én kjøring, ikke benchmarks. Jeg hevder ikke at den ene er millisekunder raskere enn den andre, fordi en stoppeklokke per side på én laptop ikke er en reell hastighetstest. Det jeg hevder, er snevrere og bedre begrunnet: på ekstraksjonsnøyaktighet og renderingsatferd, på tvers av åtte forskjellige sidetyper, var de like. Hvis du håpet at én av dem skulle skille seg ut på en ekte side, gjorde den ikke det.
Den ene forskjellen som bør avgjøre valget
Den virkelige delingen ligger ikke i tallene. Den ligger i omfang.
Playwright styrer tre motorer — Chromium, Firefox og WebKit — gjennom ett API, og leverer førsteklasses klienter i Python, Java og .NET i tillegg til JavaScript. Det er en dokumentert styrke, og jeg vil være presis på ordet «dokumentert»: Jeg testet bare Chromium i denne runden, så jeg rapporterer Playwrights støtte for tre motorer som en oppgitt egenskap jeg ikke verifiserte selv, ikke noe jeg testet direkte. Hvis du må scrape en side som oppfører seg annerledes i Safari sitt WebKit, eller teamet ditt skriver i Python, er den bredden Playwrights sterkeste argument.
Puppeteer er Chrome-først, og her bommer den vanlige kortversjonen. «Kun Chrome» stemmer ikke lenger. Siden Puppeteer v23 har det hatt produksjonsklar Firefox-støtte via WebDriver BiDi, samtidig som det fortsatt bruker CDP for Chrome for å beholde eksisterende automasjoner intakte — et skifte både Chrome for Developers og Mozilla har dokumentert. Versjonen jeg testet (24.16.0) ligger godt forbi v23, så den faktiske kontrasten er ikke «Chrome versus tre motorer». Den er: Puppeteer dekker Chrome (CDP) pluss Firefox (BiDi), men ikke WebKit, og historien om kryssmotor-støtte er nyere enn hos Playwright. Motoren Playwright har, men Puppeteer ikke har, er WebKit.
Det er beslutningen, destillert. Ikke hastighet, ikke nøyaktighet, ikke renderingstrofasthet — de er like. Det handler om omfang: trenger du WebKit-dekning eller klienter i andre språk enn JavaScript, eller er Chrome og Firefox fra Node nok for målene dine? For en stor andel oppgaver innen web scraping er begge gode nok, og du velger ut fra stack-passform snarere enn funksjonsnivå.
Det ingen av dem gjør
Begge verktøyene legger samme oppgave på skrivebordet ditt: crawl-orkestrering. Ingen av dem leverer innebygd køhåndtering, datasett-skriving eller automatisk throttling. Crawl-graf-testen min — følg interne lenker, hold styr på dybde, ikke besøk samme URL to ganger — krevde en håndskrevet breadth-first search i begge tilfeller. Tolv sider, dybder {0,1,2}, min egen BFS, begge ganger.
For noen få sider er det helt greit; en liten BFS er et dusin linjer. For crawling i stor skala — hundrevis eller tusenvis av URL-er med deduplisering, retries og høflige pauser — må du enten bygge den mekanikken selv eller ta i bruk noe som pakker inn disse motorene. Crawlee gjør nettopp det, og gir et reelt crawl-lag over både Playwright og Puppeteer.
Dette er ikke en feil, og jeg vil være presis med hvordan det skal forstås: Playwright og Puppeteer er rammeverk for browser-automatisering, ikke for crawling. Den manglende køen er en avgrensning av ansvarsområde, ikke en bug. Den riktige mentale modellen er at disse verktøyene er «se siden»-halvdelen av en scraper. Du må fortsatt ta med «gå gjennom nettstedet»-halvdelen — skriv den selv, eller koble på et lag som har den.
Oppsett og versjonsforbeholdet
Installeringen er nesten identisk. npm install henter biblioteket pluss en nettleserbinary, og binaryen er den tunge delen — Puppeteer pakker automatisk inn en Chrome-nedlasting (en ren installasjon i min kjøring, uten rapporterte sårbarheter), mens Playwright bruker en egen npx playwright install for sine nettleserbygg. Ingen av installasjonene er smertefulle, men legg inn budsjett for nedlastingen uansett; nettleservekten og per-side-kostnaden er den reelle prisen du betaler for rendering, sammenlignet med et HTTP-only-verktøy.
Så til opplysningen jeg skylder deg. Jeg testet Playwright 1.56.0 mot siste utgave 1.61.1, og Puppeteer 24.16.0 mot npm-latest 25.3.0 — altså en hel major-versjon bak på Puppeteer, alt per 2026-07-09. API-ene jeg brukte er stabile på tvers av disse gapene, så resultatene holder. Men hvis du leser dette en stund etter publisering, bør du teste på nye versjoner før du stoler blindt på eksakte tall. Og for å si det én gang til: Jeg kjørte bare Chromium i Playwright, så jeg påstår ikke noe om Firefox- eller WebKit-paritet utover at det er dokumentert.
Playwright og Puppeteer: fordeler og ulemper
Uavgjort betyr at fordeler og ulemper handler mindre om å vinne, og mer om hva du faktisk forplikter deg til.
Playwright
- Fordeler: dokumentert støtte for tre motorer (Chromium, Firefox, WebKit) gjennom ett API; offisielle klienter for Python, Java og .NET; native JS-rendering med full recall; aktivt videreutviklet bredde.
- Ulemper: ingen innebygd crawl-kø; nettleservekt og per-side-kostnad; bare Chromium ble brukt i denne testen; versjonen jeg kjørte lå bak siste release.
Puppeteer
- Fordeler: moden og stabil Chrome-automatisering over CDP; native JS-rendering med full recall; ryddig håndtering av 500-feil (responsobjekt, ingen exception); stort og velprøvd økosystem; dokumentert Firefox-støtte via WebDriver BiDi siden v23.
- Ulemper: Chrome-først og Node-basert, uten WebKit-motor; ingen innebygd crawl-kø; nettleservekt; versjonen jeg kjørte var en hel major bak npm-latest.
Hvem bør velge hva
Velg Puppeteer hvis du lever i Node, målene dine rendres fint i Chrome (det gjør de fleste), og du vil ha et modent, fokusert bibliotek med et dypt økosystem og én færre kompleksitetsakse å tenke på. Firefox via BiDi-alternativet finnes hvis du vokser inn i det.
Velg Playwright hvis du trenger WebKit-dekning, vil skrive scraperen i Python eller .NET, eller heller vil satse på prosjektet med bredere dekning av motorer og språk. Bare språkpassformen er ofte den tydeligste grunnen til at et Python-team ender på Playwright.
Og et tredje svar som sammenligningsinnlegg ofte hopper over: velg ingen av dem hvis sidene dine egentlig ikke trenger JavaScript for å vise data. Hvis en HTTP-forespørsel og en parser gir deg innholdet, er en headless browser dyr overkill — da er det en annen verktøykategori, og å bruke en ekte nettleser der er bare å bruke minne og oppsettstid uten grunn.
Hvor en managed API passer inn, inkludert Thunderbit
Prøv Thunderbit for webdatauttrekk
Både Playwright og Puppeteer er gratis, open source-biblioteker som du kjører og vedlikeholder selv. Du eier nettlesermiljøet, oppdateringene, crawl-koden du bygger rundt det, og kappløpet mot anti-bot-mekanismer. For mange prosjekter er akkurat det riktig, og ingenting her er et argument mot det.
Men se på hvor mye av den faktiske scraping-jobben som ligger utenfor disse verktøyene. De renderer en side godt; de køer ikke URL-er, de roterer ikke rundt blokkeringer, de gir deg ikke strukturert JSON, og du må holde nettleserflåten i drift. Det er et annet lag i stacken enn en administrert ekstraksjonstjeneste, og det er verdt å si rett ut for utviklere som vurderer å bygge selv kontra å kjøpe. Vår egen Thunderbit-utviklerstack ligger i det andre laget: POST /distill gjør en side om til ren, LLM-klargjort Markdown, og POST /extract returnerer strukturert JSON basert på et skjema du definerer, med JavaScript-rendering, anti-bot-håndtering og CAPTCHA-er håndtert på serversiden i stedet for på laptopen din. Det finnes en Thunderbit MCP-server for AI-agenter og kodeassistenter (der thunderbit_suggest_fields er gratis før du bruker noe som helst), og en CLI via npx @thunderbit/thunderbit-cli for CI og cron.
Jeg kommer ikke til å late som om det er objektivt bedre — det er en annen type avveiing. Med Playwright eller Puppeteer eier du rendering og alt du bygger rundt den, uten kostnad per kall. Med et administrert API flytter du rendering, anti-bot og crawl-plumbing ut, og betaler per forespørsel (i Thunderbits tilfelle målt per kall — én credit for en distill, tjue for en extract — ikke per rad). Lite, selvhostet, og du vil eie nettleseren selv? Da er disse bibliotekene riktige. Skal du skalere, og du vil slippe å drifte en headless flåte pluss en crawler pluss et blokkeringsrotasjonslag? Da fjerner en administrert løsning hele den kategorien arbeid.
For resten av feltet har teamet vårt også testet Crawlees to-motor-tilnærming og en rekke HTTP-first-rammeverk mot de samme fixture-sidene, som er et nyttig neste stopp hvis du allerede har bestemt deg for at en full nettleser er mer enn sidene dine trenger.
Konklusjon
Bør du bruke Playwright eller Puppeteer? For rendering av JavaScript-sider kan du bruke begge — de endte uavgjort på alle testene som faktisk betyr noe her, så du taper ikke funksjonalitet ved å velge ut fra andre hensyn. Velg Puppeteer hvis Chrome og Firefox fra Node passer, og du vil ha modenhet og fokus. Velg Playwright hvis du trenger WebKit-rekkevidde eller klienter utenfor JavaScript.
To ting som sammenligningsinnlegg ofte hopper over, er verdt å ta med seg. For det første er disse to reelt uavgjort på ekte scraping-oppgaver, så ikke bruk energi på et ytelsesgap som ikke dukket opp i åtte ulike tester. For det andre er ingen av dem en crawler — de renderer, og crawling er ditt ansvar eller noe en wrapper som Crawlee tar seg av. Får du klart for deg det, og matcher omfanget med stacken din, blir valget lite. Motorvalget betyr langt mindre enn den halvdelen av jobben som ingen av verktøyene gjør for deg.
Les mer
Prøv Thunderbit for webdatauttrekk Get Started Free
Vanlige spørsmål
Er Playwright eller Puppeteer raskere for web scraping? På identiske testgrunnlag var de i praksis helt like — samme recall på statiske sider (12/12), dynamiske sider (8/8) og JSON-API-ekstraksjon, samme native rendering, samme håndtering av 500-feil. Dette var enkeltkjøringer på én maskin, ikke benchmarks, så små tidsforskjeller per side er ikke en reell hastighetsmåling. Velg ut fra omfang og språk, ikke ut fra et hastighetsgap som ikke dukket opp.
Hva er den faktiske forskjellen mellom Playwright og Puppeteer? Motor- og språkbredden. Playwright styrer Chromium, Firefox og WebKit gjennom ett API, med klienter for Python, Java og .NET. Puppeteer er Chrome-først over CDP, med dokumentert Firefox-støtte via WebDriver BiDi siden v23, men uten WebKit, og det er basert på Node. Begge renderer JavaScript naturlig, og ingen av dem har innebygd crawl-orkestrering.
Kan jeg crawl’e et helt nettsted med Playwright eller Puppeteer? Ikke rett ut av boksen. Ingen av dem har kø, datasett-skriver eller automatisk throttling — crawl-graf-testen min krevde en håndskrevet BFS i begge, tolv sider på dybdene {0,1,2}. For skala bør du legge på et crawl-lag som Crawlee, som pakker inn begge motorene med ordentlig crawl-mekanikk.
Trenger jeg egentlig et nettleserverktøy for scraping? Bare hvis siden trenger JavaScript for å vise dataene. Hvis en HTTP-forespørsel pluss en parser gir deg innholdet du vil ha, er en headless browser dyr overkill — bruk heller et HTTP-first-verktøy og dropp nettleservekten helt.
Hva bør et Python-team velge? Playwright, fordi det har en førsteklasses Python-klient. Puppeteer er Node-basert, så å bruke det fra Python betyr at du må bygge en bro du selv må vedlikeholde. Den språkpassformen er en av de tydeligste enkelgrunnene til å velge Playwright fremfor Puppeteer.
