Jak obniżyć koszty przepustowości proxy: zmniejsz rachunek za GB o 60-90%

W przypadku proxy płatnych za GB, płacisz za bajty, nie za żądania — a większość tych bajtów to obrazy i czcionki, których nigdy nie analizujesz. Oto jak je usunąć i obniżyć rachunek za GB rezydencjalne o ponad połowę.

W przypadku proxy płatnych za GB, płacisz za bajty, nie za żądania — a niewygodna prawda jest taka, że większość tych bajtów to obrazy, czcionki i arkusze stylów, których nigdy nie analizujesz. Pojedyncze zdjęcie produktu w pełnej rozdzielczości może mieć 2,2 MB; pełne renderowanie przeglądarki jednej strony to 2-5 MB. Chudy HTML, z którego faktycznie korzystasz, często ma poniżej 150 KB. Usuń resztę, a rachunek za GB rezydencjalne spadnie o 60-90%. Ten przewodnik to praktyczny plan działania: blokuj zasoby, pomijaj niezmienione strony, kompresuj i kieruj do JSON zamiast HTML.

Najpierw dowiedz się, za co płacisz

Przepustowość rezydencjalna jest mierzona sumą danych przesyłanych w obu kierunkach: nagłówki żądań plus treść żądań oraz nagłówki odpowiedzi plus treść odpowiedzi. Oznacza to, że każdy zasób, który strona pobiera — każdy obraz, czcionka i skrypt śledzący — trafia na twoją fakturę, mimo że żaden z nich nie zasila twojego parsera. Cel optymalizacji jest prosty: pobieraj tylko bajty, które analizujesz. Wszystko inne to marnotrawstwo, za które płacisz.

Blokuj zasoby w przeglądarce bez interfejsu

Jeśli korzystasz z przeglądarki, to jest to największa dźwignia. Playwright i Puppeteer pozwalają przechwytywać żądania i przerywać zasoby, których nie potrzebujesz. Blokowanie obrazów, mediów, czcionek i arkuszy stylów zazwyczaj zmniejsza wagę strony o większość — DOM nadal się buduje, więc twoje selektory i wszelkie JSON do hydratacji przetrwają:

// Playwright: abort the resource types you never parse
await page.route('**/*', (route) => {
  const type = route.request().resourceType();
  if (['image', 'media', 'font', 'stylesheet'].includes(type)) {
    return route.abort();
  }
  return route.continue();
});
await page.goto(url, { waitUntil: 'domcontentloaded' });

Dwa ostrzeżenia: nie blokuj wywołań XHR/fetch, które przenoszą dane, których szukasz, i przetestuj, czy strona nadal renderuje to, czego potrzebujesz — nadmierne blokowanie może złamać logikę samej strony. Jeśli w ogóle rozważasz przeglądarkę w porównaniu do zwykłych żądań, nasza analiza kosztów renderowania vs żądań HTTP pokazuje różnicę 10-50x, która sprawia, że ta decyzja ma znaczenie.

Statystyki przepustowości dla web scrapingu: obraz 2,2 MB, 2-5 MB na pełne renderowanie, 150 KB chudy HTML i obniżka rachunku o 60-90% — Płacisz za całą stronę, ale analizujesz tylko jej fragment — blokowanie zasobów to najtańsze duże zwycięstwo, jakie można osiągnąć.

Pomijaj strony, które się nie zmieniły

Najtańszy bajt to ten, którego nie pobierasz. Dwie techniki zmniejszają marnotrawstwo ponownego pobierania w zadaniach monitorujących. Żądanie HEAD pobiera tylko nagłówki, aby sprawdzić Content-Length lub Last-Modified przed pełnym GET. Lepsze, żądanie GET warunkowe wysyła ETag lub znacznik czasu z ostatniego razu, a serwer odpowiada 304 Not Modified z pustym ciałem, gdy nic się nie zmieniło — płacisz za kilka bajtów nagłówków zamiast całej strony:

import requests

# conditional GET: 304 = near-zero bytes when unchanged
headers = {"If-None-Match": last_etag,
           "If-Modified-Since": last_seen}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)

if r.status_code == 304:
    pass  # unchanged, no body downloaded, no GB spent
else:
    process(r.content)
    last_etag = r.headers.get("ETag")

Dla scrapera, który codziennie ponownie sprawdza te same strony, same GET warunkowe mogą znacznie zmniejszyć przepustowość, ponieważ większość stron nie zmienia się między uruchomieniami.

Zawsze akceptuj kompresję

Tekst dobrze się kompresuje — HTML, JSON i CSS zmniejszają się o 70-90% z gzip lub brotli — a płacisz za skompresowany rozmiar, który faktycznie przechodzi przez sieć. Wyślij nagłówek Accept-Encoding i pozwól serwerowi kompresować. W Pythonie requests jest to domyślnie włączone, gdy tego nie zmieniasz; w surowym kliencie, poproś o to wyraźnie:

headers = {"Accept-Encoding": "gzip, deflate, br"}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
# requests transparently decompresses; you're billed on the small size

Kieruj do JSON, nie HTML

Największym strukturalnym zwycięstwem jest pominięcie renderowanej strony całkowicie. Wiele stron hydratyzuje się z punktu końcowego JSON, który przenosi te same dane w ułamku bajtów — cena i stan magazynowy produktu jako odpowiedź API 10 KB zamiast renderowanej strony 3 MB. Znajdź wywołanie XHR w zakładce Sieć przeglądarki i uderzaj bezpośrednio w nie. Sklepy Shopify to klasyczny przykład: punkt końcowy products.json przekazuje ci cały katalog bez żadnego HTML. Gdy możesz czytać API, rób to — to różnica między kilobajtami a megabajtami na rekord.

Pozwól API liczyć bajty za ciebie

Jeśli wolisz nie dostrajać reguł blokowania dla każdej strony, Scraper API, które renderuje tylko wtedy, gdy jest to potrzebne i zwraca przetworzony markdown lub JSON, wykonuje za ciebie usuwanie zasobów — otrzymujesz wyodrębnioną treść, a nie megabajty, z których pochodziła. A na proxy rezydencjalnych płatnych za GB oszczędności są bezpośrednie: mniej bajtów w sieci to mniej dolarów na fakturze, bez utraty danych, które zachowujesz. Dla pełnego obrazu tego, co faktycznie kupuje gigabajt, zobacz naszą analizę ceny za GB.

Lista zasobów do zablokowania podczas scrapingu (obrazy, CSS, czcionki, media, reklamy) w porównaniu do zasobów do zachowania (HTML, JSON, dane XHR) — Blokuj zasoby, za które płacisz, ale nie używasz; zachowaj HTML, JSON i punkty końcowe XHR, które przenoszą twoje rzeczywiste dane.

Scrapuj oszczędniej na proxy rezydencjalnych płatnych za GB

Najczęściej zadawane pytania

Jak obliczana jest przepustowość proxy?

Na podstawie całkowitej liczby bajtów przesyłanych w obu kierunkach: nagłówki żądań plus treść żądań oraz nagłówki odpowiedzi plus treść odpowiedzi. Tak więc każdy obraz, czcionka i skrypt, które strona ładuje, liczą się do twojego zużycia, nie tylko HTML, który analizujesz. Dlatego blokowanie nieużywanych zasobów i pomijanie niezmienionych stron przekłada się bezpośrednio na niższy rachunek w planach płatnych za GB.

Czy blokowanie obrazów psuje scraping?

Nie, jeśli jesteś ostrożny. Blokowanie obrazów, mediów, czcionek i arkuszy stylów pozostawia DOM i JavaScript nienaruszone, więc twoje selektory i wszelkie JSON do hydratacji nadal działają — pomijasz tylko wizualny ładunek. Ryzyko to nadmierne blokowanie: nigdy nie przerywaj wywołań XHR/fetch, które przenoszą twoje dane, i przetestuj, czy strona nadal produkuje to, czego potrzebujesz, zanim uruchomisz to na dużą skalę.

Jaka jest największa oszczędność przepustowości?

Kierowanie do punktu końcowego JSON zamiast renderowania pełnej strony, gdzie to możliwe. Odpowiedź API 10 KB może zastąpić render 3 MB dla tego samego rekordu — 99% oszczędności. Po tym, blokowanie zasobów w przeglądarce bez interfejsu i używanie GET warunkowych przy ponownym przeszukiwaniu to największe zwycięstwa. Kompresja jest prawie darmowa i zawsze powinna być włączona.

Ile mogę realistycznie zaoszczędzić?

Blokowanie zasobów zazwyczaj zmniejsza wagę renderowanej strony o dobrze ponad połowę; GET warunkowe mogą zmniejszyć przepustowość ponownego przeszukiwania do niemal zera dla stron, które się nie zmieniają; a przejście z HTML na trasę JSON to często redukcja o ponad 90% na rekord. Zestawione razem, obniżka rachunku za GB rezydencjalne o 60-90% jest realistycznym celem dla większości projektów.

Żadne z tego nie zmienia tego, co wyciągasz — zmienia to, ile płacisz za wyciągnięcie tego. Blokuj zasoby, których nigdy nie czytasz, pomijaj strony, które się nie zmieniły, akceptuj kompresję i preferuj trasy JSON nad pełnymi renderami. Na proxy płatnych za GB te cztery nawyki rutynowo obniżają rachunek o ponad połowę. Dla architektury, która skaluje to na miliony stron, zobacz nasz przewodnik o architekturze scrapingu na dużą skalę.

Uzyskaj przetworzoną treść bez zbędnych bajtów