Każdy poradnik „Scrapy vs. Selenium” w internecie w gruncie rzeczy powtarza to samo: Scrapy jest szybszy, Selenium ogarnia JavaScript, a potem trzeba wybrać mniejsze zło. Kierunek bywa trafny, ale takie uniwersalne hasła o liczbie stron na minutę zwykle nie wytrzymują zderzenia z rzeczywistością. Prawdziwa przepustowość zależy od celu, sieci, współbieżności, cyklu życia przeglądarki, mechanizmów oczekiwania i zabezpieczeń anty-bot.
Ten przewodnik porównuje architekturę i praktyczne kompromisy, które naprawdę mają znaczenie przy kolejnych projektach. Omawia też to, co większość zestawień pomija: jak automatyzacja przeglądarki zmienia model zasobów, dlaczego selektywne renderowanie często wygrywa z pełnym crawl’em w przeglądarce oraz kiedy zarządzane API do ekstrakcji będzie lepszym wyborem niż którykolwiek z tych frameworków.
Szybki werdykt: Scrapy kontra Selenium w 2026
Mówiąc krótko: Scrapy wygrywa szybkością, skalą i oszczędnością zasobów wszędzie tam, gdzie strona renderuje się po stronie serwera. Selenium sprawdza się wtedy, gdy potrzebujesz prawdziwej przeglądarki do prawdziwych zadań — klikania, wpisywania, czekania, aż pojawi się modal. Żadne z tych narzędzi nie radzi sobie dobrze z nowoczesnymi zabezpieczeniami anty-bot „z pudełka”, a Playwright po cichu przejął większość przypadków użycia, po które wcześniej sięgało się po Selenium.
Oto macierz decyzji, z której sam korzystam:
| Twoja sytuacja | Wybierz |
|---|---|
| Strony statyczne lub renderowane po stronie serwera, duża skala | Scrapy |
| SPA z dużą ilością JS, logowaniem, klikaniem i wieloetapowymi procesami | Selenium lub Playwright |
| Strona mieszana — głównie statyczna, ale z kilkoma sekcjami tylko po JS | Hybryda Scrapy-Playwright |
| Znane adresy URL, potrzebujesz tylko ustrukturyzowanych danych i minimalnej obsługi | API do ekstrakcji AI (Thunderbit i podobne) |
Na połowę 2026 roku Scrapy 2.17.0 jest już dostępny, Selenium 4 dalej rozszerza wsparcie dla WebDriver BiDi, a scrapy-playwright zapewnia utrzymywaną metodę kierowania wybranych zapytań Scrapy przez przeglądarkę. Warto trzymać tę macierz pod ręką — reszta artykułu wyjaśnia, dlaczego działa.
Czym są Scrapy i Selenium (i dlaczego programiści wciąż je porównują)
Porównywanie Scrapy z Selenium jest trochę jak zestawianie ciężarówki dostawczej z samochodem osobowym. Oba środki służą do przewożenia czegoś z punktu A do punktu B, ale jeden zaprojektowano do sprawnego transportu dużego ładunku, a drugi dla człowieka, który musi faktycznie reagować na drogę. Spór trwa, bo oba narzędzia mogą służyć do scrapingu — po prostu zostały stworzone do różnych rzeczy, a wiele zespołów wybiera złe rozwiązanie, zanim zdąży to zauważyć.
Scrapy: asynchroniczny silnik crawl’owania
Scrapy to framework w Pythonie oparty na modelu event-driven i nieblokującym I/O Twisted. To nie jest przeglądarka — nigdy nią nie była — tylko wysyła żądania HTTP i analizuje to, co wraca w HTML-u. Właśnie w tym tkwi cały sekret. Ponieważ nie musi czekać, aż przeglądarka coś wyrenderuje, może odpalać dziesiątki zapytań równocześnie bez blokowania.
Domyślnie Scrapy oferuje spidery, pipeline’y elementów, eksportery feedów, middleware do retry oraz ograniczanie tempa. To nie jest framework typu „resztę musisz zbudować sam” — sporo produkcyjnych tematów jest już załatwionych. Dokumentacja architektury opisuje Engine, Scheduler, Downloader i Item Pipeline jako osobne, wymienne komponenty, i właśnie dlatego framework tak dobrze znosi upływ czasu: można dokładać funkcje bez przepisywania rdzenia.
Jest jednak haczyk: brak przeglądarki oznacza brak wykonywania JavaScriptu. Jeśli dane ładują się przez klientowe wywołanie fetch po wyrenderowaniu strony, Scrapy tego nie zobaczy. Czyta tylko początkową odpowiedź HTML i na tym koniec.
Selenium: przeglądarka, którą możesz programować
Selenium steruje prawdziwymi przeglądarkami — Chrome, Firefox, Edge — przez protokół W3C WebDriver, czyli standard, który sprawia, że Selenium jest niezależne od języka i przeglądarki, a nie tylko jakimś obejściem dla Chrome. Renderuje JavaScript, wykonuje zapytania AJAX i potrafi klikać, przewijać oraz wpisywać dokładnie tak, jak zrobiłby to człowiek.
To czyni Selenium dobrym wyborem wszędzie tam, gdzie liczy się interakcja: wieloetapowe logowanie, kreatory, nieskończone przewijanie, rozwijane menu wywołujące API. Ale każda taka sesja przeglądarki jest ciężka. Własne wytyczne Selenium dotyczące rozmiaru Gridu sugerują przyjąć orientacyjnie około 1 GB RAM na jedną sesję przeglądarki już na etapie planowania — i to zanim doliczysz obciążenie CPU wynikające z samego renderowania stron.
Jeden szczegół, który ciągle myli ludzi: zakończenie ładowania strony nie oznacza, że interfejs jest gotowy. Dokumentacja Selenium ostrzega też przed mieszaniem implicit i explicit waits, bo wtedy timeouty bardzo szybko stają się nieprzewidywalne. Jeśli skrypt Selenium działa niestabilnie, to zwykle właśnie dlatego.
Scrapy kontra Selenium: wydajność bez fałszywych, uniwersalnych liczb
Rzetelny benchmark musi publikować testowane strony, stan cache, warunki sieciowe, współbieżność, strategię ponownego użycia przeglądarki, warunki oczekiwania i pełny kod. Bez tego liczba stron na minutę jest marketingiem, nie dowodem. Porównanie architektury nadal jednak mówi bardzo dużo:
| Cecha obciążenia | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| HTML renderowany po stronie serwera | Bezpośrednia ścieżka HTTP | Pełna ścieżka przez przeglądarkę | Korzysta z bezpośredniej ścieżki Scrapy |
| Treść renderowana przez JavaScript | Wymaga dodatkowego renderera | Natywne wykonanie w przeglądarce | Selektywne renderowanie przez przeglądarkę |
| Model współbieżności | Asynchroniczny scheduler żądań | Sesje przeglądarki zarządzane przez kod lub Grid | Scheduler Scrapy + konteksty przeglądarki |
| Profil zasobów | Bez narzutu renderowania przeglądarki | Narzut CPU i pamięci przeglądarki | Koszt przeglądarki tylko dla oznaczonych żądań |
| Najlepszy sposób pomiaru | Elementy na minutę przy bezpiecznym poziomie błędów | Ukończone procesy na minutę przy bezpiecznym poziomie błędów | Osobno mierzone przepustowości dla żądań statycznych i renderowanych |
Domyślne ustawienie współbieżnych żądań w Scrapy to górny limit, a nie obiecana przepustowość. Rzeczywista szybkość zależy od opóźnień, limitów per domena, throttlingu, retry, rozmiaru odpowiedzi, pracy parsera i akceptowalnego tempa żądań po stronie celu. Selenium może ponownie wykorzystać sesję przeglądarki, więc nie jest z definicji ograniczone do jednej nowej przeglądarki na stronę, ale każda aktywna sesja nadal uruchamia i renderuje środowisko przeglądarki.
Model hybrydowy jest atrakcyjny, bo zwykłe żądania prowadzi przez szybką ścieżkę HTTP w Scrapy, a tylko strony wymagające renderowania kieruje do przeglądarki. Zwykle obniża to koszt pracy przeglądarki, ale nie oznacza automatycznie wyższej szybkości: trzeba mierzyć osobno ścieżki statyczne i renderowane, uwzględniać błędy i retry, a współbieżność dostrajać zarówno do bezpieczeństwa po stronie serwisu, jak i dostępnej pamięci.
Kluczowe różnice, które wpływają na decyzję
Szybkość nie jest jedyną zmienną. Kilka praktycznych czynników ma równie duże znaczenie, gdy wszystko działa już produkcyjnie.
Renderowanie JavaScriptu i treści dynamiczne
Sam Scrapy jest ślepy na wszystko, co renderuje się po stronie klienta. Selenium widzi wszystko, bo jest prawdziwą przeglądarką. Złoty środek — Scrapy-Splash (starszy, oparty na Lua) oraz scrapy-playwright (nowoczesny, zalecany) — pozwala selektywnie renderować JS w pętli crawl’owania Scrapy zamiast uruchamiać pełną przeglądarkę dla każdego żądania. Jeśli 80–90% stron docelowych to statyczny HTML, a tylko kilka wymaga JS, selektywne renderowanie jest oczywistą architekturą. Renderowanie wszystkiego przez przeglądarkę tylko dlatego, że kilka stron tego wymaga, to zwykłe marnowanie mocy obliczeniowej.
Skalowalność i współbieżność
Skalowanie Scrapy z 1 000 do 1 000 000 stron to głównie kwestia infrastruktury — zwiększasz liczbę równoczesnych żądań, ewentualnie rozkładasz obciążenie na workerów z Redisem. Skalowanie Selenium oznacza liniowe dokładanie instancji przeglądarek, a więc liniowy wzrost zużycia RAM i CPU, czyli zarządzanie farmą przeglądarek przez Selenium Grid i radzenie sobie z awariami. Nie chodzi o to, że Selenium nie da się skalować — chodzi o to, że skalowanie jest tu projektem infrastrukturalnym, a nie prostą zmianą konfiguracji.
Potoki danych i eksport
Item pipeline w Scrapy obsługuje walidację, deduplikację i eksport do JSON, CSV lub bazy danych jako wbudowaną funkcję. Selenium nie daje niczego takiego — całą serializację i zapis danych musisz napisać sam. Jeśli zależy ci na jakości danych i integracji z dalszymi etapami procesu, Scrapy daje bardzo konkretny start za darmo.
Utrzymanie i długoterminowa niezawodność
Zauważyłem pewien wzorzec: spidery Scrapy zwykle starzeją się całkiem dobrze, bo architektura oparta na middleware wymusza pewną strukturę. Skrypty Selenium robią się kruche — aktualizacje przeglądarek psują sterowniki, problemy z timingiem powodują niestabilne uruchomienia, a każda zmiana DOM wymaga aktualizacji selektorów. Widziałem też programistów piszących wprost na forach, że scraper oparty na Selenium „nie wydaje się najlepszym wyborem do czegoś, co chcemy sprzedać klientowi” — i szczerze mówiąc, ten instynkt jest trafny, jeśli projekt ma przetrwać dłużej niż kilka miesięcy bez ciągłego grzebania w kodzie.
Rzeczywistość anty-bot: jak każde narzędzie radzi sobie z zabezpieczeniami w 2026
To jest część, którą inne porównania zwykle pomijają, a właśnie ona decyduje o tym, czy scraper w ogóle działa. Ani Scrapy, ani Selenium nie zostały stworzone z myślą o nowoczesnej infrastrukturze anty-bot, a udawanie, że jest inaczej, kończy się nieprzyjemnym zaskoczeniem na produkcji.
| Warstwa zabezpieczenia | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Renderowanie JS | ❌ Wymaga middleware | ✅ | ✅ | ✅ Wbudowane |
| Fingerprint TLS | ⚠️ Możliwe do wykrycia | ⚠️ Możliwe do wykrycia | ⚠️ Lepsze, ale nie rozwiązane | ✅ Obsługiwane |
| Rozwiązywanie CAPTCHA | ❌ Ręczne | ❌ Ręczne | ❌ Ręczne | ✅ Wbudowane |
| Rotacja limitów / rate limit | ⚠️ Własne proxy | ⚠️ Własne proxy | ⚠️ Własne proxy | ✅ Zarządzane |
Scrapy odpada przy kontroli fingerprintu przeglądarki, bo tak naprawdę nie ma czego fingerprintować — to po prostu klient HTTP, a wielu dostawców anty-bot oznacza ruch, który nie wygląda jak pochodzący z prawdziwej przeglądarki. Selenium przechodzi podstawowe testy JS, bo jest prawdziwą przeglądarką, ale nadal można je wykryć po sygnałach takich jak navigator.webdriver, czyli standardowym znaczniku ustawionym na true podczas automatyzacji. Poprawki typu undetected-chromedriver próbują to maskować, ale tak naprawdę grają w „whack-a-mole” z dostawcami detekcji, którzy regularnie aktualizują sygnatury.
Wyścig stealth i dlaczego rozwiązania DIY są kruche
Oto niewygodna prawda o łatkach anty-detekcyjnych: to nie jest rozwiązanie, tylko taśma produkcyjna do ich utrzymywania. undetected-chromedriver i playwright-stealth działają, dopóki Cloudflare Turnstile albo DataDome nie wypuści aktualizacji wykrywającej używaną technikę. Wtedy znowu trzeba łatać. Widziałem zespoły, które poświęcały więcej czasu na podtrzymywanie warstwy stealth niż na budowę samego scrapera.
Warto też osobno wspomnieć o rate limiting. Gdy serwer zwraca 429 Too Many Requests, nagłówek Retry-After jest sugestią, a nie nakazem — wiele stron w ogóle go nie wysyła, a niektóre ograniczają ruch innymi sygnałami. AutoThrottle w Scrapy pomaga, dostosowując opóźnienie na podstawie obserwowanych czasów odpowiedzi, ale działa reaktywnie, a nie zapobiegawczo.
I właśnie tutaj zarządzane API do ekstrakcji zaczyna mieć sens — obsługa anty-bot staje się problemem kogoś innego, a nie twojego zespołu. Wrócimy do tego za chwilę.
Wpływ Playwrighta: dlaczego „Scrapy vs. Selenium” to już nie cały obraz
Traktowanie tego jako pojedynku dwóch narzędzi pomija to, co naprawdę wydarzyło się w społeczności scrapingowej w ostatnich latach. Fora pełne są wpisów w stylu: „przeszedłem z Selenium na Playwright i jestem bardzo zadowolony” — a mimo to większość artykułów porównawczych wspomina o Playwright tylko mimochodem, jeśli w ogóle.
Playwright, rozwijany przez Microsoft, steruje Chromium, Firefoxem i WebKitem przez jedno API. Jego model actionability czeka, aż elementy będą widoczne, stabilne i faktycznie interaktywne, zanim wykona akcję — to mocno ogranicza problemy z timingiem, które męczą wiele skryptów Selenium. Obsługuje też browser contexts znacznie wydajniej, pozwalając tworzyć izolowane sesje bez kosztu uruchamiania nowej pełnej przeglądarki za każdym razem.
Kiedy Playwright całkowicie zastępuje Selenium
Do scrapingu — a nie do testowania przeglądarki na istniejącej infrastrukturze Selenium — Playwright w 2026 roku często jest po prostu lepszym narzędziem. Szybsze tworzenie kontekstów, mniejsze zużycie zasobów na stronę, natywne wsparcie async i wbudowana interceptacja sieci. Jeśli zaczynasz projekt scrapingu od zera i nie masz żadnego istniejącego zestawu testów Selenium, którego musisz chronić, niewiele jest powodów, żeby najpierw sięgać po Selenium.
Wyjątek: jeśli zespół już ma infrastrukturę testową opartą na Selenium albo potrzebujesz bardzo specyficznej konfiguracji profilu przeglądarki, której Playwright nie obsługuje równie elegancko, Selenium nadal ma swoje miejsce.
Jak działa scrapy-playwright
scrapy-playwright to handler pobierania dla Scrapy, który kieruje tylko te żądania, które oznaczysz meta={"playwright": True}, przez prawdziwą przeglądarkę — cała reszta zostaje na szybkiej, asynchronicznej ścieżce HTTP Scrapy. Oto uproszczony spider, który crawl’uje katalog z paginacją, gdzie karty produktów renderują się przez JS po stronie klienta:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Tylko strony, które naprawdę wymagają renderowania, przechodzą przez przeglądarkę. Na tym polega cały sens podejścia hybrydowego — nie płacisz za przeglądarkę przy każdym żądaniu, tylko przy tych, które naprawdę tego potrzebują.
Scrapy-Splash kontra Scrapy-Playwright: którego middleware użyć
Scrapy-Splash wymaga uruchomienia osobnej usługi Splash w Dockerze i pisania skryptów Lua do interakcji — działa, ale jest cięższym i starszym rozwiązaniem. scrapy-playwright integruje się bezpośrednio z asynchroniczną pętlą Scrapy, wspiera wszystkie trzy główne silniki przeglądarek i obsługuje złożone interakcje bez dokładania drugiego języka skryptowego. Jeśli zaczynasz nowy projekt w 2026 roku, naprawdę nie ma już powodu, by wracać do Splash.
Hybrydowa architektura gotowa do produkcji
Większość artykułów mówi tylko: „możesz połączyć Scrapy i Selenium” i na tym kończy. To nie jest architektura. To sugestia. Oto, jak wygląda rzeczywista konfiguracja produkcyjna.
Przepływ wygląda tak: scheduler Scrapy kieruje żądania przez router URL, który sprawdza, czy strona jest statyczna czy dynamiczna. Żądania statyczne trafiają bezpośrednio do standardowego downloadera Scrapy. Żądania dynamiczne są oznaczane i przekazywane do middleware Playwright, który zarządza pulą kontekstów przeglądarki. Obie ścieżki wracają do tego samego item pipeline do walidacji, deduplikacji i eksportu — niezależnie od tego, czy dane pochodzą z surowego HTML-a, czy z wyrenderowanego DOM-u, kończą jako ten sam wynik JSON, CSV albo zapis do bazy.
Kilka uwag wdrożeniowych, jeśli wchodzisz z tym na produkcję: użyj Dockera, żeby binaria przeglądarek Playwrighta działały identycznie w różnych środowiskach, ogranicz liczbę równoczesnych kontekstów Playwrighta na podstawie dostępnego RAM-u (na standardowej maszynie z 4 GB nie przekraczałbym 8–10 kontekstów) i uruchamiaj zadania cykliczne przez cron lub pipeline CI/CD zamiast trzymać proces w nieskończoność.
Taka konfiguracja daje maksymalną kontrolę. Oznacza też, że sam odpowiadasz za aktualizacje binariów przeglądarki, błędy cyklu życia kontekstów (niezamknięte strony zatrzymują crawl), rotację proxy i wszelkie łatki anty-bot, które trzeba dołożyć. To realne zobowiązanie inżynieryjne i warto to uczciwie nazwać, zanim się na nie zdecydujesz.
Dla zespołów, które chcą ustrukturyzowanego wyniku, ale nie chcą utrzymywać takiej infrastruktury, CLI Thunderbit podchodzi do problemu z innej strony:
thunderbit batch extract --schema schema.json --file urls.txt
Ten sam ustrukturyzowany JSON. Bez kodu spidera, bez puli przeglądarek, bez utrzymywania całej logiki anty-bot. Płacisz mniejszą elastycznością za szybsze wejście na produkcję — to uczciwy kompromis, a nie uniwersalne ulepszenie, i wszystko zależy od tego, ile kontroli naprawdę wymaga twój projekt.
Ścieżka „pomijamy framework”: kiedy AI API do scrapingu wygrywa z oboma rozwiązaniami
W pewnym momencie programista orientuje się, że tak naprawdę nie potrzebuje frameworka do crawl’owania. Potrzebuje ustrukturyzowanych danych z 500 znanych adresów URL, a budowanie do tego spidera, puli przeglądarek i warstwy anty-bot brzmi jak przesada — bo zwykle nią jest.
Właśnie tę lukę ma wypełniać Thunderbit i od razu powiem jasno: nie jest to zamiennik Scrapy w skomplikowanym, rekurencyjnym crawl’u z własną logiką. To inne narzędzie do innego, węższego problemu.
Open API: POST /extract przyjmuje JSON Schema i zwraca dane strukturalne zgodne z tym schematem — nie surowy HTML i nie stertę Markdowna, którą trzeba samemu parsować. POST /distill robi odwrotną rzecz, zwracając czysty Markdown gotowy do podania do pipeline’u RAG albo LLM. Zarządzana usługa obsługuje renderowanie JavaScriptu i obsługę anty-bot, więc nie musisz sam utrzymywać tej infrastruktury. Aktualny przewodnik Distill vs. Extract podaje 1 kredyt za stronę Distill i 20 za stronę Extract; przed planowaniem sprawdź dokumentację na żywo, bo warunki produktu mogą się zmieniać.
Serwer MCP: dla agentów AI, takich jak Claude czy Cursor, serwer MCP Thunderbit udostępnia distillation, ustrukturyzowaną ekstrakcję, sugestie pól i zadania wsadowe jako narzędzia, dzięki czemu agent może pobierać świeże dane z sieci w trakcie pracy, bez opuszczania swojego środowiska.
CLI: udokumentowane Thunderbit CLI obsługuje polecenia takie jak thunderbit extract <url> --schema schema.json i dobrze pasuje do pracy w terminalu oraz zadań cyklicznych. Możesz też przekazać zdistillowany Markdown do innego narzędzia przy jednorazowych zadaniach badawczych.
Jeśli wolisz w ogóle nie pisać kodu, rozszerzenie Thunderbit do Chrome oferuje to samo podejście w interfejsie klikania, co warto rozważyć, jeśli w zespole są osoby nietechniczne, które potrzebują danych bez używania terminala. Pisałem też szerzej o AI web scraping oraz scrapingu bez kodowania, jeśli chcesz pełniejszy obraz.
Bądź ze sobą szczery, do której grupy należysz: Scrapy nadal jest najlepszym wyborem do złożonych crawl’i obejmujących wiele serwisów, z własną logiką i rekurencyjnym podążaniem za linkami. Selenium albo Playwright — do procesów, w których liczy się interakcja. Ale „potrzebuję ustrukturyzowanych danych z tych znanych URL-i” to znacznie węższy problem, niż zostało to zaprojektowane do obsłużenia przez któreś z tych narzędzi, a API może naprawdę wyeliminować kod spidera, całą logikę anty-bot i ciągłe utrzymanie związane z posiadaniem takiej infrastruktury na własność.
Scrapy kontra Selenium kontra Playwright kontra AI API: porównanie obok siebie
| Cecha | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Obsługiwane języki | Tylko Python | Python, Java, C#, JS, Ruby | Python | REST (dowolny język) |
| Renderowanie JS | Nie (wymaga middleware) | Tak | Tak | Tak, wbudowane |
| Async / współbieżność | Natywne, wysokie | Ograniczone per instancja | Natywne przez Scrapy | Zarządzane po stronie serwera |
| Obsługa anty-bot | DIY | DIY | Częściowa | Wbudowana |
| Pipeline / eksport danych | Wbudowane | DIY | Wbudowane | Ustrukturyzowany JSON |
| Złożoność konfiguracji | Umiarkowana | Niska na start, wysoka w skali | Umiarkowana do wysokiej | Minimalna |
| Nakład utrzymania | Niski-umiarkowany | Wysoki | Umiarkowany | Prawie zerowy |
| Najlepsze zastosowanie | Duże crawl’e statyczne | Procesy wymagające interakcji | Strony mieszane statyczno-dynamiczne | Znane URL-e, wynik strukturalny |
Jeśli rozważasz też inne opcje scraperów poza tymi czterema, warto spojrzeć na to, jak wypadają alternatywy dla Instant Data Scraper i najlepsze AI web scrapery — rynek zrobił się gęsty, a nie każde narzędzie rozwiązuje ten sam problem.
Uwagi prawne i etyczne dotyczące scrapingu w 2026
Krótko, bo to nie jest główny temat, ale warto o tym pamiętać. Ustawienie ROBOTSTXT_OBEY w Scrapy sprawi, że spider będzie respektował reguły robots.txt — to dobra praktyka, ale warto wiedzieć, że sam Robots Exclusion Protocol wprost zaznacza, że jego reguły nie są prawnym zezwoleniem na dostęp. Selenium i Playwright nie mają wbudowanej zgodności z robots.txt — to w całości spoczywa na tobie. Niezależnie od narzędzia, przed scrapowaniem i ponownym wykorzystaniem danych sprawdź regulamin serwisu oraz obowiązujące przepisy w swojej jurysdykcji; samo „to jest publicznie widoczne” nie oznacza automatycznie zielonego światła prawnego wszędzie.
Jak wybrać właściwe narzędzie do projektu scrapingu w 2026
Decyzja sprowadza się do czterech pytań: jaki jest typ treści, jaka jest skala, ile interakcji potrzebujesz i ile bieżącego utrzymania jesteś gotów zaakceptować. Strony statyczne w realnej skali — Scrapy. Strony z dużą ilością JS i faktyczną interakcją — Selenium lub Playwright. Mieszanka jednego i drugiego — hybryda. Znane URL-e, gdzie potrzebujesz tylko danych strukturalnych i minimum utrzymania — API takie jak Thunderbit często oszczędza więcej czasu, niż kosztuje.
„Scrapy vs. Selenium” nigdy nie było pełnym pytaniem — po prostu przez długi czas było jedyną dostępną ramą porównania. Playwright zmienił środek stawki, a AI API do ekstrakcji stworzyły zupełnie nową ścieżkę dla osób, które zorientowały się, że budują infrastrukturę zamiast rozwiązywać problem biznesowy. Warto sprawdzić darmowy plan, zanim wybierzesz jedną z dróg — suggest-fields jest darmowe, a Distill zużywa jeden kredyt, więc możesz szybko zweryfikować, czy podejście API pasuje, zanim napiszesz choćby jedną linijkę kodu spidera.
FAQ
Czy Scrapy jest szybszy od Selenium w scrapingu?
Z mojego doświadczenia: tak — często nawet wielokrotnie na stronach statycznych, bo asynchroniczna architektura Scrapy omija narzut przeglądarki. Ta różnica maleje, gdy Scrapy korzysta z middleware Playwright do stron intensywnie używających JS, ale Scrapy nadal zwykle wygrywa pod względem ogólnej przepustowości przy mieszanych obciążeniach, bo strony bez JS idą szybką ścieżką.
Czy Scrapy obsługuje strony renderowane przez JavaScript?
Nie sam z siebie — Scrapy widzi tylko początkową odpowiedź HTML. Dodanie scrapy-playwright albo starszego Scrapy-Splash jako middleware pozwala selektywnie renderować konkretne żądania przez prawdziwą przeglądarkę, pozostawiając resztę crawl’a na natywnej, szybszej ścieżce Scrapy.
Kiedy użyć Selenium zamiast Scrapy?
Gdy potrzebujesz pełnej interakcji z przeglądarką — wieloetapowego logowania, przechodzenia przez kreatory, wypełniania formularzy — a liczba stron jest umiarkowana, a nie ogromna. To też rozsądny wybór, jeśli masz już infrastrukturę testową opartą na Selenium, którą chcesz wykorzystać do scrapingu.
Czy Playwright jest lepszy od Selenium do scrapingu w 2026?
Dla samego scrapingu — zwykle tak. Playwright zazwyczaj daje lepszą wydajność, automatyczne czekanie wbudowane w narzędzie i mniejsze zużycie zasobów na jeden kontekst przeglądarki. Selenium nadal ma przewagę w zespołach, które utrzymują dojrzałe zestawy testów cross-browser, których Playwright nie miał zastępować.
Czym jest AI scraping API i kiedy zastępuje Scrapy lub Selenium?
AI scraping API, takie jak Open API Thunderbit, obsługuje po stronie serwera renderowanie JS, zabezpieczenia anty-bot i ekstrakcję danych, zwracając ustrukturyzowany JSON zgodny z definiowanym przez ciebie schematem. To właściwy wybór, gdy masz znane URL-e i potrzebujesz strukturalnego wyniku bez budowania ani utrzymywania infrastruktury do crawl’owania — nie jest to zamiennik Scrapy przy złożonych, rekurencyjnych crawl’ach z własną logiką.
Dowiedz się więcej
