“Playwright vs Puppeteer” başlıklı yazıların çoğu, bu ikisinden birinin illa daha iyi bir scraper olduğu varsayımıyla başlıyor. Açıkçası bu yaklaşım, gereksiz yere büyütülmüş bir yük taşıyor. Ben iki kütüphaneyi de aynı sayfalarda denedim — statik bir katalog, JavaScript ile render edilen bir katalog, bir makale, bozuk bir 500 sayfası, küçük bir crawl grafiği ve iki herkese açık deneme sitesi — ve sonuçlar neredeyse ayırt edilemedi. Aynı yakalama oranı, aynı render, aynı ekran görüntüleri, aynı eksikler.
Yani bu bir “taç kimde kalacak” yazısı değil. Bir tarayıcı otomasyon aracının bir sayfayı scrape edip edemeyeceğine gerçekten karar veren işlerde, ikisi de öne çıkmadı. Aşağıda göreceğin şey, tercihini yönlendirmesi gereken tek gerçek fark; ikisinin de sessizce senin kurmanı beklediği kısım ve test ettiğim sürüm farkına dair bir not (2026-07-09 itibarıyla).
Bu karşılaştırma neden gerçekten adil
Karşılaştırma yazılarının kötü bir huyu vardır: Her aracı farklı sayfalarda denerler ve sonra bir kazanan ilan ederler — bu da sana araçlardan çok sayfalar hakkında bilgi verir. Ben bunu önlemek için Playwright ve Puppeteer’ı aynı yerel fixture sunucusuna ve aynı herkese açık demolarına, Books to Scrape ve Quotes to Scrape, karşı çalıştırdım; böylece tüm sayılar bire bir kıyaslanabilir oldu.
“Berabere” iddiasının anlamlı olmasının tek yolu budur. Fixture’lar farklıysa, beraberlik sadece gürültüdür. Byte byte aynı olduklarında ise eşleşen sonuçlar, araçların kendisi hakkında gerçek bir sinyal verir.
Her araç aslında nedir
Puppeteer, Chrome DevTools Protocol üzerinden Chrome’u kontrol etmeye yarayan bir JavaScript API’sidir. Resmî tanımı da zaten budur: “Chrome’u (ve deneysel olarak Firefox’u) kontrol etmek için bir JavaScript API’si.” Olgun, Chrome odaklı ve Node tabanlıdır.
Playwright ise kendini biraz farklı konumlandırır — tek bir API üzerinden Chromium, Firefox ve WebKit’i yöneten, JavaScript, Python, Java ve .NET için resmî istemcileri olan “web test ve otomasyon çerçevesi.” İkisinin de ortak bir geçmişi var (Playwright, Google’daki Puppeteer ekibinden çıkıp daha sonra Microsoft’a geçen ekipten doğdu), bu yüzden rakipten çok kuzen gibi dururlar.
Ama scraping söz konusu olduğunda ikisi de benzer şekilde çalışır. Gerçek bir tarayıcı açarsın, sayfayı yüklersin, scriptlerin çalışmasına izin verirsin ve sonra render edilmiş DOM’u okursun. HTTP parser yerine bunlardan birini seçmene neden olan şey budur: JavaScript çalıştıktan sonraki sayfayı istersin, içi boş kabuğu değil. Aşağıdaki her şey bu ortak mekanizmadan gelir — bu yüzden yaptıkları pek çok şeyin sonunda birbirini dengelemesi hiç şaşırtıcı değil.
Sonuçlar, yan yana
“Biri bariz şekilde daha iyi” anlatısının sessizce çöktüğü yer tam burası. Aynı fixture’lar, aynı sayılar, her alanda.
| Test | Playwright | Puppeteer |
|---|---|---|
| Statik katalog (12 ürün) | 12/12, recall 1.0 | 12/12, recall 1.0 |
| Makale (başlık + 3 paragraf) | 3/3, gereksiz içerik ayrıştırıldı | 3/3, gereksiz içerik ayrıştırıldı |
| Dinamik JS sayfası (yerel render) | 8/8 + ekran görüntüsü | 8/8 + ekran görüntüsü |
| Dinamik JSON API | 8/8, recall 1.0 | 8/8, recall 1.0 |
| HTTP 500 işleme | incelenebilir, hata fırlatmadı | incelenebilir, hata fırlatmadı |
| Crawl grafiği (elle yazılmış BFS) | 12 sayfa, derinlikler {0,1,2} | 12 sayfa, derinlikler {0,1,2} |
| Books to Scrape | 20 ürün | 20 ürün |
| Quotes JS (herkese açık) | 10 alıntı | 10 alıntı |
İkisi de JavaScript’i özel bir ayar gerektirmeden yerel olarak render etti. İkisi de tam sayfa ekran görüntüsü aldı. İkisi de 500 yanıtını exception fırlatmak yerine incelenebilir bir response nesnesi olarak döndürdü — yoğun scraping yaparken ve kötü status kodunu kaydedip run’ı çökertmek istemediğinde önemli olan küçük bir detay.
Burada bir uyarıyı özellikle tekrar edeceğim, çünkü yanlış anlaşılmaya çok açık: Bunlar tek makinede, tek çalıştırmada gözlemlenen sonuçlardı, benchmark değil. Bir dizüstü bilgisayarda sayfa başına kronometre tutup “hız testi” yaptıklarını iddia etmiyorum. İddiam daha dar ve daha sağlam: çıkarım doğruluğu ve render davranışında, sekiz farklı sayfa tipinde eşittiler. Birinin gerçek bir sayfada diğerinden kopmasını umuyorsan, olmadı.
Kararı vermesi gereken tek fark
Asıl ayrım sayılarda değil. Kapsamda.
Playwright, tek bir API üzerinden üç motoru — Chromium, Firefox ve WebKit — çalıştırır ve JavaScript’in yanında Python, Java ve .NET için birinci sınıf istemciler sunar. Bu, belgelenmiş bir güçtür; “belgelenmiş” kelimesini özellikle dikkatli kullanıyorum: Bu çalışmada yalnızca Chromium’u denedim, dolayısıyla Playwright’ın üç motor desteğini bizzat doğruladığım bir şey olarak değil, belgelenmiş bir yetenek olarak aktarıyorum. Safari’nin WebKit’i altında farklı render eden bir siteyi scrape etmen gerekiyorsa ya da ekibin Python ile çalışıyorsa, bu genişlik Playwright’ın en güçlü artısıdır.
Puppeteer ise Chrome odaklıdır ve burada yaygın kısa özetler gerçeği tam anlatmaz. “Sadece Chrome” artık doğru değil. Puppeteer v23 sürümünden beri WebDriver BiDi üzerinden üretime hazır Firefox desteği sunuyor; Chrome tarafında ise mevcut otomasyonları bozmamak için CDP’yi varsayılan olarak kullanıyor — bu geçişi hem Chrome for Developers hem de Mozilla belgeledi. Benim test ettiğim sürüm (24.16.0), v23’ün epey üzerindeydi; yani gerçek fark artık “Chrome mu, üç motor mu?” değil. Fark şu: Puppeteer Chrome’u (CDP) ve Firefox’u (BiDi) kapsıyor ama WebKit’i kapsamıyor; ayrıca motorlar arası hikâyesi Playwright’tan daha yeni. Playwright’ta olup Puppeteer’da olmayan motor WebKit’tir.
Karar aslında bu kadar net. Hız değil, doğruluk değil, render sadakati değil — bunlarda eşitler. Soru kapsamla ilgili: WebKit desteğine veya JavaScript dışı dil istemcilerine ihtiyacın var mı, yoksa hedeflerin için Node üzerinden Chrome ve Firefox yeterli mi? Scraping işlerinin büyük bir kısmında iki araç da eşiği rahatça geçiyor; sen de yetenekten çok teknoloji yığını uyumuna göre seçim yapıyorsun.
İkisinin de yapmadığı şey
İki araç da aynı işi masanda bırakıyor: crawl orkestrasyonu. Hiçbiri yerleşik bir istek kuyruğu, veri seti yazıcısı ya da otomatik hız sınırlaması sunmuyor. Crawl-grafiği testim — dahili bağlantıları gez, derinliği takip et, aynı URL’ye tekrar uğrama — her iki durumda da elle yazılmış bir breadth-first search gerektirdi. 12 sayfa, derinlikler {0,1,2}, iki seferde de benim BFS’ım.
Birkaç sayfa için bu sorun değildir; küçük bir BFS on iki satırlık iştir. Ama ölçekli crawling — yüzlerce ya da binlerce URL, deduplikasyon, yeniden deneme ve nazik gecikmeler ile — için o altyapıyı ya kendin kurarsın ya da bu motorları saran bir araç seçersin. Crawlee tam olarak bunu yapar; hem Playwright hem de Puppeteer üzerine gerçek bir crawling katmanı ekler.
Bu bir kusur değil ve doğru adını koymak istiyorum: Playwright ve Puppeteer birer browser-automation framework’üdür, crawler framework’ü değil. Eksik kuyruk bir hata değil, kapsam sınırıdır. Doğru zihinsel model şu: Bu araçlar scraper’ın “sayfayı gör” kısmıdır. “Siteyi gez” kısmını ise senin getirmen gerekir — ya kendin yazarsın ya da bunu sağlayan bir sarmalayıcı eklersin.
Kurulum ve sürüm notu
Kurulum neredeyse birebir aynıdır. npm install, kütüphaneyle birlikte bir tarayıcı binary’si de indirir; ağır kısım odur — Puppeteer temiz bir kurulumda otomatik olarak bir Chrome indirmesi paketiyle gelir (çalıştırmamda sıfır güvenlik açığı raporlandı), Playwright ise tarayıcı derlemeleri için ayrı bir npx playwright install adımı kullanır. Kurulumların hiçbiri can sıkıcı değil; ama her iki durumda da indirmenin yükünü hesaba katman gerekir, çünkü render etmenin asıl faturası budur; HTTP-only bir araca kıyasla.
Şimdi sana borçlu olduğum açıklama: Playwright 1.56.0’ı 1.61.1’in en güncel sürümüne karşı, Puppeteer 24.16.0’ı ise npm’deki 25.3.0 en güncel sürümüne karşı test ettim — yani Puppeteer tarafında tam bir majör sürüm gerideydim; bunların hepsi 2026-07-09 itibarıyla geçerliydi. Denediğim API’ler bu sürüm farkları arasında stabildi, bu yüzden sonuçlar geçerliliğini koruyor. Ancak bunu yayınlandıktan bir süre sonra okuyorsan, kesin sayılara güvenmeden önce güncel sürümlerle yeniden test et. Ve bir kez daha söyleyeyim: Playwright altında yalnızca Chromium’u kullandım; dolayısıyla Firefox veya WebKit eşdeğerliği hakkında “belgelenmiş olması dışında” başka bir iddiam yok.
Playwright ve Puppeteer: artılar ve eksiler
Beraberlik, artı/eksi listesini bir kazanan belirlemekten çok neyi üstlenmiş olduğun sorusuna çeviriyor.
Playwright
- Artılar: tek API ile belgelenmiş üç motor desteği (Chromium, Firefox, WebKit); resmî Python, Java ve .NET istemcileri; tam doğrulukla yerel JS render; aktif biçimde genişleyen kapsam.
- Eksiler: yerleşik crawl kuyruğu yok; tarayıcı ağırlığı ve sayfa başı maliyet; bu testte yalnızca Chromium kullanıldı; çalıştırdığım sürüm en güncel sürümün gerisindeydi.
Puppeteer
- Artılar: CDP üzerinden olgun ve stabil Chrome otomasyonu; tam doğrulukla yerel JS render; temiz 500 işleme (response nesnesi, exception yok); köklü ve iyi oturmuş ekosistem; v23’ten beri WebDriver BiDi ile belgelenmiş Firefox desteği.
- Eksiler: Chrome odaklı ve Node tabanlı; WebKit motoru yok; yerleşik crawl kuyruğu yok; tarayıcı ağırlığı; çalıştırdığım sürüm npm’deki son sürümün tam bir majör gerisindeydi.
Kim hangisini seçmeli
Node içinde yaşıyorsan, hedeflerin Chrome’da sorunsuz render ediyorsa (çoğu öyledir) ve derin bir ekosisteme sahip, olgun ve odaklı bir kütüphane istiyorsan Puppeteer’ı seç. Firefox’u BiDi üzerinden kullanma seçeneği, büyüdükçe sana ayrıca kapı açar.
WebKit kapsamına ihtiyacın varsa, scraper’ını Python veya .NET ile yazmak istiyorsan ya da daha geniş motor ve dil desteği olan projeye güvenmeyi tercih ediyorsan Playwright’ı seç. Sadece dil uyumu bile çoğu zaman bir Python ekibinin Playwright’a yönelmesinin en net sebebidir.
Karşılaştırma yazılarının atlama eğiliminde olduğu üçüncü bir cevap daha var: Sayfaların veriyi göstermek için gerçekten JavaScript’e ihtiyacı yoksa ikisini de seçme. Bir HTTP isteği ve bir parser içeriği getiriyorsa, headless browser pahalı bir aşırı çözümdür — bu bambaşka bir araç kategorisidir ve orada gerçek bir tarayıcı kullanmak yalnızca bellek ve kurulum süresini boşa harcar.
Yönetilen API nerede devreye girer, Thunderbit dahil
Web Veri Çekimi için Thunderbit’i Dene
Playwright ve Puppeteer, kendi başına çalıştırıp yönettiğin ücretsiz, açık kaynaklı kütüphanelerdir. Tarayıcı ortamından, güncellemelerden, üzerine eklediğin crawl kodundan ve anti-bot rekabetinden sen sorumlusun. Pek çok proje için bu sahiplik tam olarak doğru seçimdir; burada buna karşı bir argüman yok.
Ama gerçek scraping işinin ne kadar büyük bir kısmının bu araçların dışında kaldığına bak. Sayfayı iyi render ederler; URL kuyruğu yönetmezler, bloklara karşı rotasyon yapmazlar, sana yapılandırılmış JSON vermezler ve tarayıcı filosunu da sen ayakta tutarsın. Bu, yönetilen bir çıkarım hizmetinden farklı bir katmandır; build mi buy mu kararında olan geliştiriciler için bunu açıkça adlandırmak gerekir. Bizim Thunderbit geliştirici yığınımız işte o diğer katmanda durur: POST /distill, bir sayfayı temiz ve LLM’e hazır Markdown’a dönüştürür; POST /extract ise tanımladığın şemaya göre yapılandırılmış JSON döndürür; JavaScript render, anti-bot işleme ve CAPTCHA’lar ise dizüstü bilgisayarında değil sunucu tarafında yönetilir. AI ajanları ve kodlama asistanları için bir Thunderbit MCP sunucusu da vardır (thunderbit_suggest_fields hiçbir ücret harcamadan önce ücretsiz çalışır) ve CI ile cron için npx @thunderbit/thunderbit-cli üzerinden bir CLI sağlanır.
Bunun kesinlikle daha iyiymiş gibi davranmayacağım — bu farklı bir takas. Playwright veya Puppeteer ile render etme işini ve etrafında kurduğun her şeyi sen sahiplenirsin; çağrı başına sıfır maliyetle. Yönetilen bir API ile render, anti-bot ve crawl tesisatını dışarı verirsin; bunun karşılığında çağrı başına ücret ödersin (Thunderbit’te durum böyledir: satır başına değil, çağrı bazında ölçülür — bir distill için bir kredi, bir extract için yirmi kredi). Küçük ölçekte, kendi sunucunda çalıştırmayı seviyor ve tarayıcıyı sahiplenmek istiyorsan? Bu kütüphaneler doğru araçlardır. Ölçek büyüdüğünde ve headless filo + crawler + blok rotasyonu katmanı işletmek istemediğinde? Yönetilen yol, o iş kategorisini ortadan kaldırır.
Daha geniş alan için ekibimiz bu aynı fixture’lar üzerinde Crawlee’nin iki motor yaklaşımını ve HTTP-first çerçevelerden oluşan bir seti de test etti; tam tarayıcının sayfalarının ihtiyacından fazla olup olmadığına karar verdiysen, bu doğal sonraki durak olur.
Hüküm
Playwright mı Puppeteer mı kullanmalısın? JavaScript sayfalarını render etmek için ikisi de olur — burada önemli olan tüm testlerde berabere kaldılar, yani başka bir kritere göre seçim yaparak bir yetenek kaybı yaşamıyorsun. Chrome ve Firefox’un Node üzerinden yeterli olduğu, olgun ve odaklı bir araç istiyorsan Puppeteer’ı seç. WebKit erişimine veya JavaScript dışı istemcilere ihtiyacın varsa Playwright’ı seç.
Karşılaştırma yazılarının atlama eğiliminde olduğu iki şey akılda kalmaya değer. Birincisi, gerçek scraping görevlerinde bu ikisi gerçekten berabere; dolayısıyla sekiz farklı testte görünmeyen bir performans farkı için gereksiz yere kafayı yorma. İkincisi, ikisi de bir crawler değil — onlar sayfayı render eder, crawling ise sana ya da Crawlee gibi bir sarmalayıcıya kalır. Bu ikisini net ayır, kapsamı stack’ine eşleştir, karar küçülür. Motor seçimi, araçların senin için yapmadığı işin yarısından çok daha az önemlidir.
Daha Fazla Bilgi
Web Veri Çekimi için Thunderbit’i Dene Get Started Free
SSS
Web scraping için Playwright mı Puppeteer mı daha hızlı? Aynı fixture’larda pratikte berabereydiler — statik (12/12), dinamik (8/8) ve JSON-API çıkarımında aynı doğruluk, aynı yerel render, aynı 500 işleme. Bunlar tek çalıştırmalık, tek makine gözlemleriydi; benchmark değildi. Bu yüzden sayfa başına zaman farkı gerçek bir hız ölçümü sayılmaz. Seçimi hız farkına göre değil, kapsam ve dile göre yap; çünkü ortada görünen bir hız farkı yoktu.
Playwright ile Puppeteer arasındaki gerçek fark nedir? Motor ve dil kapsamı. Playwright, Chromium, Firefox ve WebKit’i tek bir API üzerinden çalıştırır; Python, Java ve .NET istemcileri vardır. Puppeteer ise CDP üzerinden Chrome odaklıdır; v23’ten beri WebDriver BiDi ile belgelenmiş Firefox desteği sunar ama WebKit yoktur ve Node tabanlıdır. İkisi de JavaScript’i yerel olarak render eder; ikisinin de yerleşik crawl orkestrasyonu yoktur.
Playwright veya Puppeteer ile tüm bir siteyi crawl edebilir miyim? Kutudan çıktığı haliyle hayır. Hiçbirinde istek kuyruğu, veri seti yazıcı ya da otomatik hız sınırlaması yok — crawl-grafiği testim her iki tarafta da elle yazılmış BFS gerektirdi; 12 sayfa, derinlikler {0,1,2}. Ölçek için, her iki motorun üzerine gerçek crawl altyapısı ekleyen Crawlee gibi bir katman kullan.
Scraping için mutlaka bir tarayıcı aracına ihtiyacım var mı? Sadece sayfanın veriyi göstermek için JavaScript’e ihtiyacı varsa. Bir HTTP isteği ve parser istediğin içeriği döndürüyorsa, headless browser pahalı bir aşırı çözümdür — bunun yerine HTTP-first bir araç kullan ve tarayıcı ağırlığını tamamen atla.
Bir Python ekibi hangisini seçmeli? Playwright, çünkü birinci sınıf Python istemcisi vardır. Puppeteer Node tabanlıdır; dolayısıyla onu Python’dan kullanmak, bakımını yapman gereken bir köprü kurmak anlamına gelir. Bu dil uyumu, çoğu zaman Playwright’ı Puppeteer’a tercih etmenin en net sebeplerinden biridir.
