Cenniki web scrapingu: za GB, za stronę czy za request?

Nikt nie sprzedaje web scrapingu w tej samej jednostce

Bright Data wycenia swój Web Unlocker za tysiąc requests. Oxylabs wycenia Web Unblocker za gigabajt. Firecrawl pobiera jeden kredyt za stronę. Zyte nalicza opłaty za tysiąc udanych responses, podzielonych na pięć poziomów trudności. Apify rozlicza jednostki obliczeniowe (compute unit), czyli jeden gigabajt pamięci RAM przydzielony na godzinę.

Pięciu dostawców, pięć jednostek. Żadnej z nich nie da się przeliczyć na inną bez wartości, którą musisz zmierzyć samodzielnie. Żaden z dostawców jej nie publikuje, ponieważ zależy ona od Twojego ruchu, a nie od ich produktu.

Przeanalizowaliśmy cenniki wszystkich pięciu dostawców z 8 września 2026 r. Oto co zawierają i jak wygląda ich bezpośrednie przeliczenie.

Szybkie porównanie

W tej tabeli rzucają się w oczy dwie kwestie.

Sam cennik Zyte obejmuje rozpiętość 124x. Ten sam dostawca, ta sama jednostka, ta sama pozycja na fakturze: prosta strona pobierana przez HTTP kosztuje $0.13 za tysiąc, a zaawansowana strona renderowana w przeglądarce to $16.08. Każdy, kto podaje stawkę "za tysiąc requests" jako wartość porównawczą, wybiera jeden ze skrajnych punktów tak szerokiego przedziału.

Z kolei Bright Data zmienia jednostki wewnątrz własnej oferty. Web Unlocker jest sprzedawany za request. Browser API jest sprzedawany za gigabajt. To nie jest niedopatrzenie. To wyraźny sygnał, a w dalszej części tego wpisu wyjaśniamy, co dokładnie z niego wynika.

Ile faktycznie daje jeden gigabajt

Wartością decydującą o każdym przeliczeniu jest średnia waga strony, a publiczne dane na ten temat są bezlitosne.

Raport Web Almanac 2025 serwisu HTTP Archive wskazuje, że mediana wagi mobilnej strony głównej w crawl z lipca 2025 r. wynosiła 2559 KB, co oznacza wzrost o 8.4% w ciągu roku. Rozbicie tej mediany na typy zasobów daje 911 KB obrazów, 632 KB JavaScriptu, 122 KB fontów oraz 77 KB CSS.

Oraz 22 KB HTML.

Ta ostatnia liczba jest kluczowa, ponieważ dokument HTML jest zazwyczaj jedyną częścią, którą faktycznie parsujesz. Na przeciętnej stronie stanowi on 0.86% bajtów pobieranych podczas pełnego renderowania w przeglądarce. Pozostałe 99% to zbędny balast, za którego transfer płacisz.

Przeliczmy to na przykładzie planu Oxylabs 8 GB w cenie $9.40/GB:

• Pobieranie samego HTML przy 22 KB na stronę: jeden gigabajt to około 45 000 stron. Daje to około 0,21 USD za 1 000 stron.
• Renderowanie całej strony przy 2 559 KB: jeden gigabajt to około 390 stron. Daje to około 24 USD za 1 000 stron.

Ten sam plan. Ta sama cena w cenniku. Różnica rzędu 116x, wynikająca wyłącznie z jednego ustawienia w Twoim własnym kodzie.

Teraz porównaj to z Firecrawl. Przy cenie 83 USD za 100 000 kredytów w rozliczeniu rocznym i zużyciu jednego kredytu na stronę, płacisz 0,83 USD za 1 000 stron, niezależnie od tego, czy strona waży 20 KB, czy 4 MB. W porównaniu z pobieraniem samego HTML rozliczenie za gigabajty jest około cztery razy tańsze. W porównaniu z pełnym renderowaniem jest około 29 razy droższe.

Punkt przecięcia wypada w okolicach 100 kilobajtów

Prosta kalkulacja pokazuje, że oba modele spotykają się przy konkretnym rozmiarze strony. Stawka Firecrawl wynosząca 0,00083 USD za stronę podzielona przez 9,40 USD za gigabajt w Oxylabs daje 88 KB. Jeśli wybierzesz Firecrawl w rozliczeniu miesięcznym zamiast rocznego (99,50 USD za te same 100 000 kredytów), punkt przecięcia przesuwa się do 106 KB. Poniżej tego przedziału wygrywa rozliczenie za gigabajty. Powyżej wygrywa stała stawka za stronę, a różnica rośnie bardzo szybko, ponieważ waga stron nie ma górnego limitu.

Oto ciekawy szczegół. Oxylabs podaje własny przelicznik, choć nie nazywa go wprost: darmowy okres próbny Web Unblocker jest opisany jako "1GB (up to 10k results)". Oznacza to 100 KB na wynik, co idealnie mieści się w wyliczonym przez nas przedziale bazującym na cennikach dwóch innych dostawców. Ich własna kalkulacja zakłada, że pobierasz dokumenty, a nie renderujesz galerie multimedialne.

Jeśli więc rozliczasz się za bajty i sterujesz przeglądarką, największą dźwignią nie jest wybór dostawcy. Jest nią blokowanie obrazów i fontów przed załadowaniem strony, ponieważ na medianowej stronie stanowią one 1 033 z 2 559 KB. Wolimy powiedzieć to wprost, zamiast udawać, że o wysokości faktury decyduje logo wybranego dostawcy.

Dwa istotne zastrzeżenia. Są to wartości medianowe dla całego internetu, a Twoje cele to nie cały internet (strony e-commerce i turystyczne ważą znacznie więcej, a endpointy JSON znacznie mniej). Ponadto renderowana strona z zablokowanymi multimediami może ważyć dużo poniżej mediany, co przesuwa punkt opłacalności na Twoją korzyść bez jakichkolwiek zmian w cenniku dostawcy. Ta sama logika decyduje o tym, kiedy etap ekstrakcji przez LLM przestaje na siebie zarabiać: cena jednostkowa nigdy nie jest najistotniejszą liczbą, liczy się koszt każdego zachowanego rekordu.

Kryterium naliczania opłat to druga oś

Jednostka rozliczeniowa to jedno. To, co faktycznie uruchamia licznik, to zupełnie inna kwestia, którą łatwo przeoczyć.

Bright Data promuje model "pay only for success" w usłudze Web Unlocker. Zyte wycenia ruch "za 1 000 udanych odpowiedzi". Firecrawl pobiera kredyt za każde żądanie API, w zależności od endpointu. W rozliczeniu za gigabajty warunek sukcesu w ogóle nie istnieje: dane zostały przesłane, więc płacisz, a strona z weryfikacją CAPTCHA, którą natychmiast odrzucasz, jest stroną, za którą i tak zapłacono.

To ma większe znaczenie, niż się wydaje, ponieważ challenge lub strona pośrednia (interstitial) zazwyczaj zwracają kod HTTP 200. Jeśli Twoja definicja sukcesu opiera się na kodzie statusu, logika ponawiania prób (retry) i Twoja faktura będą rozmijać się z Twoim zbiorem danych. Pisaliśmy o tym rozłamie w artykule Validate Rules Now Decide What Counts as Success. To dokładnie ta sama linia podziału, która zamienia częściową blokadę w cichą lukę w szeregu czasowym.

Kto powinien wybrać którą jednostkę rozliczeniową

Płać za gigabajt, jeśli pobierasz dokumenty zamiast je renderować, a Twoimi celami jest tekst: wyniki wyszukiwania, endpointy JSON, strony z listingami czy mapy witryn. Przy 20 do 50 KB na stronę rozliczenie za bajty jest najtańszą opcją na rynku i nic innego się do niej nie zbliża.

Płać za stronę lub za request, jeśli renderujesz strony, jeśli Twoje cele zawierają dużo multimediów lub po prostu nie potrafisz przewidzieć wagi stron w długim ogonie witryn. Płacisz marżę przy małych stronach, aby zyskać górny limit kosztów przy dużych, a przy obciążeniach opartych na renderowaniu ten limit jest wart bardzo wiele.

Płać za poziom (tier), tak jak oferuje to Zyte, jeśli Twój zestaw celów jest stabilny i wiesz, do którego poziomu trafia każda witryna. Ten model otwarcie uwzględnia to, co wszyscy inni uśredniają: trudne witryny generują wyższe koszty pobierania. To zły wybór, jeśli Twoja lista celów zmienia się co tydzień.

Płać za jednostki obliczeniowe (compute units), jeśli uruchamiasz długie procesy crawlowania z własnym kodem na platformie. Ten licznik rozlicza maszynę, a nie dane, dzięki czemu nagradza szybki parser i karze powolny. To jedyny model na tej liście, w którym optymalizacja Twojego kodu przekłada się bezpośrednio na fakturę.

Żadna z tych jednostek nie jest pułapką. Każda z nich to zakład o to, jak wygląda typowy ruch, postawiony przez dostawcę znającego swoją bazę klientów. Błędem nie jest wybór złej jednostki. Błędem jest porównywanie dwóch ofert, które nigdy nie były wyrażone w tej samej jednostce, i traktowanie niższej liczby jako podstawy do decyzji.

Cena rośnie, nawet jeśli nikt jej nie podnosi

Zanim zaakceptujesz wycenę od kogokolwiek, łącznie z nami, zmierz dwie wartości na podstawie tygodnia własnego ruchu: liczbę bajtów na pobranie oraz odsetek pobrań, które zwróciły dane faktycznie przez Ciebie zachowane. Każdą ofertę w tym artykule da się łatwo przeliczyć, gdy masz te dwie liczby, i żadnej nie da się przeliczyć bez nich.

Następnie obserwuj, co wydarzy się w kolejnym roku. Mediana wagi strony głównej wzrosła o 7,8% w ciągu dwunastu miesięcy, a presja idzie tylko w jednym kierunku. Jeśli Twój rachunek jest rozliczany w bajtach, oznacza to coroczną podwyżkę cen, której nikt nie musi ogłaszać, na pozycji kosztowej, której nikt nie negocjował.

W FourA zwracamy koszt każdego wywołania bezpośrednio w odpowiedzi, więc przeliczenie odczytujesz na bieżąco, zamiast rekonstruować je z faktury na koniec miesiąca. To nie wskaże Ci wprost, którą jednostkę kupić. Pokaże Ci jednak, ile faktycznie wydajesz na każdą zachowaną stronę, a to jest liczba, wokół której toczy się cała ta dyskusja.