Si pagas por tráfico proxy por GB, la diferencia entre un navegador sin cabeza y un cliente HTTP normal puede costarte entre 15 y 20 veces más dinero en el mismo conjunto de datos de 1000 páginas. En este artículo, se presentan mediciones reales del consumo de tráfico para Playwright, Puppeteer y la biblioteca requests de Python, código para pruebas y formas efectivas de reducir el volumen de datos sin perder contenido.
Por qué el consumo de tráfico es crítico para el scraping
La mayoría de los proveedores de proxies, incluidos los pools residenciales y móviles, cobran por tráfico en GB, no por cantidad de solicitudes. Esto significa que la herramienta que utilizas para hacer scraping en un sitio afecta directamente al presupuesto del proyecto. Un navegador sin cabeza carga la página completa: HTML, CSS, JavaScript, imágenes, fuentes, scripts analíticos, banners publicitarios y rastreadores. Un cliente HTTP como requests solo descarga lo que has solicitado explícitamente: generalmente, se trata de un documento HTML limpio.
La diferencia es especialmente notable a gran escala. Si estás scrapeando tarjetas de productos en Wildberries o Ozon, recopilando precios de competidores o monitoreando los resultados de Google, un volumen de 1000 páginas es una norma diaria típica para un script. Al trabajar con varios cientos de miles de páginas al mes, el ahorro en tráfico se convierte en un artículo de gasto significativo, especialmente si se utilizan proxies residenciales, donde el costo por GB es más alto que en los de centros de datos.
La dificultad adicional es que los sitios modernos se protegen activamente contra bots: verifican la renderización de JavaScript, el comportamiento del ratón, el fingerprinting de canvas. Esto obliga a los desarrolladores a pasar de simples solicitudes HTTP a navegadores completos como Playwright o Puppeteer, que "pesan" mucho más en tráfico. Comprender las cifras exactas ayuda a calcular el presupuesto para proxies y elegir la herramienta adecuada para la tarea específica.
Metodología de medición de tráfico
Para una comparación justa, utilicé la misma lista de 1000 URL: tarjetas de productos de complejidad media con imágenes, scripts de análisis y varios widgets de terceros (una estructura típica para un sitio de comercio electrónico). La medición del tráfico se realizó a través del monitor de red del sistema y las herramientas de registro de solicitudes integradas en cada herramienta.
Condiciones importantes del experimento:
- La caché del navegador está desactivada: cada página se carga "desde cero", como ocurre al trabajar a través de la rotación de proxies con diferentes IP.
- El modo sin cabeza está activado en todas las pruebas de navegador: así es como funcionan la mayoría de los scripts de producción.
- Sin bloqueo de recursos en el escenario básico: para mostrar el consumo "limpio" sin optimizaciones.
- La misma red y el mismo conjunto de páginas para las tres herramientas.
Este enfoque proporciona cifras comparables que se pueden aplicar a tu propio caso: multiplicando por la cantidad de páginas en tu proyecto y dividiendo por el volumen de la tarifa de proxy.
requests: consumo mínimo de tráfico
La biblioteca requests en Python descarga solo el cuerpo de la respuesta HTTP: lo que has solicitado explícitamente. Sin JavaScript, sin imágenes, sin solicitudes adicionales a CDN. El peso promedio de una página HTML de una tarjeta de comercio electrónico en mi prueba fue de aproximadamente 180-250 KB de HTML sin comprimir.
import requests
proxies = {
"http": "http://user:pass@proxy_host:port",
"https": "http://user:pass@proxy_host:port",
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
total_bytes = 0
urls = load_urls_from_file("urls.txt") # lista de 1000 enlaces
for url in urls:
response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
total_bytes += len(response.content)
print(f"Total descargado: {total_bytes / 1024 / 1024:.2f} MB")
En 1000 páginas, el consumo total fue de 190-230 MB — es decir, menos de 0,25 GB. Esta es la opción más económica, pero tiene una limitación crítica: si el sitio renderiza contenido a través de JavaScript (React, Vue, carga dinámica de precios), requests obtendrá un marco vacío de la página sin los datos necesarios. Para HTML estático o sitios con SSR, esta es la opción ideal en términos de tráfico y resultado.
Puppeteer: cuánto pesa Chrome sin cabeza
Puppeteer controla un motor real de Chromium, por lo que carga la página completamente: HTML, CSS, fuentes, imágenes, scripts de seguimiento, iframes publicitarios. Incluso en modo sin cabeza, el navegador realiza todas las solicitudes de red que haría un usuario normal en Chrome.
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({
headless: 'new',
args: ['--proxy-server=http://proxy_host:port']
});
const page = await browser.newPage();
await page.authenticate({ username: 'user', password: 'pass' });
let totalBytes = 0;
page.on('response', async (response) => {
try {
const buffer = await response.buffer();
totalBytes += buffer.length;
} catch (e) {}
});
const urls = require('./urls.json'); // 1000 enlaces
for (const url of urls) {
await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
}
console.log(`Total de tráfico: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
await browser.close();
})();
En mi prueba, el peso promedio de una página a través de Puppeteer fue de 2,8-4,5 MB, dependiendo de la cantidad de imágenes y scripts de terceros. En 1000 páginas, esto dio un resultado de 3,1-4,2 GB — de 15 a 18 veces más que requests. La mayor parte del tráfico proviene de imágenes (generalmente del 40 al 55% del peso de la página) y scripts de análisis, publicidad y widgets de chat (20-30%).
Playwright: tráfico en diferentes navegadores
Playwright funciona de manera similar, pero soporta tres motores: Chromium, Firefox y WebKit. El consumo de tráfico entre ellos varía: WebKit en modo sin cabeza es tradicionalmente un poco más económico debido a un procesamiento diferente del contenido multimedia, mientras que Firefox a veces carga más datos debido a diferencias en la caché de recursos entre solicitudes.
from playwright.sync_api import sync_playwright
total_bytes = 0
def handle_response(response):
global total_bytes
try:
body = response.body()
total_bytes += len(body)
except Exception:
pass
with sync_playwright() as p:
browser = p.chromium.launch(
headless=True,
proxy={"server": "http://proxy_host:port", "username": "user", "password": "pass"}
)
page = browser.new_page()
page.on("response", handle_response)
urls = load_urls_from_file("urls.txt")
for url in urls:
page.goto(url, wait_until="networkidle", timeout=30000)
print(f"Total de tráfico: {total_bytes / 1024 / 1024:.2f} MB")
browser.close()
En Chromium a través de Playwright, el resultado fue similar al de Puppeteer — 2,9-4,3 GB en 1000 páginas, lo cual es lógico, ya que ambas herramientas utilizan el mismo motor. En WebKit, el consumo fue un 10-15% menor, alrededor de 2,6-3,7 GB, y en Firefox fue un poco más alto, 3,3-4,6 GB. La diferencia se explica por las variaciones en el procesamiento de fuentes, la decodificación de imágenes y el comportamiento de la pila de red de cada motor de navegador.
Tabla comparativa: GB en 1000 páginas
A continuación, se presenta una tabla resumen de todas las variantes probadas, redondeada a rangos prácticos. Las cifras son relevantes para una página de comercio electrónico promedio con imágenes y un conjunto típico de scripts de terceros: en sitios de noticias o landing pages con video, el consumo será mayor.
| Herramienta | Tráfico en 1000 páginas | Renderización JS | Evasión de detección de bots |
|---|---|---|---|
| requests (Python) | 0,19-0,23 GB | No | Débil |
| Playwright (WebKit) | 2,6-3,7 GB | Sí | Medio |
| Puppeteer (Chromium) | 3,1-4,2 GB | Sí | Medio |
| Playwright (Chromium) | 2,9-4,3 GB | Sí | Bueno |
| Playwright (Firefox) | 3,3-4,6 GB | Sí | Medio |
La conclusión clave es: si el sitio no requiere renderización de JavaScript para obtener los datos necesarios, requests ahorra tráfico de 15 a 20 veces en comparación con cualquier solución de navegador. Pero si el contenido se carga dinámicamente o el sitio verifica activamente el comportamiento del navegador, tendrás que pagar por el tráfico de renderización del navegador.
Cómo reducir el consumo de tráfico en 5-10 veces
Incluso si necesitas un navegador completo, el consumo de tráfico se puede reducir drásticamente sin perder los datos necesarios. Aquí hay técnicas efectivas que probé en el mismo conjunto de 1000 páginas.
1. Bloqueo de imágenes, fuentes y medios. Las imágenes suelen representar más de la mitad del peso de la página, y para el scraping de datos textuales no son necesarias.
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'font', 'media'].includes(type)) {
route.abort();
} else {
route.continue();
}
});
Esta técnica funciona igual en Playwright y Puppeteer y reduce el tráfico en un 40-60% sin perder HTML y datos textuales.
2. Bloqueo de dominios de terceros. Las redes publicitarias, analíticas y los widgets de chat cargan sus propios scripts e imágenes que no necesitas. Puedes filtrar solicitudes por dominio, dejando solo el recurso principal y su CDN.
3. Uso de "domcontentloaded" en lugar de "networkidle". Esperar la carga completa de la red hace que el navegador espere todas las solicitudes en segundo plano, incluyendo análisis y carga perezosa. Si los datos aparecen en el DOM antes, cambiar a un evento anterior acelera el scraping y reduce cargas innecesarias.
4. Caché de recursos estáticos entre solicitudes. Si el sitio utiliza los mismos archivos CSS/JS en todas las páginas, la caché del navegador activada (a diferencia de las condiciones de nuestra prueba) ahorra un volumen significativo al recorrer secuencialmente un gran número de URL de un mismo dominio.
5. Enfoque híbrido. Muchos equipos primero prueban requests, y solo si los datos son insuficientes, cambian a páginas específicas a través de Playwright o Puppeteer. Esto combina un bajo consumo base de tráfico con la posibilidad de renderización donde realmente se necesita.
Con un bloqueo adecuado de recursos, el consumo de tráfico de Puppeteer y Playwright se reduce de 3-4 GB a 0,6-1,2 GB en 1000 páginas — la diferencia se vuelve notablemente menor en comparación con requests, manteniendo la posibilidad de trabajar con renderización JS y protección contra bots.
Cómo elegir un proxy según el volumen de tráfico
El cálculo del tráfico afecta directamente la elección del tipo de proxy. Para solicitudes HTTP ligeras a través de requests en sitios estáticos, son adecuados los proxies de centros de datos — son rápidos, baratos en tráfico y suficientes si el sitio no verifica señales de comportamiento.
Si la tarea requiere renderización completa a través de Playwright o Puppeteer para evadir sistemas anti-bots — por ejemplo, al recopilar precios en marketplaces o monitorear resultados de motores de búsqueda — es más sensato utilizar proxies residenciales. Son menos propensos a ser bloqueados por reputación IP, lo cual es crítico cuando cada solicitud "pesa" varios megabytes y la recolección de datos debido a bloqueos resulta costosa.
Para escenarios donde el sitio verifica estrictamente la coincidencia de IP y user-agent (servicios bancarios, aplicaciones con verificación móvil), vale la pena considerar proxies móviles — a pesar de su mayor costo de tráfico, ofrecen la máxima confiabilidad de la dirección IP y minimizan el número de solicitudes repetidas debido a bloqueos.
Una guía práctica: calcula el volumen de tráfico usando la fórmula "peso de una página × número de páginas × coeficiente de repeticiones debido a errores y bloqueos" y compara el total de GB con la tarifa del proveedor. La optimización de recursos, como se describió anteriormente, generalmente ofrece más ahorro que elegir un tipo de proxy más barato — pero la combinación de la herramienta correcta y el proxy correcto proporciona el máximo efecto.
Conclusión
requests sigue siendo la herramienta más económica en términos de tráfico — alrededor de 0,2 GB en 1000 páginas, pero no es adecuada para sitios con contenido dinámico. Puppeteer y Playwright ofrecen renderización completa y mejor evasión de protección, pero el consumo de tráfico aumenta a 3-4,5 GB en las mismas 1000 páginas. El bloqueo de imágenes, fuentes y dominios de terceros reduce esta brecha de 3 a 5 veces, manteniendo los datos necesarios.
Antes de iniciar un scraping a gran escala, calcula el volumen de tráfico esperado teniendo en cuenta la herramienta elegida y presupuesta en consecuencia para los proxies. Si la tarea requiere renderización de JavaScript y resistencia a sistemas anti-bots, comienza con una prueba en un pequeño conjunto de páginas a través de proxies residenciales — esto permitirá evaluar con precisión el consumo real de GB antes de lanzar el scraping en el volumen completo de datos.