Cómo reducir los costos de ancho de banda de proxy: reduce tu factura de GB entre un 60-90%
En los proxies de pago por GB, tu factura se basa en bytes, no en solicitudes, y la mayoría de esos bytes son imágenes y fuentes que nunca analizas. Aquí te mostramos cómo eliminarlos y reducir una factura de GB residencial a más de la mitad.
En los proxies de pago por GB, tu factura se basa en bytes, no en solicitudes, y la incómoda verdad es que la mayoría de esos bytes son imágenes, fuentes y hojas de estilo que nunca analizas. Una sola foto de producto en alta resolución puede ser de 2.2 MB; una renderización completa de una página en el navegador puede ser de 2-5 MB. El HTML ligero del que realmente extraes suele estar por debajo de 150 KB. Elimina el resto y una factura de GB residencial se reduce entre un 60-90%. Esta guía es el manual práctico: bloquea activos, omite páginas sin cambios, comprime y dirígete a JSON en lugar de HTML.
Primero, conoce por qué te facturan
El ancho de banda residencial se mide por la suma de datos transmitidos en ambas direcciones: encabezados de solicitud más cuerpo de solicitud, y encabezados de respuesta más cuerpo de respuesta. Eso significa que cada activo que una página carga — cada imagen, fuente y script de seguimiento — aparece en tu factura aunque ninguno de ellos alimente tu analizador. El objetivo de optimización es simple: descarga solo los bytes de los que extraes. Todo lo demás es desperdicio por el que estás pagando.
Bloquea activos en un navegador sin cabeza
Si estás manejando un navegador, esta es la palanca más grande. Playwright y Puppeteer te permiten interceptar solicitudes y abortar los tipos de recursos que no necesitas. Bloquear imágenes, medios, fuentes y hojas de estilo típicamente reduce el peso de la página en la mayoría — el DOM aún se construye, por lo que tus selectores y cualquier JSON de hidratación sobreviven:
// 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' });Dos advertencias: no bloquees las llamadas XHR/fetch que llevan los datos que buscas, y prueba que la página aún renderiza lo que necesitas — bloquear en exceso puede romper la lógica propia de un sitio. Si estás considerando un navegador frente a solicitudes simples, nuestro desglose del costo de renderizado vs solicitudes HTTP muestra la brecha de 10-50x que hace que esta decisión sea importante.
Omite páginas que no han cambiado
El byte más barato es el que no descargas. Dos técnicas reducen el desperdicio de re-solicitudes en trabajos de monitoreo. Una solicitud HEAD solo extrae encabezados para verificar Content-Length o Last-Modified antes de comprometerte con el GET completo. Mejor aún, un GET condicional envía el ETag o la marca de tiempo de la última vez y el servidor responde con 304 Not Modified con un cuerpo vacío cuando nada ha cambiado — pagas por unos pocos bytes de encabezado en lugar de toda la página:
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")Para un scraper que revisa las mismas páginas diariamente, los GET condicionales por sí solos pueden reducir drásticamente el ancho de banda, porque la mayoría de las páginas no cambian entre ejecuciones.
Siempre acepta compresión
El texto se comprime bien — HTML, JSON y CSS se reducen un 70-90% con gzip o brotli — y se te factura por el tamaño comprimido que realmente cruza el cable. Envía un encabezado Accept-Encoding y deja que el servidor comprima. En requests de Python esto está activado por defecto cuando no lo desactivas; en un cliente sin procesar, pídelo explícitamente:
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 sizeDirígete a JSON, no a HTML
La mayor ganancia estructural es omitir la página renderizada por completo. Muchos sitios se hidratan desde un endpoint JSON que lleva los mismos datos en una fracción de los bytes — el precio y el stock de un producto como una respuesta de API de 10 KB en lugar de una página renderizada de 3 MB. Encuentra la llamada XHR en la pestaña de Red de tu navegador y accede a ella directamente. Las tiendas Shopify son el ejemplo clásico: el endpoint products.json te entrega todo el catálogo sin HTML en absoluto. Cuando puedas leer la API, hazlo — es la diferencia entre kilobytes y megabytes por registro.
Deja que la API cuente los bytes por ti
Si prefieres no ajustar manualmente las reglas de bloqueo por sitio, una Scraper API que renderiza solo cuando es necesario y devuelve markdown o JSON analizado hace el trabajo de eliminación de activos por ti — recibes el contenido extraído, no los megabytes de los que provino. Y en proxies residenciales de pago por GB los ahorros son directos: menos bytes en el cable son menos dólares en la factura, sin perder nada de los datos que conservas. Para una visión completa de lo que realmente compra un gigabyte, consulta nuestro desglose de precios por GB.
Haz scraping más eficiente en proxies residenciales de pago por GB
Preguntas frecuentes
¿Cómo se calcula el ancho de banda del proxy?
Por el total de bytes transmitidos en ambas direcciones: encabezados de solicitud más cuerpo de solicitud, y encabezados de respuesta más cuerpo de respuesta. Así que cada imagen, fuente y script que carga una página cuenta para tu uso, no solo el HTML que analizas. Por eso bloquear activos no utilizados y omitir páginas sin cambios se traduce directamente en una factura más baja en planes de pago por GB.
¿Bloquear imágenes rompe el scraping?
No si tienes cuidado. Bloquear imágenes, medios, fuentes y hojas de estilo deja el DOM y JavaScript intactos, por lo que tus selectores y cualquier JSON de hidratación aún funcionan — solo omites la carga visual. El riesgo es bloquear en exceso: nunca abortes las llamadas XHR/fetch que llevan tus datos, y prueba que la página aún produce lo que necesitas antes de ejecutar a gran escala.
¿Cuál es el mayor ahorro de ancho de banda?
Dirigirse a un endpoint JSON en lugar de renderizar la página completa, donde exista. Una respuesta de API de 10 KB puede reemplazar un renderizado de 3 MB para el mismo registro — una reducción del 99%. Después de eso, bloquear activos en un navegador sin cabeza y usar GET condicionales en re-rastreados son las mayores ganancias. La compresión es casi gratuita y siempre debería estar activada.
¿Cuánto puedo ahorrar realmente?
Bloquear activos típicamente reduce el peso de una página renderizada en más de la mitad; los GET condicionales pueden reducir el ancho de banda de re-rastreo a casi cero para páginas que no cambian; y cambiar de HTML a una ruta JSON es a menudo una reducción de más del 90% por registro. Juntos, una reducción del 60-90% en una factura de GB residencial es un objetivo realista para la mayoría de los proyectos.
Nada de esto cambia lo que extraes — cambia lo que pagas por extraerlo. Bloquea los activos que nunca lees, omite las páginas que no se han movido, acepta la compresión y prefiere rutas JSON sobre renderizados completos. En proxies de pago por GB esos cuatro hábitos rutinariamente reducen una factura a más de la mitad. Para la arquitectura que escala esto a millones de páginas, consulta nuestra guía sobre arquitectura de scraping a gran escala.