Většina článků typu „playwright vs puppeteer“ vychází z předpokladu, že jeden z nich musí být lepší nástroj na web scraping. To je ale rámování, které si nezasloužilo, aby bylo bráno jako samozřejmost. Obě knihovny jsem poslal přes úplně stejnou sadu stránek — statický katalog, katalog vykreslovaný přes JavaScript, článek, rozbitou chybu 500, malý crawl graf a dvě veřejné tréninkové weby — a výsledky byly prakticky k nerozeznání. Stejné pokrytí, stejné vykreslení, stejné screenshoty, stejné mezery.
Takže tohle není korunovace vítěze. U úloh, které ve skutečnosti rozhodují o tom, zda nástroj pro automatizaci prohlížeče zvládne stránku scrapeovat, ani jeden z nich neujel dopředu. Níže najdete jediný skutečný rozdíl, který by měl ovlivnit váš výběr, tedy tu část, kterou si oba nástroje tiše nechávají na vás, a také poznámku k verzi, se kterou jsem testoval (k 2026-07-09).
Proč je to srovnání vůbec fér
Srovnávací články mají ošklivý zvyk testovat každý nástroj na jiných stránkách a pak vyhlásit vítěze — čímž vám toho řeknou víc o těch stránkách než o nástrojích. Tomu jsem se vyhnul tím, že jsem Playwright i Puppeteer spustil nad stejným lokálním testovacím serverem a stejnými veřejnými demo weby, Books to Scrape a Quotes to Scrape, takže všechna čísla sedí sloupec po sloupci.
Jedině tak má tvrzení o „remíze“ nějakou váhu. Když se testovací podklady liší, je remíza jen šum. Když jsou ale na byte přesně stejné, shodné výsledky vypovídají něco o samotných nástrojích.
Co je každý z těch nástrojů zač
Puppeteer je JavaScriptové API pro ovládání Chromu přes Chrome DevTools Protocol. Jeho oficiální popis je přesně takový: „JavaScript API pro ovládání Chromu (experimentálně i Firefoxu).“ Je to zralý, na Chrome zaměřený nástroj pro Node.
Playwright se definuje trochu jinak — jako „framework pro webové testování a automatizaci“, který přes jedno API ovládá Chromium, Firefox a WebKit, a nabízí oficiální klienty v JavaScriptu, Pythonu, Javě i .NET. Oba nástroje vycházejí ze stejné linie (Playwright vznikl z týmu kolem Puppeteeru v Googlu, než přešel pod Microsoft), proto působí spíš jako příbuzní než jako rivalové.
Pro web scraping se ale chovají stejně. Spustíte reálný prohlížeč, otevřete stránku, necháte doběhnout skripty a pak načtete vykreslený DOM. Právě proto po nich sáhnete místo HTTP parseru: chcete stránku až po provedení JavaScriptu, ne prázdnou skořápku před ním. Všechno níže vychází z tohoto společného mechanismu — a právě proto se u tolika věcí nakonec ukáže, že je to v podstatě nerozhodně.
Výsledky vedle sebe
Tady se nenápadně rozpadá příběh o tom, že „jeden je jasně lepší“. Stejné podklady, stejná čísla, ve všech testech.
| Test | Playwright | Puppeteer |
|---|---|---|
| Statický katalog (12 produktů) | 12/12, recall 1.0 | 12/12, recall 1.0 |
| Článek (titulek + 3 odstavce) | 3/3, oddělený boilerplate | 3/3, oddělený boilerplate |
| Dynamická JS stránka (nativní vykreslení) | 8/8 + screenshot | 8/8 + screenshot |
| Dynamické JSON API | 8/8, recall 1.0 | 8/8, recall 1.0 |
| Zpracování HTTP 500 | lze prozkoumat, bez vyhození výjimky | lze prozkoumat, bez vyhození výjimky |
| Crawl graf (ručně napsané BFS) | 12 stránek, hloubky {0,1,2} | 12 stránek, hloubky {0,1,2} |
| Books to Scrape | 20 produktů | 20 produktů |
| Quotes JS (veřejný web) | 10 citátů | 10 citátů |
Oba nástroje vykreslily JavaScript nativně bez jakéhokoli speciálního nastavení. Oba pořídily screenshot celé stránky. Oba zvládly odpověď 500 tak, že vrátily prozkoumatelný response objekt místo toho, aby spadly výjimkou — drobnost, která ale při velkém scrapingu hodně záleží, protože chcete špatný status zalogovat, ne zhroutit celý běh.
Ještě jedno upozornění, protože se na něj dá snadno zapomenout: šlo o jednorázová měření na jednom stroji, ne o oficiální benchmark. Netvrdím, že je jeden z nich o milisekundy rychlejší než druhý, protože stopky na jedné mašině nejsou skutečný speed test. Tvrdím jen něco užšího a lépe podloženého: u extrakční přesnosti a chování při renderování se napříč osmi typy stránek shodly. Pokud jste doufali, že se jeden z nich na reálné stránce utrhne, nestalo se.
Ten jediný rozdíl, který by měl rozhodnout
Skutečný rozdíl není v číslech. Je v rozsahu podpory.
Playwright ovládá tři enginy — Chromium, Firefox a WebKit — přes jedno API a vedle JavaScriptu dodává i plnohodnotné klienty pro Python, Javu a .NET. To je dokumentovaná výhoda, a chci být přesný u slova „dokumentovaná“: v tomto testu jsem používal jen Chromium, takže tříenginovou podporu Playwrightu uvádím jako oficiálně deklarovanou schopnost, kterou jsem sám nezávisle neověřoval, ne jako něco, co jsem si odzkoušel. Pokud potřebujete scrapeovat web, který se v Safari WebKitu renderuje jinak, nebo váš tým píše v Pythonu, právě tahle šířka je argument pro Playwright.
Puppeteer je napřed zaměřený na Chrome, ale tady se běžná zkratka plete. „Jen Chrome“ už není přesné. Od Puppeteer v23 má produkční podporu Firefoxu přes WebDriver BiDi, zatímco pro Chrome dál používá CDP, aby zůstaly zachované existující automatizace — změnu zaznamenaly jak Chrome for Developers, tak Mozilla. Verze, kterou jsem testoval (24.16.0), je už daleko za v23, takže skutečný rozdíl není „Chrome versus tři enginy“. Je to spíš: Puppeteer pokrývá Chrome (CDP) a Firefox (BiDi), ale ne WebKit, a jeho příběh napříč enginy je mladší než u Playwrightu. Engine, který má Playwright a Puppeteer ne, je WebKit.
Tohle je tedy ono rozhodnutí v kostce. Ne rychlost, ne přesnost, ne věrnost renderování — tam je remíza. Jde o rozsah: potřebujete WebKit nebo ne-JavaScriptové klienty, nebo vám stačí Chrome a Firefox z Node pro vaše cíle? U velké části scrapingových úloh projdou oba, takže vybíráte podle vhodnosti pro stack, ne podle schopností.
Co neudělá ani jeden z nich
Oba nástroje vám nechávají na stole stejný úkol: orchestrace crawlů. Ani jeden nemá vestavěnou frontu požadavků, zapisování datasetu ani automatické throttlingy. Můj test crawl grafu — projít interní odkazy, hlídat hloubku a nevracet se na stejné URL — vyžadoval v obou případech ručně napsané breadth-first search. Dvanáct stránek, hloubky {0,1,2}, vlastní BFS, pokaždé.
Pro pár stránek je to v pořádku; malý BFS je otázka asi dvanácti řádků. Pro crawl ve velkém — stovky nebo tisíce URL s deduplikací, retry a ohleduplnými prodlevami — si tu infrastrukturu buď postavíte sami, nebo sáhnete po vrstvě, která tyto enginy obaluje. Crawlee dělá přesně to a poskytuje skutečnou crawl vrstvu nad Playwrightem i Puppeteerem.
Tohle není chyba a chci to pojmenovat přesně: Playwright a Puppeteer jsou frameworky pro automatizaci prohlížeče, ne crawl frameworky. Chybějící fronta není bug, ale hranice rozsahu. Správný mentální model je, že tyto nástroje představují tu část scrapingu, která „vidí stránku“. Část „projde web“ si musíte dodat sami — napsat ji, nebo přidat wrapper, který ji už má.
Instalace a verze, které je dobré znát
Instalace je téměř stejná. npm install stáhne knihovnu i binárku prohlížeče, a právě binárka je ta těžká část — Puppeteer automaticky přibalí download Chromu (v mém běhu čistá instalace, bez nahlášených zranitelností), zatímco Playwright používá pro své browser buildy samostatné npx playwright install. Ani jedna instalace není bolestivá, ale s downloadem počítejte v obou případech; váha prohlížeče a cena za každou stránku je skutečná daň za renderování oproti čistě HTTP nástroji.
A teď disclosure, který vám dlužím. Testoval jsem Playwright 1.56.0 proti aktuální 1.61.1 a Puppeteer 24.16.0 proti npm aktuální 25.3.0 — u Puppeteeru to znamená celou major verzi zpět, vše k 2026-07-09. API, která jsem používal, jsou přes tyto rozdíly stabilní, takže výsledky platí. Pokud ale čtete článek až po nějaké době, spusťte si to na aktuálních verzích znovu, než na těch číslech postavíte rozhodnutí. A ještě jednou: v Playwrightu jsem používal jen Chromium, takže o shodě s Firefoxem nebo WebKitem netvrdím nic víc než to, že je to dokumentovaná vlastnost.
Playwright a Puppeteer: výhody a nevýhody
Remíza znamená, že seznam pro a proti je spíš o tom, k čemu se zavazujete, než o tom, kdo vyhrává.
Playwright
- Výhody: dokumentovaná podpora tří engineů (Chromium, Firefox, WebKit) přes jedno API; oficiální klienti pro Python, Javu a .NET; nativní vykreslení JavaScriptu s plným pokrytím; aktivně rozšiřovaná podpora.
- Nevýhody: bez vestavěné crawl fronty; vyšší váha prohlížeče a cena za stránku; v tomto testu byl použit jen Chromium; verze, kterou jsem spustil, byla za nejnovějším releasem.
Puppeteer
- Výhody: zralá a stabilní automatizace Chrome přes CDP; nativní vykreslení JavaScriptu s plným pokrytím; čisté zpracování chyby 500 (response objekt, žádná výjimka); hluboký, prověřený ekosystém; od v23 dokumentovaná podpora Firefoxu přes WebDriver BiDi.
- Nevýhody: primárně pro Chrome a Node, bez WebKit engine; bez vestavěné crawl fronty; vyšší váha prohlížeče; verze, kterou jsem testoval, byla o celou major verzi za aktuálním npm vydáním.
Kdo by měl zvolit co
Zvolte Puppeteer, pokud žijete v Node, vaše cílové weby se v Chromu renderují správně (a většina ano) a chcete zralou, úzce zaměřenou knihovnu s hlubokým ekosystémem a o jednu osu složitosti méně. Možnost přes BiDi pro Firefox tu je, kdyby se vám později hodila.
Zvolte Playwright, pokud potřebujete pokrytí WebKitem, chcete psát scraper v Pythonu nebo .NET, nebo raději vsadíte na projekt se širším záběrem v enginech i jazycích. Už jen jazyková kompatibilita je často ten nejjasnější důvod, proč Python tým skončí u Playwrightu.
A je tu ještě třetí odpověď, kterou srovnávací články často přeskakují: neberte ani jeden, pokud vaše stránky k vykreslení dat JavaScript vůbec nepotřebují. Jestli vám obsah vrátí obyčejný HTTP request s parserem, headless browser je drahé přestřelení — to už je jiná kategorie nástrojů a sahat po reálném prohlížeči v takové situaci znamená zbytečně pálit paměť i čas na setup.
Kde dává smysl spravované API, včetně Thunderbit
Vyzkoušejte Thunderbit pro extrakci webových dat
Playwright i Puppeteer jsou zdarma a open-source knihovny, které si sami provozujete a spravujete. Máte na starosti prostředí prohlížeče, aktualizace, crawl kód, který k nim přidáte, i závod ve zbrojení proti bot detekci. U spousty projektů je přesně tahle odpovědnost správná a nic z toho není argument proti nim.
Ale podívejte se, kolik skutečné práce při web scraping leží mimo tyto nástroje. Stránku vykreslí dobře; neřídí frontu URL, neřeší obcházení blokací, nedají vám strukturované JSON výstupy a browser fleet musíte držet v chodu sami. To je jiná vrstva stacku než spravovaná extrakční služba, a je fér to říct nahlas, když někdo váží build vs. buy. Náš vlastní vývojářský stack Thunderbit sedí právě v té druhé vrstvě: POST /distill převede stránku do čistého Markdownu připraveného pro LLM a POST /extract vrátí strukturované JSON podle schématu, které si definujete, přičemž JavaScriptové renderování, anti-bot ochrana i CAPTCHAs se řeší na serveru, ne na vašem notebooku. Pro AI agenty a coding asistenty je tu Thunderbit MCP server (kde thunderbit_suggest_fields běží zdarma, ještě než něco utratíte) a pro CI i cron je k dispozici CLI přes npx @thunderbit/thunderbit-cli.
Nechci předstírat, že je to jednoznačně lepší — je to jen jiný typ kompromisu. S Playwrightem nebo Puppeteerem máte pod kontrolou renderování i vše, co kolem něj postavíte, a neplatíte nic za každý request. Se spravovaným API přenesete renderování, anti-bot i crawl infrastrukturu jinam a platíte za požadavek (v případě Thunderbit podle počtu volání — jeden kredit za distill, dvacet za extract — ne za řádek). Malý projekt, vlastní hosting a rádi si držíte prohlížeč pod kontrolou? Tyto knihovny jsou správná volba. Potřebujete škálovat a nechce se vám provozovat headless farmu, crawler a vrstvu na rotaci blokací? Spravovaná cesta tuhle práci celé kategorie smaže.
V širším kontextu náš tým testoval i dvojenginový přístup Crawlee a sadu HTTP-first frameworků proti stejným testovacím podkladům — což je užitečný další krok, pokud jste dospěli k závěru, že plný browser je větší, než vaše stránky skutečně potřebují.
Verdikt
Měli byste použít Playwright, nebo Puppeteer? Pro renderování JavaScriptových stránek klidně kterýkoli — ve všech důležitých testech tu skončily nerozhodně, takže při volbě podle jiných kritérií o schopnosti nepřicházíte. Zvolte Puppeteer, pokud vám sedí Chrome a Firefox z Node a chcete zralost a fokus. Zvolte Playwright, pokud potřebujete WebKit nebo ne-JavaScriptové klienty.
Jsou tu ale ještě dvě věci, které se v podobných článcích často vynechávají a které si stojí za to odnést. Za prvé: v reálném web scraping jsou tyto dva nástroje skutečnou remízou, takže nemá smysl trápit se kvůli výkonové mezeře, která se v osmi různých testech vůbec neukázala. Za druhé: ani jeden z nich není crawler — renderují a zbytek je na vás, nebo na wrapperu jako Crawlee. Když si tohle ujasníte a sladíte rozsah s vaším stackem, výběr se zmenší na minimum. Rozhodnutí o engine je mnohem méně důležité než ta polovina práce, kterou pro vás žádný z těchto nástrojů neudělá.
Další informace
Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free
Časté dotazy
Je Playwright nebo Puppeteer rychlejší pro web scraping?
Na stejných testovacích podkladech byly v praxi na stejné úrovni — stejná přesnost na statických stránkách (12/12), dynamických stránkách (8/8) i při extrakci z JSON API, stejné nativní vykreslení i stejné chování při chybě 500. Šlo o jednorázová měření na jednom stroji, ne o oficiální benchmark, takže rozdíly v časech na stránku nejsou skutečné speed testy. Rozhodujte podle rozsahu a jazyka, ne podle výkonové mezery, která se vůbec neukázala.
Jaký je skutečný rozdíl mezi Playwrightem a Puppeteerem?
Rozsah engineů a jazyků. Playwright přes jedno API ovládá Chromium, Firefox a WebKit a má klienty pro Python, Javu i .NET. Puppeteer je primárně pro Chrome přes CDP, od v23 má dokumentovanou podporu Firefoxu přes WebDriver BiDi, ale ne WebKit, a je navázaný na Node. Oba nativně renderují JavaScript a ani jeden nemá vestavěnou crawl orchestrace.
Můžu s Playwrightem nebo Puppeteerem projít celý web?
Ne přímo z krabice. Ani jeden nemá request queue, zapisování datasetu ani automatické throttlingy — můj crawl graf test v obou případech vyžadoval ručně napsané BFS, dvanáct stránek v hloubkách {0,1,2}. Pro větší měřítko přidejte crawl vrstvu, například Crawlee, která oba enginy obaluje skutečnou crawl logikou.
Potřebuji na scraping vůbec browserový nástroj?
Jen tehdy, když stránka potřebuje JavaScript k zobrazení dat. Pokud vám stačí HTTP request a parser, headless browser je zbytečně drahé řešení — použijte raději HTTP-first nástroj a browserovou zátěž úplně vynechejte.
Co by si měl vybrat Python tým?
Playwright, protože má plnohodnotného klienta pro Python. Puppeteer je orientovaný na Node, takže jeho použití z Pythonu znamená stavět vlastní most, který byste museli udržovat. Tahle jazyková kompatibilita je jeden z nejjasnějších důvodů, proč dát před Puppeteerem přednost Playwrightu.
