# 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ą:

```js
// 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](https://quantumproxies.io/blog/headless-browser-vs-http-requests-cost) pokazuje różnicę 10-50x, która sprawia, że ta decyzja ma znaczenie.

![Strona produktu taka, jak rozlicza ją proxy: zdjęcie w pełnej rozdzielczości o wadze 2,2 MB oraz otaczające je czcionki, arkusze stylów i skrypty, w zestawieniu z lekkim HTML, który faktycznie parsujesz, często poniżej 150 KB. Karta wymienia wagi: 2-5 MB na pełne renderowanie w przeglądarce i rachunek mniejszy o 60-90% po zablokowaniu zasobów.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785335198/blog/generated/qp-b9-068-diag1.png)
*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:

```python
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:

```python
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](https://quantumproxies.io/blog/shopify-products-json-scraping) 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](https://quantumproxies.io/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](https://quantumproxies.io/residential-proxies) 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](https://quantumproxies.io/blog/residential-proxy-pricing-per-gb-explained).

![Handler route w Playwright, który przerywa każde żądanie obrazu, multimediów, czcionki i arkusza stylów, a resztę przepuszcza dalej. Karta dzieli zasoby: blokuj obrazy, multimedia, czcionki i CSS, za które płacisz, a których nie używasz; zachowaj HTML, JSON oraz wywołania XHR lub fetch, które niosą dane, i sprawdź, czy strona nadal je renderuje.](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785335199/blog/generated/qp-b9-068-diag2.png)
*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](https://quantumproxies.io/residential-proxies)

## 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ę](https://quantumproxies.io/blog/large-scale-web-scraping-architecture).

[Uzyskaj przetworzoną treść bez zbędnych bajtów](https://quantumproxies.io/scraper-api)