Cómo reducir el tráfico del parser en 5 veces sin perder datos: 7 técnicas para ingenieros de datos

Cada megabyte adicional de tráfico del parser representa un costo para el proveedor de proxies o el riesgo de caer bajo límites y recibir un baneo por IP. Si estás recolectando precios de Wildberries, Ozon o monitoreando anuncios en Avito a través de cientos de direcciones proxy, el ahorro de tráfico impacta directamente en el presupuesto del proyecto. En este artículo, se presentan técnicas técnicas concretas que permiten reducir el volumen de datos transmitidos en 4-5 veces, manteniendo la completitud y precisión de la información extraída.

Por qué el tráfico del parser afecta el presupuesto

La mayoría de los proveedores de proxies cobran por el volumen de gigabytes transmitidos, no por el tiempo de uso. Si tu parser carga la página del producto de Wildberries completamente — con imágenes, scripts de recomendaciones, rastreadores de análisis y fuentes — pagas por 2-3 MB por cada tarjeta, aunque realmente solo necesitas 15-20 KB de texto: nombre, precio, calificación, disponibilidad.

Al escalar hasta 50,000-100,000 tarjetas al día, la diferencia entre "cargar todo" y "cargar solo lo necesario" se convierte en decenas de gigabytes de tráfico innecesario diariamente. Esto no solo implica gastos en proxies, sino también una carga aumentada en el sitio objetivo, lo que incrementa la posibilidad de caer bajo protección anti-bots y recibir un captcha o un baneo temporal de IP. La optimización del tráfico es al mismo tiempo un ahorro de dinero y una reducción del riesgo de bloqueos.

Hay un tercer efecto: cuanto menos datos se transmiten por solicitud, más rápido se ejecuta la solicitud misma. Esto permite aumentar el paralelismo: ejecutar más hilos en la misma cantidad de proxies sin exceder los límites de velocidad que establecen los navegadores anti-detección como Dolphin Anty o AdsPower al trabajar con sesiones.

Técnica 1: Bloqueo de imágenes, CSS y fuentes

Si el parser funciona a través de un navegador sin cabeza (Playwright, Puppeteer, Selenium), la forma más rápida de reducir el tráfico en 2-3 veces es bloquear la carga de recursos estáticos que no afectan los datos en el DOM. Las imágenes de los productos, las fuentes del sitio web, los videos y los estilos CSS ocupan hasta el 70% del peso de la página, pero no participan en la extracción de texto y atributos.

from playwright.sync_api import sync_playwright

def block_heavy_resources(route, request):
    if request.resource_type in ["image", "media", "font", "stylesheet"]:
        route.abort()
    else:
        route.continue_()

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.route("**/*", block_heavy_resources)
    page.goto("https://example.com/product/123")
    html = page.content()
    browser.close()

Una lógica similar se implementa en Puppeteer a través de page.setRequestInterception(true) y en Selenium a través de la configuración del perfil de Chrome con el parámetro profile.managed_default_content_settings.images: 2. En la práctica, esta sola configuración reduce de inmediato entre el 50% y el 70% del tráfico al parsear marketplaces donde las páginas están sobrecargadas de contenido visual y banners publicitarios.

Técnica 2: Solicitudes HTTP en lugar de un navegador completo

Muchos utilizan Selenium o Playwright donde no es necesario. Si la página no requiere la ejecución de JavaScript para renderizar datos (esto se puede verificar fácilmente abriendo "Ver código de la página" en lugar de DevTools), es mucho más rentable obtener el HTML directamente a través de bibliotecas requests o httpx en Python. Tal solicitud pesa kilobytes, no megabytes, porque no arrastra consigo el renderizado del motor del navegador, llamadas de red para rastreadores y recursos secundarios.

import httpx

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
    "Accept-Encoding": "gzip, br",
    "Accept": "text/html,application/xhtml+xml"
}

proxies = {"http://": "http://user:pass@proxy_host:port",
           "https://": "http://user:pass@proxy_host:port"}

with httpx.Client(headers=headers, proxies=proxies, http2=True) as client:
    response = client.get("https://example.com/catalog/item/456")
    print(len(response.content), "bytes recibidos")

Cambiar de la emulación de navegador a solicitudes HTTP directas donde el sitio entrega HTML listo sin renderizado del cliente reduce el tráfico de 3 a 8 veces. El único matiz es que tales solicitudes son más fáciles de distinguir de un usuario real, por lo que para sitios con protección anti-bots estricta, es recomendable combinar este método con proxies residenciales de calidad, que proporcionan IP de proveedores de hogar reales y reducen la probabilidad de bloqueo de la solicitud.

Técnica 3: Parsing a través de JSON API ocultos

Prácticamente todos los marketplaces modernos — incluyendo Wildberries, Ozon y Yandex.Market — renderizan las tarjetas de productos y listas a través de JSON API internos que son llamados por el frontend. Estos endpoints se pueden encontrar a través de la pestaña Network en DevTools, filtrando las solicitudes por tipo XHR/Fetch. Por lo general, una de estas solicitudes devuelve JSON de 5-30 KB con datos limpios: id del producto, precio, descuento, existencias, calificación — sin un solo byte de HTML o CSS.

La diferencia en el volumen de datos transmitidos entre una página HTML completa y una llamada directa a JSON API puede alcanzar de 10 a 15 veces. Un beneficio adicional es que JSON es más fácil de parsear programáticamente: no se necesitan selectores XPath, solo es necesario acceder al campo requerido por la clave del diccionario. El inconveniente es que tales endpoints a menudo requieren encabezados específicos, tokens de sesión o parámetros de firma de solicitud que deben extraerse previamente de la página principal o de la aplicación móvil.

Técnica 4: Compresión Gzip y Brotli

Incluso si estás obligado a obtener el HTML completo, habilitar la compresión adecuada puede reducir el tamaño de la transmisión en un 60-80%. Muchos parsers hechos a mano no envían el encabezado Accept-Encoding: gzip, br, lo que hace que el servidor entregue una respuesta sin empaquetar. Las bibliotecas requests y httpx descomprimen Gzip y Brotli automáticamente — solo es importante indicar explícitamente el soporte de compresión en los encabezados de la solicitud.

Brotli, en promedio, comprime el HTML de texto más que Gzip, en un 15-20%, pero no todos los servidores soportan este algoritmo — es recomendable solicitar ambas opciones y permitir que el servidor elija la óptima. Para JSON API, el efecto de la compresión es aún más notable: las claves repetidas de los diccionarios ("price", "name", "rating") se comprimen prácticamente de manera ideal, reduciendo el peso de la respuesta drásticamente.

Técnica 5: Solicitudes condicionales y almacenamiento en caché

Si monitoreas precios de los mismos productos varias veces al día, la mayor parte de las tarjetas entre verificaciones no cambian. Utiliza los encabezados If-Modified-Since y If-None-Match con el valor ETag obtenido en la primera solicitud. Si el contenido no ha cambiado, el servidor devuelve el estado 304 Not Modified prácticamente sin cuerpo de respuesta — el ahorro de tráfico puede alcanzar hasta el 95% en páginas no modificadas.

import httpx

etag_store = {}

def fetch_with_cache(url, client):
    headers = {}
    if url in etag_store:
        headers["If-None-Match"] = etag_store[url]
    resp = client.get(url, headers=headers)
    if resp.status_code == 304:
        return None  # los datos no han cambiado
    etag_store[url] = resp.headers.get("ETag", "")
    return resp.content

No todos los sitios soportan ETag correctamente, pero para aquellos que lo hacen, esta técnica se convierte en la forma más efectiva de reducir el tráfico durante el monitoreo regular: efectivamente pagas solo por los cambios reales en los datos, no por la recarga de contenido inalterado.

Técnica 6: Parsing selectivo de campos necesarios

A veces, reducir el tráfico entrante desde el servidor es imposible — el sitio entrega la página completa independientemente de la solicitud. En este caso, la optimización ocurre en la etapa de procesamiento: no vuelvas a cargar la página solo para extraer un campo más. Diseña los selectores XPath o CSS de manera que en un solo recorrido por el DOM extraigas todos los atributos necesarios — precio, nombre, artículo, disponibilidad, calificación — en lugar de hacer solicitudes repetidas a la misma URL con diferentes parsers para diferentes tareas.

También es útil limitar la profundidad de rastreo de páginas anidadas. Si para monitorear precios son suficientes los datos de la página de categoría (lista de productos), no accedas a la tarjeta de cada producto por separado — esto genera tráfico duplicado que a menudo no proporciona nueva información, además de descripciones y reseñas que no influyen en el precio y la disponibilidad.

Técnica 7: Optimización del patrón de rastreo

La deduplicación de URL es una técnica básica, pero a menudo ignorada. Los catálogos de marketplaces generan numerosos enlaces con contenido idéntico, pero con diferentes parámetros de clasificación, etiquetas UTM o ID de sesión. La normalización de URL antes de ponerlas en cola (eliminación de parámetros de seguimiento, ordenación de parámetros de consulta) elimina del 10% al 30% de solicitudes redundantes al rastrear grandes catálogos.

La priorización del rastreo según la frecuencia de cambio de datos también ahorra tráfico: los productos con alta demanda y precios volátiles deben ser verificados cada hora, mientras que las posiciones raras — una vez al día. Este horario adaptativo en lugar de un rastreo uniforme de todas las tarjetas con la misma periodicidad reduce el volumen total de solicitudes de 2 a 4 veces sin perder la actualidad de los datos críticos.

Cómo se combina esto con la estrategia de proxies

La reducción del tráfico impacta directamente en la elección del tipo de proxy. Si estás parseando un gran volumen de páginas a través de solicitudes HTTP directas sin una compleja protección anti-bots, son suficientes proxies de centros de datos rápidos y baratos — ofrecen alta velocidad de transmisión a bajo costo por gigabyte, lo cual es crítico al escalar el parseo de miles de tarjetas al día.

Para sitios con estrictas protecciones contra bots, donde es importante simular el comportamiento de un usuario real, es mejor usar proxies residenciales — combinándolos con técnicas de bloqueo de recursos innecesarios, obtienes tanto bajo tráfico como alta confianza del sitio en la solicitud. Y si el parseo se realiza a través de versiones móviles de APIs de marketplaces, donde los datos son más compactos y el sistema anti-bots se orienta a rangos de IP móviles, es recomendable considerar proxies móviles para reducir aún más el riesgo de bloqueos.

La combinación de "mínimo tráfico por solicitud" + "tipo de proxy adecuado para la tarea" permite reducir simultáneamente los gastos en infraestructura y aumentar la velocidad de recolección de datos sin perder fiabilidad.

Tabla comparativa de técnicas

Técnica	Reducción de tráfico	Dificultad de implementación
Bloqueo de imágenes/CSS/fuentes	50-70%	Baja
Solicitudes HTTP en lugar de navegador	3-8 veces	Media
JSON API ocultos	10-15 veces	Alta
Compresión Gzip/Brotli	60-80%	Baja
Solicitudes condicionales (ETag)	hasta 95% en páginas no modificadas	Media
Deduplicación de URL y priorización	2-4 veces	Media

Lista de verificación para la implementación

• Verificar si la página objetivo requiere renderizado JavaScript, o si se puede obtener HTML directamente a través de httpx/requests
• Configurar el bloqueo de image/media/font/stylesheet en el navegador sin cabeza, si es que el navegador es necesario
• Encontrar JSON API internos a través de DevTools → Network → XHR/Fetch
• Agregar encabezados Accept-Encoding: gzip, br en todas las solicitudes
• Implementar almacenamiento de ETag/Last-Modified para solicitudes condicionales en URL repetidas
• Normalizar y deduplicar la cola de URL antes del rastreo
• Configurar una frecuencia de rastreo adaptativa según la importancia y volatilidad de los datos
• Seleccionar el tipo de proxy según el perfil de tráfico final — centro de datos, residenciales o móviles

Conclusión

Reducir el tráfico del parser en 5 veces es un objetivo realista si se aplican las técnicas de manera secuencial: eliminar recursos innecesarios, cambiar a solicitudes HTTP directas o JSON API donde sea posible, habilitar la compresión, utilizar solicitudes condicionales para datos inalterados y optimizar el propio patrón de rastreo. Cada uno de estos pasos proporciona un efecto medible, y en conjunto, cambian radicalmente la economía del proyecto de recolección de datos de marketplaces y otros sitios.

Después de optimizar el tráfico, es importante seleccionar correctamente la infraestructura de proxies para el nuevo perfil de carga. Para la recolección rápida y económica de grandes volúmenes de datos, son adecuados los proxies de centros de datos, mientras que para trabajar con sitios con estrictas protecciones anti-bots, son recomendables los proxies residenciales con direcciones IP reales de proveedores de hogar, que reducen el riesgo de bloqueo incluso con un parseo intensivo.