Recenzja Playwright: renderowanie JavaScriptu w Chromium, a warstwa crawl pozostaje po Twojej stronie

Playwright to framework Microsoftu do automatyzacji przeglądarki: biblioteka oparta na Apache-2.0, pisana z myślą o TypeScript, która uruchamia prawdziwą przeglądarkę, steruje nią przez jedno API i zwraca stronę dopiero po wykonaniu JavaScriptu. Jest promowany jako framework do testów end-to-end, ale to właśnie jego silnik wiele osób po cichu wybiera wtedy, gdy odpowiedź HTTP zwraca pustą powłokę zamiast danych. Pod względem zastosowania konkuruje z Puppeteerem i Selenium — sterujesz prawdziwą przeglądarką, a nie analizujesz klienta HTTP.

Przepuściłem microsoft/playwright 1.56.0 przez stały zestaw testów scrapingowych — statyczny katalog z paginacją, artykuł, katalog renderowany przez JavaScript, API JSON, uszkodzony błąd 500, mały graf crawl oraz dwie publiczne strony ćwiczeniowe — na Node v22.22.3, macOS arm64, wyłącznie w Chromium. Część odpowiedzialna za renderowanie wypadła bez zarzutu. Części crawl po prostu nie ma, a to najważniejsza rzecz, jaką warto zrozumieć o tym narzędziu, zanim się na nie zdecydujesz.

Co się wyróżniło

Na szczycie listy znalazły się dwa wyniki i wskazują one na nieco różne strony narzędzia.

Pierwszy to oczekiwany rezultat przeglądarkowy, zależny od zastosowanych przeze mnie warunków oczekiwania. Po page.goto(..., { waitUntil: 'domcontentloaded' }) test dynamicznego fixture czekał na #dynamic-products article.product-card, a publiczny test Quotes to Scrape czekał na .quote. Po pojawieniu się tych selektorów specyficznych dla aplikacji uruchomienia zwracały 8/8 elementów fixture i 10 cytatów ze strony publicznej; wynik fixture osiągnął recall 1.0 względem prawdy referencyjnej z ośmioma elementami. Nie trzeba było pisać własnej pętli pollingowej, ale Playwright nie rozwiązał problemu gotowości sam z siebie — to test dostarczył warunek zakończenia. Na pierwszym wywołaniu zapisał się też pełny zrzut ekranu strony.

Drugi wynik korzystał z browserContext.request: konkretnie ctx.request.get(...) po tym, jak Chromium był już uruchomiony i istniał kontekst przeglądarki. Wywołanie trafiło bezpośrednio do endpointu JSON fixture i zwróciło 8/8 produktów bez tworzenia ani renderowania strony. To pomija pracę DOM, ale nie koszt procesu przeglądarki w tym środowisku testowym. Klient request powiązany z kontekstem może dzielić stan cookies ze stronami przeglądarki; samodzielne playwright.request.newContext() nie wymaga kontekstu przeglądarki, ale nie współdzieli z nim automatycznie sesji. W teście sprawdziłem tylko pierwszą ścieżkę.

Playwright nie oferuje też kolejki crawl, zapisu zbioru danych ani automatycznego throttlingu. Mój test grafu crawl — przechodzenie po linkach wewnętrznych, śledzenie głębokości i unikanie ponownych odwiedzin — dotarł do 12 stron na głębokościach {0:1, 1:4, 2:7}, ale to BFS napisałem sam. Playwright otwiera strony i je analizuje; trwałość frontu, polityka URL, ponawianie prób i harmonogramowanie należą do innej warstwy.

Czym właściwie jest Playwright

To narzędzie — microsoft/playwright na GitHubie — jest napisane w TypeScript, objęte licencją Apache-2.0 i rozwijane przez Microsoft. Testowana kompilacja to 1.56.0 z 9 lipca 2026. Wyniki odnoszą się do tej wersji, a nie stanowią deklaracji zgodności dla późniejszych wydań.

Oficjalne pozycjonowanie jest precyzyjne: to framework do testowania i automatyzacji WWW, który steruje Chromium, Firefoksem i WebKitem przez jedno API. Główna ścieżka Playwrighta to runner testów z fixture, asercjami i podglądem trace. Użycie go jako podstawy do scrapingu oznacza skorzystanie z udokumentowanego trybu Library mode: chromium.launch(), potem context, potem page, poza harness testowym. Wszystko w tej recenzji korzystało właśnie z tego publicznego API. Nie robiłem testu zgodności między wersjami, więc nie jest to twierdzenie, że każde sprawdzone zachowanie pozostaje stabilne w kolejnych wydaniach.

Dokumentowana szerokość wsparcia to wszędzie główny atut, więc powiem to ostrożnie. Playwright obsługuje trzy silniki przeglądarki — Chromium, Firefox i WebKit — przez jedno API, a dodatkowo oferuje pierwszorzędne klienty w Pythonie, Javie i .NET, obok JavaScriptu. To jest udokumentowane i faktycznie stanowi największą przewagę narzędzia pod względem zakresu. To, co faktycznie przetestowałem, jest węższe:

Jeśli cel zachowuje się inaczej w WebKit Safari albo Twój zespół pracuje w Pythonie, to właśnie ta szerokość jest argumentem za Playwrightem — tylko nie traktuj moich wyników jako dowodu równości Firefoxa czy WebKita, bo ich nie testowałem.

Jak to działa pod maską

Model mentalny jest prosty: to silnik przeglądarki, którym sterujesz. chromium.launch() uruchamia proces przeglądarki. context to odizolowana sesja z własnymi cookies, storage i cache; page to karta w obrębie tego kontekstu. Wywołujesz page.goto(url), czekasz na warunek oznaczający gotowość aplikacji i odczytujesz wynikowy DOM za pomocą helperów takich jak page.$$eval. To bliższe przeglądarce używanej przez człowieka niż parsowanie odpowiedzi HTTP, ale nie oznacza pełnej zgodności środowiska: sygnały headless, viewport, locale, fonty, stan profilu, ścieżka TLS/sieci oraz zabezpieczenia strony nadal mogą zmienić to, co zostanie zwrócone. W tej recenzji nie testowałem zachowań antybotowych ani zgodności z pełną przeglądarką produkcyjną.

page.screenshot() zapisuje wyrenderowaną stronę, pełną albo przyciętą, i w moim uruchomieniu zadziałało to przy pierwszym wywołaniu. A wspomniane API request — context.request.get — korzysta z cookies tego samego kontekstu, ale omija renderowanie, więc w jednym skrypcie można łączyć „załaduj stronę i odczytaj DOM” z „po prostu pobierz endpoint JSON” bez zmiany narzędzia.

Czego pod maską nie ma, to mechanika crawl. Nie ma tu scheduler’a requestów, utrwalonego zbioru odwiedzonych adresów, polityki uprzejmości ani pipeline’u eksportu. Ograniczony traversal łatwo naszkicować, ale niezawodne zarządzanie frontem wymaga też normalizacji URL, obsługi redirectów, ponowień, reguł zakresu, throttlingu i odtwarzania po awarii. Tę warstwę budujesz sam albo korzystasz z frameworka, który już opakowuje silnik przeglądarki.

Instalacja i realia wdrożenia

Instalacja składa się z dwóch kroków, a drugi z nich niesie największy ciężar wdrożeniowy. npm install playwright pobiera bibliotekę; osobne npx playwright install ściąga buildy przeglądarek (u mnie Chromium). Trzeba uwzględnić miejsce na dysku, czas pobierania, cache przeglądarek w CI i sprzątanie procesów — nie traktować pakietu npm jak całego działającego systemu.

Jeśli instalujesz Playwrighta z myślą o scraperze, a potem podążasz za tutorialem do testów, zaczniesz od plików testowych i asercji expect(). Kod scrapingowy korzysta natomiast bezpośrednio z API biblioteki. Oba podejścia są udokumentowane, ale różnica ma znaczenie przy szukaniu przykładów i wyborze komend wdrożeniowych.

W tym uruchomieniu praktyczne zalety były bardzo konkretne: konteksty przeglądarki izolowały stan sesji, wywołania async dobrze się komponowały, screenshot wymagał jednego wywołania, a błędne HTTP 500 dało się dalej analizować przez obiekt response. Słabym punktem była raczej operacyjna niż składniowa strona: build przeglądarki trzeba było zainstalować i osobno zarządzać jego cyklem życia niezależnie od biblioteki.

Wyniki z praktyki

Wszystkie lokalne liczby zostały uzyskane na serwerze fixture pod 127.0.0.1, z prawdą referencyjną zapisaną przed crawl. Dokładny harness znajduje się w run_playwright_material_tests.mjs, a zatwierdzone surowe artefakty zawierają prawdę referencyjną i wyniki poszczególnych testów. To nadal są obserwacje autora z jednej maszyny i jednego uruchomienia; linki pokazują powierzchnię reprodukcji, a nie zamieniają tego w szeroki benchmark.

Pętla paginacji podążała za linkiem next jawnie; Playwright sam nie wykrywał stron. Selektor artykułu utrzymywał nawigację i stopkę poza wynikiem treści. W scenariuszu błędu nawigacja zwracała obiekt response ze statusem 500 zamiast rzucać wyjątek, pozostawiając wywołującemu decyzję, czy logować, ponawiać próbę czy iść dalej. Dwa publiczne targety ćwiczeniowe zwróciły liczbę elementów pokazanych w tabeli.

Warto jasno wyznaczyć granicę: wszystko tutaj zostało uruchomione w Chromium, na jednej maszynie, raz. Tabela możliwości oddziela udokumentowaną szerokość wsparcia od zachowania faktycznie sprawdzonego w testach. Nie uruchamiałem zestawu ponownie na innej wersji Playwrighta, więc nie da się z tego wyprowadzić wniosku międzywersyjnego. Czasy per test również nie są podane jako benchmark; pojedynczy pomiar stoperem na jednym laptopie nie nadaje się do porównania szybkości.

Gotowość jest częścią kontraktu ekstrakcji

Wyniki dynamiczne zależały od waitów, które reprezentowały interesujące mnie dane, a nie tylko samą nawigację przeglądarki. Dla lokalnego katalogu harness przechodził z waitUntil: 'domcontentloaded', a następnie wywoływał waitForSelector('#dynamic-products article.product-card') z timeoutem 15 sekund. Publiczny test Quotes JS używał tego samego stanu nawigacji i czekał na .quote z timeoutem 20 sekund. Ekstrakcja następowała dopiero po pojawieniu się tych selektorów.

To rozróżnienie ma znaczenie przy adaptacji skryptu. domcontentloaded mówi jedynie, że dokument początkowy został sparsowany; nie oznacza, że przyszła opóźniona odpowiedź API, zakończyła się hydratacja, przestała rosnąć nieskończona lista albo że wirtualizowany wiersz pojawił się w viewportcie. Selektor jest przydatny wtedy, gdy wystarczy obecność jednego pasującego elementu. Jeśli kompletność zależy od znanej odpowiedzi, liczby elementów, stanu aplikacji albo spokojnego okna sieciowego, trzeba czekać właśnie na ten warunek. Warunek powinien być powiązany z kontraktem wyniku: „istnieje co najmniej jedna karta” i „załadowane zostały wszystkie oczekiwane strony” to dwie różne asercje.

Obsługa timeoutów też należy do wywołującego. Test używał skończonych timeoutów selektorów, ale nie badał polityki retry ani nie odróżniał wolnej strony od selektora, który zmienił się na stałe. Produkcyjny wrapper powinien zapisać, który warunek gotowości zawiódł, zarejestrować wystarczająco dużo stanu strony, by można było to zdiagnozować, i zdecydować, czy kolejna próba nawigacji jest bezpieczna. Playwright daje wydarzenia i DOM; nie odgadnie, co oznacza „pełne dane” w Twoim zadaniu.

Tę granicę warto dokumentować obok każdego ekstraktora, a nie zostawiać jej jako domyślnego timeoutu.

Ścieżka API ma analogiczny kontrakt. ctx.request.get było tu właściwe, ponieważ kontekst przeglądarki już istniał, a współdzielenie sesji może być przydatne. Jeśli zadanie odkryje, że endpoint danych działa bez jakiejkolwiek sesji przeglądarkowej, samodzielny request context to inna architektura z innym cyklem życia i zachowaniem cookies. W tym uruchomieniu nie porównywałem tych dwóch podejść. Traktuj „bez renderowania DOM” jako zmierzony fakt, a dopiero potem osobno zdecyduj, czy szerszy workflow wymaga procesu przeglądarki.

Pytanie o crawl

Wynik grafu crawl to ten element, który mówi, jak należy myśleć o Playwrightcie. Dwanaście stron, trzy poziomy, poprawnie — i cała logika przejścia była moja. Playwright dostarczył połowę „otwórz ten URL i przeczytaj go”; ja dostarczyłem kolejkę, zbiór odwiedzonych i śledzenie głębokości.

W małych, ograniczonych zadaniach to nie problem. W przypadku crawl na większą skalę oznacza to, że albo piszesz crawlera na bibliotece przeglądarkowej, albo łączysz Playwrighta z czymś, co już crawlerem jest. Udokumentowanym wzorcem jest Crawlee, które opakowuje Playwrighta (i Puppeteera) w prawdziwą kolejkę requestów, magazyn datasetów i automatyczny throttling — zachowujesz renderowanie Playwrighta, a pożyczasz warstwę orkiestracji. Jeśli chcesz, by kolejka była wbudowana w sam framework, a nie dosztukowana, to właśnie cała idea Scrapy, choć Scrapy działa przede wszystkim po HTTP i sam z siebie nie renderuje JavaScriptu. Chodzi nie o to, że Playwright jest niewystarczający; chodzi o to, że „automatyzacja przeglądarki” i „crawl” to dwa różne zadania, a Playwright deklaruje tylko jedno z nich.

Dziewięciostronicowy BFS jasno pokazuje granicę odpowiedzialności. Dostarczał kolejkę, visited set i śledzenie głębokości dla kontrolowanego grafu. Produkcyjny front nadal musi zdefiniować normalizację URL, obsługę przekierowań, dozwolone hosty, duplikaty kluczy, ponowienia, współbieżność, opóźnienie per host, trwałość i semantykę restartu. Eksport to kolejny wybór: fixture zapisywał JSON i CSV, bo tak zrobił harness, a nie dlatego, że Playwright dostarcza abstrakcję datasetu.

Projekt sesji też wpływa na wrapper. Jeden browser może zawierać wiele kontekstów z izolowanymi cookies i storage, ale ta recenzja nie mierzyła skali wielu kontekstów ani izolacji awarii. Ponowne użycie kontekstu może zachować logowanie i zmniejszyć koszty setupu; tworzenie osobnych kontekstów może zapobiec przeciekaniu stanu między zadaniami. To polityki na poziomie crawlera, mimo że Playwright udostępnia prymityw kontekstu. Warto benchmarkować wybrany cykl życia w faktycznym buildzie przeglądarki i środowisku wdrożenia.

Plusy i minusy

Plusy:

• Wykonywanie JavaScriptu w prawdziwym silniku Chromium; oba dynamiczne cele osiągnęły selektory użyte jako warunki gotowości.
• Pełny screenshot został zapisany już przy pierwszym wywołaniu.
• Selektory poprawnie wyciągały pola ze statycznego katalogu i artykułu w kontrolowanych fixture.
• browserContext.request dotarł do endpointu JSON bez renderowania strony, a już uruchomiony proces przeglądarki pozostał częścią harnessu.
• Odporność na złą odpowiedź: HTTP 500 dało się odczytać, a nawigacja nie rzuciła wyjątku.
• Udokumentowane wsparcie trzech silników (Chromium, Firefox, WebKit) przez jedno API oraz klientów Python, Java i .NET (udokumentowane; tutaj sprawdzono tylko Chromium).
• Licencja Apache-2.0 i rozwój pod skrzydłami Microsoftu.
• Bardzo dobre doświadczenie deweloperskie w trybie library mode: jedno API dla wszystkich silników, pierwszorzędne async i banalne screenshoty.

Minusy:

• Brak wbudowanej kolejki crawl, datasetu i automatycznego throttlingu — zadania crawl na większą skalę to Twój kod albo wrapper taki jak Crawlee.
• Ciężar przeglądarki: pobieranie binarek i koszt per strona to realny narzut względem narzędzia działającego wyłącznie po HTTP.
• Domyślna rama to runner testów; scraping wymaga wiedzy, że istnieje library mode, i zejścia z promowanej ścieżki.
• Sprawdzono tylko Playwright 1.56.0 i Chromium; zgodność między wersjami i silnikami nie była testowana.
• Brak własnego wyjścia typu JSON zgodnego ze schematem; selektory i kształt danych trzeba zbudować samemu.

Dla kogo to jest, a kto powinien pójść gdzie indziej

Jeśli Twój problem polega na renderowaniu stron, których dane pojawiają się dopiero po uruchomieniu JavaScriptu, albo na pobieraniu screenshotów razem z danymi DOM, Playwright jest sensownym kandydatem do odtworzenia na Twoich targetach. Zespoły już używające Playwrighta do testów mogą przenieść te same pojęcia i umiejętność pracy z selektorami do library mode. Klienci Python, Java i .NET są udokumentowanymi opcjami, ale ta recenzja sprawdzała wyłącznie Node i Chromium.

W trzech przypadkach warto rozważyć inną warstwę. Jeśli potrzebne dane są już obecne w odpowiedzi HTTP, narzędzie HTTP-first pozwala uniknąć narzutu startu przeglądarki i renderowania; Colly to biblioteka crawlerowa z tej kategorii, a Trafilatura jest nastawiona na ekstrakcję artykułów. Jeśli potrzebujesz kolejkowania, trwałości i throttlingu, użyj frameworka crawlerowego albo wrappera do Playwrighta. Jeśli potrzebujesz wyjścia w kształcie schematu bez ręcznego utrzymywania selektorów, porównaj zarządzane usługi ekstrakcji. Żadna z tych alternatyw nie była benchmarkowana w tej recenzji.

Jeśli zastanawiasz się konkretnie między Playwrightem a Puppeteerem, to jest osobny pojedynek; nasze porównanie side by side przepuszcza oba przez te same fixture i pokazuje, gdzie faktycznie kończy się wybór.

Alternatywy i miejsce zarządzanej ekstrakcji

Playwright jest darmowy, objęty Apache-2.0 i hostowany samodzielnie. To Ty odpowiadasz za wdrożenie przeglądarek, selektory, warunki gotowości, kod crawl, aktualizacje i obsługę błędów. Ta recenzja nie mierzyła skuteczności antybotowej ani nie porównywała całkowitego kosztu działania z usługą zarządzaną.

W świecie open source najpraktyczniej porównywać narzędzia według zadania. Do crawl na większą skalę na bazie przeglądarki Crawlee dodaje kolejkę i dataset, których Playwright nie ma. Jeśli celem wyjściowym są Markdowny gotowe dla LLM z prawdziwej przeglądarki, a nie ręcznie kształtowane wiersze, Crawl4AI uruchamia przeglądarkę i produkuje Markdown pod taki pipeline. A jeśli porównujesz kilka takich narzędzi naraz, nasze zestawienie open-source scraperów pokazuje te kategorie obok siebie.

Ujawnienie: Thunderbit to produkt wydawcy i nie był uruchamiany przez ten fixture Playwrighta. Reprezentuje kategorię zarządzanej ekstrakcji: usługa obsługuje renderowanie i zwraca tekst strony lub rekordy zgodne ze schematem, podczas gdy Playwright pozostawia obsługę przeglądarki i logikę selektorów po stronie dewelopera. Porównanie dotyczy więc modelu hostingu, kształtu wyjścia i modelu kosztowego — a nie wyniku wydajnościowego z tej recenzji.

Wypróbuj Thunderbit do ekstrakcji danych z WWW

Werdykt

Użyj Playwrighta wtedy, gdy Twój cel wymaga silnika przeglądarki i jesteś gotów wziąć na siebie warunki gotowości, selektory oraz orkiestrację crawl. Tabela wyników pokazuje, że jego tryb biblioteczny w Chromium poradził sobie w tym autor-samodzielnie wykonanym passie ze statycznymi, dynamicznymi, API, screenshotowymi i błędnymi fixture zgodnie z oczekiwaniami.

Zachowaj jednak granicę dowodową: sprawdzono tylko Chromium i Node, przejście po 12 stronach opierało się na ręcznie napisanym BFS, browserContext.request omijał renderowanie strony, ale nie uruchomiony już proces przeglądarki, a każda dynamiczna ekstrakcja korzystała z jawnie podanego selektora gotowości. Te ograniczenia czynią z Playwrighta w tej recenzji prymityw przeglądarkowy, a nie zmierzony system crawl end-to-end.

Wypróbuj Thunderbit do ekstrakcji danych z WWW Get Started Free

FAQ

Czy nadal potrzebuję waitów przy scrapingu w Playwrightcie? Tak. Samo wykonanie w przeglądarce nie mówi skryptowi, kiedy dane aplikacji są gotowe. W tych testach przechodziliśmy do domcontentloaded, a następnie czekaliśmy na selektor specyficzny dla celu przed ekstrakcją. W produkcji może być potrzebny inny sygnał, na przykład response, stan lokatora albo zdarzenie aplikacji.

Czy Playwright potrafi samodzielnie crawlować całą witrynę? Nie out of the box. Nie ma wbudowanej kolejki requestów, zapisu datasetu ani automatycznego throttlingu — mój test grafu crawl osiągnął 12 stron na głębokościach {0:1, 1:4, 2:7} tylko dlatego, że ręcznie napisałem BFS. Do pracy na większą skalę połącz Playwrighta z Crawlee, które opakowuje go w prawdziwą warstwę crawl, albo użyj frameworka crawlerowego.

Kiedy używać browserContext.request, a kiedy samodzielnego request context? Użyj browserContext.request, gdy wywołania HTTP powinny współdzielić cookies ze stronami w istniejącym kontekście przeglądarki. Użyj playwright.request.newContext(), gdy chcesz mieć kontekst tylko do API, bez uruchamiania przeglądarki, i nie potrzebujesz automatycznego współdzielenia cookies z kartami przeglądarki. Tutaj testowano tylko pierwszą ścieżkę.

Czy testowano tutaj Firefoxa i WebKit? Nie. Wszystkie testy uruchomiono w Chromium, na jednej maszynie, jednorazowo. Wsparcie Playwrighta dla trzech silników (Chromium, Firefox, WebKit) oraz klientów Python, Java i .NET jest udokumentowane — podaję je jako deklarowane możliwości, a nie zweryfikowane wyniki. Zgodność Firefoxa i WebKita, proxy, skala równoległa i intercepcja sieci nie mieszczą się w zakresie tych liczb.

Jakie środowisko obejmowała ta recenzja? Playwright 1.56.0, Node v22.22.3, macOS arm64 i wyłącznie Chromium. Firefox, WebKit, proxy, skala równoległa, zachowania antybotowe i późniejsze wersje Playwrighta były poza zakresem uruchomienia. Instalacja wymagała biblioteki oraz osobnego pobrania builda przeglądarki.