Hoe proxybandbreedtekosten te verlagen: Verminder uw GB-rekening met 60-90%
Bij proxies die per GB worden betaald, is uw rekening gebaseerd op bytes, niet op verzoeken — en de meeste van die bytes zijn afbeeldingen en lettertypen die u nooit verwerkt. Hier leest u hoe u ze kunt verwijderen en een residentiële GB-rekening met meer dan de helft kunt verlagen.
Bij proxies die per GB worden betaald, is uw rekening gebaseerd op bytes, niet op verzoeken — en de ongemakkelijke waarheid is dat de meeste van die bytes afbeeldingen, lettertypen en stylesheets zijn die u nooit verwerkt. Een enkele productfoto in volledige resolutie kan 2,2 MB zijn; een volledige browserweergave van één pagina bedraagt 2-5 MB. De slanke HTML waaruit u daadwerkelijk extraheert, is vaak minder dan 150 KB. Verwijder de rest en een residentiële GB-rekening daalt met 60-90%. Deze gids is het praktische handboek: blokkeer middelen, sla ongewijzigde pagina's over, comprimeer en richt op JSON in plaats van HTML.
Weet eerst waarvoor u wordt gefactureerd
Residentiële bandbreedte wordt gemeten op basis van de som van de gegevens die in beide richtingen worden verzonden: aanvraagheaders plus aanvraaglichaam en antwoordheaders plus antwoordlichaam. Dat betekent dat elke bron die een pagina ophaalt — elke afbeelding, lettertype en volgscript — op uw factuur terechtkomt, ook al voedt geen van deze uw parser. Het optimalisatiedoel is eenvoudig: download alleen de bytes waaruit u extraheert. Alles wat overblijft is verspilling waarvoor u betaalt.
Blokkeer middelen in een headless browser
Als u een browser aanstuurt, is dit de grootste hefboom. Playwright en Puppeteer laten u beide verzoeken onderscheppen en de brontypen die u niet nodig heeft, afbreken. Het blokkeren van afbeeldingen, media, lettertypen en stylesheets vermindert het paginagewicht doorgaans aanzienlijk — de DOM wordt nog steeds opgebouwd, zodat uw selectors en eventuele hydratatie-JSON behouden blijven:
// 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' });Twee waarschuwingen: blokkeer niet de XHR/fetch-aanroepen die de gegevens bevatten waarnaar u op zoek bent, en test of de pagina nog steeds weergeeft wat u nodig heeft — overmatig blokkeren kan de eigen logica van een site breken. Als u een browser afweegt tegen gewone verzoeken, toont onze analyse van de kosten van rendering versus HTTP-verzoeken de 10-50x kloof die deze beslissing belangrijk maakt.
Sla pagina's over die niet zijn gewijzigd
De goedkoopste byte is degene die u niet downloadt. Twee technieken verminderen verspilling door opnieuw ophalen bij monitoringtaken. Een HEAD-verzoek haalt alleen headers op om Content-Length of Last-Modified te controleren voordat u zich aan de volledige GET verbindt. Beter nog, een voorwaardelijke GET stuurt de ETag of tijdstempel van de vorige keer en de server antwoordt met 304 Not Modified met een lege body wanneer er niets is veranderd — u betaalt voor een paar headerbytes in plaats van de hele pagina:
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")Voor een scraper die dagelijks dezelfde pagina's opnieuw controleert, kunnen voorwaardelijke GETs alleen al de bandbreedte aanzienlijk verminderen, omdat de meeste pagina's niet veranderen tussen runs.
Accepteer altijd compressie
Tekst comprimeert goed — HTML, JSON en CSS krimpen 70-90% met gzip of brotli — en u wordt gefactureerd op de gecomprimeerde grootte die daadwerkelijk de lijn overgaat. Stuur een Accept-Encoding header en laat de server comprimeren. In Python's requests is dit standaard ingeschakeld wanneer u het niet tegenwerkt; in een ruwe client, vraag er expliciet om:
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 sizeRicht op JSON, niet HTML
De grootste structurele winst is het volledig overslaan van de gerenderde pagina. Veel sites hydrateren vanaf een JSON-endpoint dat dezelfde gegevens bevat in een fractie van de bytes — de prijs en voorraad van een product als een 10 KB API-reactie in plaats van een 3 MB gerenderde pagina. Zoek de XHR-aanroep in het Netwerk-tabblad van uw browser en richt direct daarop. Shopify-winkels zijn het klassieke voorbeeld: het products.json endpoint geeft u de hele catalogus zonder enige HTML. Wanneer u de API kunt lezen, doe dat dan — het is het verschil tussen kilobytes en megabytes per record.
Laat de API de bytes voor u tellen
Als u liever geen blokkeringsregels per site handmatig afstemt, doet een Scraper API die alleen rendert wanneer nodig en geparseerde markdown of JSON retourneert, het middelenstrippen voor u — u ontvangt de geëxtraheerde inhoud, niet de megabytes waaruit deze afkomstig is. En bij residentiële proxies die per GB worden betaald zijn de besparingen direct: minder bytes over de lijn betekent minder dollars op de factuur, zonder dat er iets verloren gaat van de gegevens die u behoudt. Voor het volledige beeld van wat een gigabyte daadwerkelijk oplevert, zie onze analyse van per-GB prijzen.
Scrape efficiënter op residentiële proxies die per GB worden betaald
Veelgestelde vragen
Hoe wordt proxybandbreedte berekend?
Door het totale aantal bytes dat in beide richtingen wordt verzonden: aanvraagheaders plus aanvraaglichaam en antwoordheaders plus antwoordlichaam. Dus elke afbeelding, lettertype en script die een pagina laadt, telt mee voor uw gebruik, niet alleen de HTML die u verwerkt. Daarom vertaalt het blokkeren van ongebruikte middelen en het overslaan van ongewijzigde pagina's zich direct in een lagere rekening bij plannen die per GB worden betaald.
Breekt het blokkeren van afbeeldingen scraping?
Niet als u voorzichtig bent. Het blokkeren van afbeeldingen, media, lettertypen en stylesheets laat de DOM en JavaScript intact, zodat uw selectors en eventuele hydratatie-JSON nog steeds werken — u slaat alleen de visuele lading over. Het risico is overmatig blokkeren: stop nooit de XHR/fetch-aanroepen die uw gegevens bevatten, en test of de pagina nog steeds produceert wat u nodig heeft voordat u op grote schaal gaat draaien.
Wat is de grootste enkele bandbreedtebesparing?
Richten op een JSON-endpoint in plaats van de volledige pagina te renderen, waar dat mogelijk is. Een 10 KB API-reactie kan een 3 MB weergave vervangen voor hetzelfde record — een besparing van 99%. Daarna zijn het blokkeren van middelen in een headless browser en het gebruik van voorwaardelijke GETs bij herhaalde crawls de grootste winsten. Compressie is bijna gratis en moet altijd ingeschakeld zijn.
Hoeveel kan ik realistisch gezien besparen?
Het blokkeren van middelen vermindert doorgaans het gewicht van een gerenderde pagina met ruim meer dan de helft; voorwaardelijke GETs kunnen de hercrawl-bandbreedte tot bijna nul reduceren voor pagina's die niet veranderen; en overschakelen van HTML naar een JSON-route is vaak een reductie van meer dan 90% per record. Samen opgeteld is een verlaging van 60-90% van een residentiële GB-rekening een realistisch doel voor de meeste projecten.
Niets hiervan verandert wat u extraheert — het verandert wat u betaalt om het te extraheren. Blokkeer de middelen die u nooit leest, sla de pagina's over die niet zijn gewijzigd, accepteer compressie en geef de voorkeur aan JSON-routes boven volledige weergaven. Bij proxies die per GB worden betaald, verlagen deze vier gewoonten routinematig een rekening met meer dan de helft. Voor de architectuur die dit over miljoenen pagina's schaalt, zie onze gids over grootschalige scraping-architectuur.