Cómo recortar los costes de ancho de banda de proxy al scrapear a escala

Los proxies residenciales se facturan por gigabyte, así que en un plan por GB tu ancho de banda es tu factura. La trampa es que un scraper ingenuo desperdicia la mayoría de los bytes que paga, descargando imágenes, fuentes, vídeos, y scripts de tracking que nunca mira, re-descargando páginas que no han cambiado, y renderizando navegadores completos cuando una simple petición HTTP bastaría. La buena noticia: casi todo ese desperdicio es fácil de recortar, y un scraper bien afinado rutinariamente usa menos de la mitad del ancho de banda de uno sin afinar para los mismos datos.

Esta es una guía práctica para hacer exactamente eso. Nueve tácticas, ordenadas aproximadamente por impacto, para recolectar los mismos datos a través de tus proxies residenciales mientras pagas por una fracción de los bytes. Es la compañera de eficiencia de costes del cambio a por-GB cubierto en proxies residenciales facturados por ancho de banda.

1. No renderices un navegador a menos que tengas que hacerlo

Esta es la palanca individual más grande. Un navegador headless descarga todo lo que la página referencia: imágenes, CSS, fuentes web, vídeo, analítica, scripts de anuncios. Para la mayoría del scraping, no necesitas nada de eso. Si los datos que quieres están en el HTML inicial o son alcanzables vía una API (siguiente sección), sáltate el navegador por completo y usa un cliente HTTP simple, requests, httpx, o Scrapy. Un único GET HTTP puede ser una fracción minúscula de los bytes que un render de navegador completo trae.

Reserva el navegador para páginas que genuinamente requieren ejecución de JavaScript para producir los datos. En la duda, obtén primero el HTML crudo y comprueba si tus valores objetivo ya están ahí.

2. Golpea la API JSON, no el HTML

Muchos sitios renderizan su contenido desde un endpoint JSON de backend que la página llama tras cargar. Obtener ese endpoint directamente, en lugar de la página HTML completa y sus assets, es a menudo una fracción de los bytes y te da datos limpios y estructurados sin parseo. Abre la pestaña de red de tu navegador, encuentra la petición que devuelve los datos (normalmente un XHR/fetch que devuelve JSON), y llámala directamente a través del proxy. Una respuesta JSON esbelta puede reemplazar una página pesada más un render de navegador.

3. Bloquea los tipos de recurso pesados cuando debas usar un navegador

Cuando una página realmente necesita renderizado, no dejes que el navegador descargue lo que no vas a usar. Tanto Playwright como Puppeteer te dejan interceptar peticiones y abortar imágenes, media, fuentes, y a menudo hojas de estilo antes de que lleguen al proxy, lo cual típicamente recorta el ancho de banda en bastante más de la mitad. En Playwright:

await context.route("**/*", (route) => {
  const type = route.request().resourceType();
  if (["image", "media", "font"].includes(type)) {
    return route.abort();          // nunca descargado, nunca facturado
  }
  return route.continue();
});

Mantén document, script, xhr, y fetch; descarta el resto. El mismo patrón y las particularidades de Chromium están en cómo usar proxies residenciales con Playwright.

4. Mantén la compresión activada

El texto comprime aproximadamente de 5 a 10x, así que una respuesta HTML codificada con gzip o brotli es una fracción del tamaño crudo. La mayoría de los clientes HTTP envían Accept-Encoding: gzip, deflate, br y descomprimen de forma transparente por defecto, pero verifica que no lo hayas deshabilitado, y nunca quites el header. Si estás poniendo headers manualmente, inclúyelo:

headers = {"Accept-Encoding": "gzip, br", "User-Agent": "..."}

Los bytes que cruzan el proxy son los comprimidos, así que esto es una reducción directa y gratuita de lo que se te factura.

5. Usa peticiones condicionales para que las páginas sin cambios cuesten casi nada

Para cualquier crawl recurrente, no re-descargues páginas a ciegas. Las peticiones condicionales HTTP dejan que el servidor te diga “nada cambió” en una respuesta 304 minúscula en lugar de reenviar el cuerpo entero. Guarda el ETag o Last-Modified de cada fetch y envíalo de vuelta:

# En el re-fetch, envía el validador guardado
headers = {"If-None-Match": stored_etag}      # o If-Modified-Since
r = client.get(url, headers=headers)
if r.status_code == 304:
    pass   # sin cambios: unos pocos bytes en lugar de la página completa

Un 304 cuesta casi nada comparado con una página completa, y en un trabajo de monitorización donde la mayoría de las páginas rara vez cambian, esto por sí solo puede recortar el ancho de banda drásticamente.

6. No re-descargues lo que no ha cambiado

Relacionado, pero más amplio que los validadores HTTP: rastrea lo que ya has recolectado y sáltalo. Usa las marcas de tiempo lastmod del sitemap para encontrar URLs cambiadas, mantén un hash de contenido por página y sáltate re-procesar contenido idéntico, y deduplica tu frontera de crawl para no obtener la misma URL dos veces en una corrida. El gigabyte más barato es el que nunca descargas.

7. Obtén solo los bytes que necesitas

Si solo necesitas los headers de un archivo o su primer trozo (una comprobación de metadatos, un sniff de content-type), no descargues la cosa entera. Una petición HEAD devuelve headers sin cuerpo, y una petición Range trae solo los bytes que especifiques donde el servidor lo soporte:

client.head(url)                                   # solo headers, sin cuerpo
client.get(url, headers={"Range": "bytes=0-2047"}) # solo los primeros 2 KB

Esto importa más cuando tu crawl toca media grande, PDFs, o descargas donde solo necesitas una parte pequeña o solo metadatos.

8. Haz los reintentos y el geo-targeting eficientes

Cada intento fallido aún gasta ancho de banda, así que los reintentos derrochadores inflan tu factura en silencio. Aplica backoff y limita los reintentos en lugar de martillar una URL que falla, y evita filtros geo demasiado ajustados (país + ciudad + ASN todos a la vez) que causan que las peticiones fallen y reintenten cuando no hay una IP coincidente libre, afloja un filtro en su lugar. Pon timeouts sensatos para que una respuesta estancada no arrastre, y haz coincidir tu estrategia de sesión con el trabajo para no re-establecer flujos innecesariamente. Las peticiones eficientes son peticiones baratas.

9. Mide los bytes por registro

No puedes recortar lo que no mides. Rastrea el ancho de banda por trabajo y, mejor, los bytes por registro exitoso extraído, y el desperdicio se revela solo: una página que cuesta megabytes por fila normalmente está trayendo assets que podrías bloquear o renderizando cuando podrías haber golpeado una API. Regístralo, observa la tendencia, y optimiza primero a los peores infractores.

Una nota sobre hacerlo de forma responsable

Recortar el ancho de banda no es solo más barato para ti, es más ligero para los sitios de los que recolectas: menos peticiones y más pequeñas significan menos carga en sus servidores. Eso alinea la eficiencia de costes con el buen civismo. Sigue recolectando datos públicos, honra los términos y rate limits de cada sitio, y deja que la eficiencia reduzca tu huella. Nuestra política de uso aceptable es la fuente de la verdad para lo que está permitido en Shifter.

Preguntas frecuentes

¿Qué usa más ancho de banda al scrapear a través de proxies? El renderizado de navegador completo, por un amplio margen, porque descarga cada imagen, fuente, vídeo, y script de la página. Recortar el renderizado (o bloquear los tipos de recurso pesados cuando debas renderizar) es el cambio de mayor impacto que puedes hacer.

¿Bloquear imágenes y fuentes rompe el scraping? Normalmente no, rara vez las necesitas para la extracción de datos. Prueba que el sitio no hace lazy-load del contenido objetivo detrás de imágenes; para la gran mayoría de los trabajos, bloquear peticiones de imagen, media, y fuente es seguro y recorta el ancho de banda sustancialmente.

¿Los proxies residenciales cobran por peticiones fallidas o bloqueadas? Los bytes que cruzan el proxy son facturables, así que los intentos fallidos y los reintentos aún cuestan ancho de banda. Por eso los reintentos eficientes, los timeouts sensatos, y evitar filtros geo demasiado ajustados (que causan fallos) importan para tu factura.

¿Está permitido golpear la API JSON de un sitio? Llamar a un endpoint público que la propia página usa es práctica común y mucho más eficiente, pero los términos y rate limits del sitio siguen aplicando. Recolecta de forma responsable y obtén asesoramiento legal para cualquier cosa incierta.

¿Cuánto puedo ahorrar realistamente? Varía según el objetivo, pero saltarse el renderizado innecesario, bloquear recursos pesados, y no re-descargar páginas sin cambios comúnmente recortan el ancho de banda total en más de la mitad para los mismos datos extraídos.

En resumen

En un plan por GB, la eficiencia de ancho de banda es eficiencia de costes, y la mayoría de los scrapers dejan mucho sobre la mesa: renderizando cuando podrían obtener, descargando assets que nunca leen, y re-trayendo páginas que nunca cambiaron. Trabaja esta lista, sáltate el navegador cuando puedas, golpea la API, bloquea recursos pesados, mantén la compresión activada, usa peticiones condicionales, no re-descargues páginas sin cambios, obtén solo lo que necesitas, haz los reintentos eficientes, y mide, y los mismos datos vuelven por una fracción de los bytes.

Esa eficiencia se compone con la calidad del pool: IPs limpias significan menos bloqueos y reintentos, que es menos bytes desperdiciados, así que vale la pena elegir los proxies correctos para scrapear junto con afinar tu cliente. Ve los planes por GB en la página de precios, luego apunta un scraper bien afinado al gateway residencial y observa cómo caen los bytes.