Playwright İncelemesi: Chromium Üzerinde JavaScript Rendering, Ama Tarama Katmanı Size Ait

Playwright, Microsoft’un tarayıcı otomasyon çerçevesi: Apache-2.0 lisanslı, TypeScript odaklı bir kütüphane; gerçek bir tarayıcıyı ayağa kaldırır, onu tek bir API üzerinden yönetir ve JavaScript çalıştıktan sonra sayfayı size geri verir. Genelde uçtan uca test aracı olarak konumlandırılır, ama altındaki motor, çoğu kişinin bir HTTP isteğinin verinin olması gereken yerde boş bir kabuk döndürdüğü anda sessizce başvurduğu şeydir. Yapı olarak Puppeteer ve Selenium ile yarışır — parse ettiğiniz HTTP istemcileri değil, komutla yönettiğiniz gerçek tarayıcılar.

microsoft/playwright 1.56.0 sürümünü, sabit bir dizi scraping testiyle denedim: sayfalama içeren statik bir katalog, bir makale, JavaScript ile render edilen bir katalog, bir JSON API, bozuk bir 500 yanıtı, küçük bir crawl grafiği ve iki herkese açık pratik site — Node v22.22.3, macOS arm64 ve sadece Chromium üzerinde. Rendering tarafı pürüzsüz geçti. Tarama tarafı ise yok; araca karar vermeden önce asıl kritik nokta da tam olarak bu eksik kısım.

Öne çıkanlar

Sonuç yığını içinde iki çıktı en üstte duruyor ve ikisi farklı yönlere işaret ediyor.

İlki, kullandığım bekleme koşulları içinde beklenen tarayıcı sonucu. page.goto(..., { waitUntil: 'domcontentloaded' }) sonrasında dinamik fixture testi #dynamic-products article.product-card öğesini bekledi, herkese açık Quotes to Scrape testi ise .quote öğesini bekledi. Uygulamaya özel bu seçiciler göründükten sonra testler 8/8 fixture öğesini ve 10 kamuya açık site alıntısını döndürdü; fixture sonucu, sekiz öğelik gerçek veriyle karşılaştırıldığında 1.0 recall elde etti. Özel bir polling döngüsüne gerek kalmadı, ama Playwright hazır olma sorununu ortadan kaldırmadı — tamamlanma koşulunu testin kendisi verdi. İlk çağrıda tam sayfa ekran görüntüsü de kaydedildi.

İkinci sonuç browserContext.request ile geldi: yani Chromium zaten başlatılmışken ve bir browser context varken ctx.request.get(...) çağrıldı. Fixture’ın JSON uç noktasına doğrudan istek atıldı ve bir sayfa oluşturup render etmeden 8/8 ürün geri geldi. Bu, DOM işini atlar; ama bu kurulumda tarayıcı sürecinin maliyetini ortadan kaldırmaz. Context’e bağlı request istemcisi, tarayıcı sayfalarıyla çerez durumunu paylaşabilir; bağımsız bir playwright.request.newContext() tarayıcı context’i gerektirmez ama oturumu otomatik olarak paylaşmaz. Bu test yalnızca ilk yolu kapsadı.

Playwright ayrıca bir crawl kuyruğu, veri seti yazıcısı ya da otomatik throttling sunmaz. Crawl grafiği testim — iç bağlantıları takip et, derinliği izle ve tekrar ziyaretlerden kaçın — derinliklere {0:1, 1:4, 2:7} dağılan toplam 12 sayfaya ulaştı; fakat bu breadth-first traversal benim yazdığım test koduydu. Playwright sayfaları açar ve inceler; frontier kalıcılığı, URL politikası, yeniden deneme ve zamanlama başka bir katmana aittir.

Playwright aslında nedir

Araç — GitHub’daki microsoft/playwright — TypeScript ile yazılmış, Apache-2.0 lisanslı ve Microsoft tarafından sürdürülüyor. Burada test edilen derleme 1.56.0 ve tarih 9 Temmuz 2026. Sonuçlar, daha sonraki sürümlerle uyumluluk beyanı olarak değil, bu derleme için raporlanıyor.

Resmî konumlandırma net: Chromium, Firefox ve WebKit’i tek bir API üzerinden yöneten web test ve otomasyon çerçevesi. Playwright’ın ana akışı fixture’lar, assertion’lar ve trace viewer içeren bir test runner’dır. Onu scraping amacıyla kullanmak, belgelenen Library mode akışını izlemek demektir: test altyapısının dışında chromium.launch(), ardından context, sonra page. Bu incelemedeki her şey bu genel API yüzeyini kullandı. Sürümler arası uyumluluk testi yapmadım; dolayısıyla bu, denenen her davranışın tüm sürümlerde sabit kaldığı iddiası değildir.

Belgelenen genişlik başka yerlerde de ana özellik olarak sunulur, o yüzden dikkatli konuşayım. Playwright, Chromium, Firefox ve WebKit olmak üzere üç tarayıcı motorunu tek API üzerinden yönetir ve JavaScript’in üstünde Python, Java ve .NET için birinci sınıf istemciler sunar. Bu belgelenmiş bir gerçektir ve biçim olarak aracın en büyük farklarından biridir. Ama bu incelemede gerçekten denenen kapsam daha dar:

Bir hedef Safari’nin WebKit motorunda farklı render ediliyorsa ya da ekibiniz Python kullanıyorsa, Playwright’ın argümanı tam da bu genişliktir — sadece benim sonuçlarımı Firefox veya WebKit eşdeğerliğinin kanıtı gibi okumayın, çünkü onları test etmedim.

Perde arkasında nasıl çalışıyor

Zihinsel model, komut verdiğiniz bir tarayıcı motorudur. chromium.launch() bir tarayıcı süreci başlatır. context, kendi çerezleri, depolaması ve cache’i olan izole bir oturumdur; page ise o context içindeki bir sekmedir. page.goto(url) çağırır, uygulamanın hazır olduğunu temsil eden koşulu beklersiniz ve ortaya çıkan DOM’u page.$$eval gibi yardımcılarla okursunuz. Bu, HTTP yanıtı parse etmeye kıyasla kullanıcıya dönük bir tarayıcıya daha yakındır; fakat çevresel eşitlik sağlamaz: headless sinyalleri, viewport, locale, fontlar, profil durumu, TLS/ağ yolu ve site savunmaları hâlâ sunulan içeriği değiştirebilir. Bu inceleme anti-bot davranışını veya gerçek tarayıcıyla birebir eşleşmeyi test etmedi.

page.screenshot(), render edilmiş sayfanın ekran görüntüsünü tam sayfa ya da kırpılmış şekilde alır; benim çalıştırmamda ilk denemede sorunsuz çalıştı. Ve bahsettiğim request API’si — context.request.get — aynı context’in çerezlerini kullanırken render adımını atlar; böylece aynı betikte “sayfayı yükle ve DOM’u oku” ile “sadece JSON uç noktasını çağır” akışlarını araç değiştirmeden birleştirebilirsiniz.

Ama perde arkasında olmayan şey tarama altyapısıdır. Dahili bir request scheduler, kalıcı visited-set, politeness policy veya dışa aktarma hattı yoktur. Sınırlı bir dolaşım kolayca yazılabilir; ancak güvenilir frontier yönetimi için URL normalizasyonu, yönlendirme işleme, yeniden denemeler, kapsam kuralları, throttling ve kurtarma da gerekir. O katmanı siz kurarsınız ya da tarayıcı motorunu saran bir çerçeve kullanırsınız.

Kurulum ve yükleme gerçeği

Kurulum iki adımdır ve asıl dağıtım yükünü ikinci adım taşır. npm install playwright kütüphaneyi çeker; ayrı bir npx playwright install komutu tarayıcı derlemelerini indirir (benim durumda Chromium). npm paketini başlı başına çalıştırılabilir sistem gibi görmek yerine disk alanı, indirme süresi, CI içi tarayıcı cache’i ve süreç temizliğini bütçelemek gerekir.

Playwright’ı bir scraper bekleyerek kurup test eğitimini takip ederseniz, test dosyaları ve expect() assertion’larıyla başlarsınız. Oysa scraping kodu doğrudan library API’sini kullanır. İkisi de belgelenmiştir, ama örnek ararken ve dağıtım komutlarını seçerken bu ayrım önemlidir.

Bu çalıştırmada ergonomi tarafı somuttu: browser context’leri oturum durumunu izole etti, async çağrılar düzgün birleşti, bir ekran görüntüsü tek çağrıda alındı ve bir HTTP 500 yanıt nesnesi üzerinden incelenebilir kaldı. Zorlayan taraf sözdiziminden çok operasyoneldi: tarayıcı derlemesi ayrı kurulmalı ve yaşam döngüsü kütüphaneden bağımsız olarak yönetilmeliydi.

Uygulamalı sonuçlar

Yerel sayıların tamamı, tarama başlamadan önce gerçek verisi yazılmış bir fixture sunucusuna karşı 127.0.0.1 üzerinde çalıştı. Tam kurulum run_playwright_material_tests.mjs dosyasındadır ve repoya eklenmiş ham çıktılar gerçek veriyi ve her testin çıktılarını içerir. Bunlar yine de tek bir makinede, tek çalıştırmada elde edilmiş yazar gözlemleridir; bağlantılar bunları yeniden üretilebilir hâle getirir, geniş kapsamlı bir benchmark’a dönüştürmez.

Sayfalama döngüsü bir sonraki bağlantıyı açıkça takip etti; Playwright sayfaları kendi kendine keşfetmedi. Makale seçicisi, gezinme ve footer metnini gövde sonucunun dışında tuttu. Hata yolunda navigation, hata fırlatmak yerine 500 durum kodlu bir response nesnesi döndürdü; böylece çağıran taraf loglama, yeniden deneme veya devam etme kararını verebildi. İki halka açık pratik hedef tabloda gösterilen sayıları verdi.

Net söylenmesi gereken bir sınır: buradaki her şey Chromium üzerinde, tek makinede ve bir kez çalıştı. Yetenek tablosu, belgelenen genişliği denenen davranıştan ayrı gösteriyor. Testleri başka bir Playwright derlemesinde yeniden çalıştırmadım; dolayısıyla sürümler arası bir sonuç çıkarılamaz. Test başına süreler de benchmark olarak verilmedi; tek bir dizüstü bilgisayarda yapılan tek ölçüm, hız karşılaştırmasına temel olamaz.

Hazır olma, çıkarım sözleşmesinin parçasıdır

Dinamik sonuçlar, yalnızca tarayıcı gezinmesine değil, almak istediğim veriyi temsil eden bekleme koşullarına bağlıydı. Yerel katalog için harness, waitUntil: 'domcontentloaded' ile gezindi ve ardından 15 saniyelik zaman aşımıyla waitForSelector('#dynamic-products article.product-card') çağırdı. Public Quotes JS çalıştırması da aynı navigation durumunu kullandı ve 20 saniyelik zaman aşımıyla .quote öğesini bekledi. Çıkarım ancak bu seçiciler göründükten sonra yapıldı.

Betiği uyarlarken bu ayrım önemlidir. domcontentloaded, ilk belgenin parse edildiğini söyler; gecikmeli bir API yanıtının geldiğini, hydration’ın tamamlandığını, sonsuz listenin büyümeyi bıraktığını veya sanallaştırılmış bir satırın viewport’a girdiğini söylemez. Bir eşleşmenin varlığı yeterliyse seçici kullanışlıdır. Tamamlanma bilinen bir yanıt, öğe sayısı, uygulama durumu ya da sakin bir ağ penceresine bağlıysa, bunun yerine o koşulu bekleyin. Koşul, çıktı sözleşmesine bağlanmalıdır: “en az bir kart var” ile “beklenen tüm sayfalar yüklendi” aynı iddia değildir.

Zaman aşımı yönetimi de çağıran tarafa aittir. Test, sonlu selector timeout’ları kullandı ama yeniden deneme politikasını incelemedi veya yavaş bir sayfayla kalıcı olarak değişmiş bir seçiciyi ayırmadı. Üretim için bir sarmalayıcı, hangi hazır olma koşulunun başarısız olduğunu kaydetmeli, sorunu teşhis etmek için yeterli sayfa durumunu yakalamalı ve bir sonraki navigation denemesinin güvenli olup olmadığına karar vermelidir. Playwright size event’leri ve DOM’u verir; işiniz için “tam veri”nin ne anlama geldiğini çıkaramaz.

Bu sınır, her extractor’ın yanında belgelenmeli; örtük bir timeout olarak bırakılmamalıdır.

API yolu da paralel bir sözleşmeye sahiptir. ctx.request.get, tarayıcı context’i zaten var olduğu ve oturum paylaşımı faydalı olabildiği için uygundu. Bir iş, verinin tarayıcı oturumu olmadan da çalıştığını keşfederse, bağımsız bir request context farklı yaşam döngüsü ve çerez davranışına sahip başka bir mimaridir. Bu çalıştırma ikisini karşılaştırmadı. “DOM render edilmedi” ifadesini ölçülmüş gerçek olarak kabul edin, ardından daha geniş iş akışının tarayıcı sürecine ihtiyaç duyup duymadığını ayrı değerlendirin.

Crawl sorusu

Crawl grafiği sonucu, Playwright’ı nasıl düşünmeniz gerektiğini belirleyen sonuçtur. On iki sayfa, üç derinlik, doğru — ve gezme mantığının tamamı bana ait. Playwright yalnızca “bu URL’yi aç ve oku” kısmını sağladı; kuyruğu, visited-set’i ve derinlik takibini ben ekledim.

Küçük ve sınırlı işler için bu bir sorun değildir. Crawl ölçeğinde ise ya bir tarayıcı kütüphanesinin üstüne kendi crawler’ınızı yazarsınız ya da Playwright’ı bunu zaten yapan bir şeyle birleştirirsiniz. Belgelenen yaklaşım Crawlee’dir; Playwright’ı (ve Puppeteer’ı) gerçek bir request queue, dataset depolama ve otomatik throttling ile sarar — siz Playwright’ın rendering gücünü korur, orkestrasyonu ödünç alırsınız. Kuyruğun çerçevenin içine gömülü olmasını, sonradan eklenmemesini istiyorsanız, bu Scrapy’nin bütün tasarım mantığıdır; ancak Scrapy HTTP önceliklidir ve JavaScript’i kendi başına render etmez. Nokta Playwright’ın yetersiz olması değil; “browser automation” ve “crawling” iki ayrı iştir ve Playwright yalnızca bunlardan birini iddia eder.

On iki sayfalık BFS, sahiplik sınırını somutlaştırır. Kontrollü bir grafik için kuyruk, visited set ve derinlik takibi sağladı. Üretim frontieri hâlâ URL canonicalization, redirect handling, izin verilen host’lar, duplicate key’ler, yeniden denemeler, eşzamanlılık, host başına gecikme, kalıcılık ve yeniden başlatma semantiğini tanımlamalıdır. Dışa aktarma da başka bir karardır: fixture JSON ve CSV yazdı çünkü harness bunu yaptı; Playwright bir dataset soyutlaması sunduğu için değil.

Oturum tasarımı da sarmalayıcıyı etkiler. Bir tarayıcı birden fazla context içerebilir; bunların çerezleri ve depolaması izole edilir. Ama bu inceleme paralel context ölçeğini veya hata izolasyonunu ölçmedi. Bir context’i yeniden kullanmak oturumu koruyup kurulum işini azaltabilir; ayrı context’ler oluşturmak işler arasında durum sızıntısını engelleyebilir. Bunlar crawler seviyesindeki politikalardır, Playwright context ilkelini sunsa bile. Seçtiğiniz yaşam döngüsünü, gerçekten çalıştıracağınız tarayıcı derlemesi ve dağıtım ortamıyla benchmark edin.

Artılar ve eksiler

Artılar:

• Gerçek Chromium motoru üzerinden JavaScript çalıştırma; dinamik hedeflerin ikisi de hazır olma koşulu olarak kullanılan seçicilere ulaştı.
• İlk çağrıda tam sayfa ekran görüntüsü alındı.
• Seçiciler, kontrollü fixture’lardan beklenen statik katalog ve makale alanlarını çıkardı.
• browserContext.request, bir sayfa render etmeden JSON uç noktasına erişti; bu sırada zaten başlatılmış tarayıcı süreci harness’in parçası olarak kaldı.
• Kötü yanıta rağmen sağlam: HTTP 500 incelenebilir kaldı ve navigation hata fırlatmadı.
• Tek API üzerinden üç motor desteği belgelendi (Chromium, Firefox, WebKit) ve Python, Java, .NET istemcileri mevcut (burada yalnızca belgeli; fiilen sadece Chromium denendi).
• Apache-2.0 lisanslı ve Microsoft tarafından sürdürülüyor.
• Library mode’a geçtiğinizde geliştirici deneyimi temiz: motorlar arasında tek API, birinci sınıf async, zahmetsiz ekran görüntüleri.

Eksiler:

• Yerleşik crawl kuyruğu, dataset veya otomatik throttle yok — crawl ölçeğindeki iş sizin kodunuz ya da Crawlee gibi bir sarmalayıcıdır.
• Tarayıcı ağırlığı: ikili indirme ve sayfa başı maliyet, yalnızca HTTP kullanan bir araca göre gerçek vergidir.
• Varsayılan çerçeve test runner’dır; scraping için library mode’un varlığını bilmek ve pazarlanan yoldan çıkmak gerekir.
• Yalnızca Playwright 1.56.0 ve Chromium denendi; sürüm ve motorlar arası eşdeğerlik test edilmedi.
• Kendi başına şemaya bağlı yapılandırılmış JSON çıktısı üretmez; seçicileri siz yazar ve veriyi siz şekillendirirsiniz.

Kimler için uygun, kimler uzak durmalı

Sorununuz, JavaScript çalıştıktan sonra verisi görünen sayfaları render etmekse veya DOM verisine ek olarak ekran görüntüsü toplamaksa, Playwright hedeflerinize karşı yeniden üretmeye değer bir adaydır. Zaten Playwright testleri kullanan ekipler, aynı kavramları ve seçici becerilerini library mode’da yeniden kullanabilir. Python, Java ve .NET istemcileri belgelenmiş seçeneklerdir; ama bu inceleme yalnızca Node ve Chromium’u denedi.

Üç durumda başka bir katman düşünün. Gerekli veri zaten bir HTTP yanıtında varsa, HTTP-öncelikli bir araç tarayıcı başlatma ve rendering yükünü ortadan kaldırır; Colly bu kategoride bir crawler kütüphanesidir, Trafilatura ise makale çıkarımını hedefler. Kuyruklama, kalıcılık ve throttling gerekiyorsa bir crawler framework’ü ya da Playwright sarmalayıcısı kullanın. Şema biçimli çıktı istiyor ve seçicileri sürekli bakımda tutmak istemiyorsanız, yönetilen extraction servislerini karşılaştırın. Bu alternatiflerin hiçbiri bu incelemede benchmark edilmedi.

Özellikle Playwright ile Puppeteer arasında karar veriyorsanız, bu ayrı bir başa baş karşılaştırmadır; yan yana incelememiz ikisini aynı fixture’lar üzerinden çalıştırır ve seçimin gerçekte nereye oturduğunu gösterir.

Alternatifler ve yönetilen extraction’ın yeri

Playwright ücretsizdir, Apache-2.0 lisanslıdır ve self-hosted çalışır. Tarayıcı dağıtımı, seçiciler, hazır olma koşulları, crawl kodu, güncellemeler ve hata yönetimi sizin sorumluluğunuzdadır. Bu inceleme anti-bot performansını ölçmedi ve toplam işletme maliyetini yönetilen bir servisle karşılaştırmadı.

Open source dünyasında anlamlı karşılaştırmalar iş bazındadır. Tarayıcı üstünde crawl ölçeğinde iş için Crawlee, Playwright’ın eksik bıraktığı kuyruğu ve dataset’i ekler. Çıktınızın amacı elle şekillendirilmiş satırlar yerine gerçek bir tarayıcıdan LLM’e hazır Markdown ise, Crawl4AI bir tarayıcı çalıştırır ve bu hat için Markdown üretir. Birkaçını aynı anda değerlendiriyorsanız, açık kaynak scraper derlememiz kategorileri yan yana sıralar.

Açıklama: Thunderbit, yayıncının ürünüdür ve bu Playwright fixture’ı üzerinden çalıştırılmadı. Yönetilen extraction kategorisini temsil eder: servis rendering’i işletir ve sayfa metni ya da şema biçimli kayıtlar döndürür; buna karşılık Playwright tarayıcı işletimini ve seçici mantığını geliştiriciye bırakır. Dolayısıyla buradaki karşılaştırma hosting modeli, çıktı biçimi ve maliyet modelidir — bu incelemeden çıkan bir performans sonucu değildir.

Web Verisi Çıkarma için Thunderbit'i Deneyin

Sonuç

Hedefiniz bir tarayıcı motoru gerektiriyorsa ve hazır olma koşulları, seçiciler ve crawl orkestrasyonunu siz üstlenmeye hazırsanız Playwright kullanın. Sonuç tablosu, Chromium library mode’un bu yazar tarafından yapılan çalıştırmada kontrollü statik, dinamik, API, ekran görüntüsü ve hata fixture’larını beklendiği gibi işlediğini gösteriyor.

Kanıt sınırını koruyun: yalnızca Chromium ve Node denendi, 12 sayfalık dolaşım elle yazılmış BFS’ye dayanıyordu, browserContext.request sayfa render’ını atladı ama hâlihazırda çalışan tarayıcı sürecini atlamadı ve her dinamik çıkarım açıkça belirtilmiş bir hazır olma seçicisi kullandı. Bu kısıtlar, Playwright’ı bu incelemede bir tarayıcı primi olarak konumlandırıyor; ölçülmüş uçtan uca bir crawling sistemi olarak değil.

Web Verisi Çıkarma için Thunderbit'i Deneyin Get Started Free

SSS

Playwright ile scraping yaparken hâlâ wait kullanmam gerekir mi?
Evet. Tarayıcı yürütmesi, uygulama verisinin ne zaman hazır olduğunu betiğinize söylemez. Bu testler domcontentloaded durumuna gidip ardından çıkarımdan önce hedefe özel bir seçiciyi bekledi. Üretim sayfaları response, locator durumu ya da uygulama olayı gibi başka bir sinyal gerektirebilir.

Playwright bir web sitesini kendi başına tamamen crawl edebilir mi?
Varsayılan olarak hayır. Yerleşik request queue, dataset writer veya auto-throttle yoktur — benim crawl grafiği testim derinlikler {0:1, 1:4, 2:7} boyunca 12 sayfaya ancak breadth-first search’ü elle yazdığım için ulaştı. Crawl ölçeğinde işler için Playwright’ı gerçek bir crawling katmanıyla saran Crawlee ile birlikte kullanın ya da doğrudan bir crawler framework’ü tercih edin.

browserContext.request ile bağımsız request context’i ne zaman kullanmalıyım?
HTTP çağrılarının mevcut bir browser context içindeki sayfalarla çerez paylaşması gerekiyorsa browserContext.request kullanın. Tarayıcı başlatmadan yalnızca API odaklı bir context istiyor ve browser sayfalarıyla otomatik çerez paylaşımına ihtiyaç duymuyorsanız playwright.request.newContext() kullanın. Burada yalnızca ilk yol test edildi.

Firefox ve WebKit burada test edildi mi?
Hayır. Tüm testler bir makinede, tek çalıştırmada Chromium üzerinde yapıldı. Playwright’ın üç motor desteği (Chromium, Firefox, WebKit) ve Python, Java, .NET istemcileri belgelenmiş yeteneklerdir; bunları olduğu gibi raporluyorum, doğrulamış değilim — Firefox ve WebKit eşdeğerliği, proxy kullanımı, paralel ölçek ve ağ kesiştirme bu sayıların kapsamı dışındadır.

Bu inceleme hangi ortamı kapsıyor?
Playwright 1.56.0, Node v22.22.3, macOS arm64 ve sadece Chromium. Firefox, WebKit, proxy kullanımı, paralel ölçek, anti-bot davranışı ve daha yeni Playwright sürümleri çalıştırmaya dahil edilmedi. Kurulum için kütüphane ve ayrıca ayrı bir tarayıcı derlemesi indirilmesi gerekiyordu.