Fíjate en los registros de captura de casi cualquier rastreador de larga duración y aparece el mismo patrón. La gran mayoría de las solicitudes devuelven una página idéntica a la última copia. Cada una de esas capturas costó ancho de banda o créditos, ocupó un slot de concurrencia y cargó el servidor de otra persona, y no produjo absolutamente nada.
Eso no es un fallo en el sistema de captura. Es una decisión de planificación, normalmente tomada por defecto: revisitar todo en el mismo ciclo, o revisitar las cosas importantes con más frecuencia. Ambas parecen razonables, y ambas malgastan la mayor parte del presupuesto. Este artículo trata sobre tomar la decisión de forma deliberada, poniendo precio a cada visita según lo que probablemente vaya a aportar.
Mide la unidad correcta
Los equipos suelen medir el coste por página capturada. El número que importa es el coste por cambio detectado.
Un rastreador que captura un millón de páginas al día y detecta diez mil cambios ha gastado cien capturas por cada observación útil. Reducir a la mitad el número de capturas sin perder cambios reduce a la mitad el coste del conjunto de datos. Duplicar el número de capturas sin encontrar más cambios lo duplica sin ningún beneficio. Pon “capturas que no encontraron ningún cambio” en un panel, por sitio y por tipo de página, y quedará claro adónde va el dinero.
Conoce lo que realmente cuesta una captura
El coste de una visita depende de cómo se te facture, y los dos modelos habituales premian optimizaciones distintas.
| Modelo de facturación | Por qué pagas | Qué hace más barata una visita |
|---|---|---|
| Ancho de banda de proxy residencial | Bytes a través de la puerta de enlace | Respuestas más pequeñas: sin renderizado, sin imágenes, transferencia comprimida |
| Créditos de API de scraping | Respuestas correctas | Menos capturas; el tamaño de cada una importa mucho menos |
En la puerta de enlace residencial de Shifter cuenta cada byte enviado o recibido, incluidas las cabeceras, y las solicitudes fallidas cuentan si se transfirieron bytes antes del error. Reducir el tamaño de cada captura tiene un beneficio directo, y las tácticas para ello se tratan en cómo reducir los costes de ancho de banda de proxy. En el Web Scraping API, una solicitud correcta cuesta un crédito tanto si el renderizado de JavaScript está activado como si no, y las solicitudes fallidas y los errores del objetivo no cuestan nada. Ahí, una página renderizada y una sin renderizar cuestan lo mismo, y la única palanca que mueve la factura es cuántas capturas correctas solicitas.
En cualquier caso, el planificador es la palanca más grande que tienes, porque la captura más barata es la que decidiste no hacer.
¿Con qué frecuencia cambia cada página?
Planificar según el valor esperado requiere una estimación de con qué frecuencia cambia cada página. La suposición de trabajo estándar en la investigación sobre rastreadores es que los cambios llegan de forma más o menos aleatoria a una tasa media por página, lo que hace que la probabilidad de que una página haya cambiado desde tu última visita sea:
P(cambio) = 1 - e^(-tasa × tiempo desde la última visita)
Estimas la tasa a partir de tu propio historial. Cada visita te dice si la página cambió desde la anterior. Divide los cambios observados por el tiempo observado, por página, y suavízalo hacia la media de páginas similares para que una página visitada tres veces no obtenga una estimación extrema.
Dos advertencias. Primero, una visita solo puede decirte que una página cambió, no cuántas veces, así que las páginas que cambian más rápido de lo que las visitas parecen más lentas de lo que realmente son. Segundo, define “cambio” según los campos que te importan. Una página cuya marca de tiempo, espacio publicitario o token de sesión difiere en cada carga cambia constantemente y no significa nada. Aplica el hash al registro extraído, no al HTML.
El resultado contraintuitivo: no persigas las páginas más rápidas
La política obvia es visitar las páginas en proporción a la frecuencia con la que cambian. También es errónea, y la prueba tiene más de veinte años.
En “Effective Page Refresh Policies for Web Crawlers” (ACM Transactions on Database Systems, 2003), Junghoo Cho y Hector Garcia-Molina compararon políticas de asignación para mantener una copia local actualizada con un presupuesto de visitas fijo. Su conclusión, en sus propias palabras, es que “la política uniforme es siempre más efectiva que la política proporcional bajo cualquier escenario”. Su política óptima va más allá, y la resumen directamente: “Para mejorar la actualización, deberíamos penalizar a los elementos que cambian con demasiada frecuencia.”
La intuición es sencilla una vez expuesta. Una página que cambia cada quince minutos vuelve a estar obsoleta casi tan pronto como la capturas. Visitarla compra unos pocos minutos de actualidad. Una página que cambia aproximadamente una vez al día, visitada diariamente, permanece correcta durante la mayor parte del día después de cada visita. Con un presupuesto limitado, la segunda es una compra mucho mejor.
Se puede poner un número a esto. Bajo el mismo modelo de cambio, la actualidad que compra una visita es la probabilidad de que la página esté actualmente obsoleta multiplicada por cuánto tiempo es probable que permanezca correcta después. Para un rastreador que puede revisitar aproximadamente una vez al día:
| Frecuencia de cambio de la página | Actualidad comprada por visita (días) |
|---|---|
| Cada 15 minutos aproximadamente | 0,010 |
| Aproximadamente cada hora | 0,042 |
| Cada 6 horas aproximadamente | 0,241 |
| Aproximadamente a diario | 0,400 |
| Aproximadamente semanal | 0,124 |
| Aproximadamente mensual | 0,032 |
| Aproximadamente anual | 0,003 |
Las mejores compras son las páginas que cambian aproximadamente al ritmo que puedes permitirte revisitar. Las páginas que cambian mucho más rápido son casi imposibles de mantener actualizadas a cualquier ritmo asequible; las páginas que cambian mucho más lento casi siempre están ya actualizadas.
Hay una excepción importante. El resultado trata sobre actualidad: con qué frecuencia tu copia coincide con la página en vivo. Algunos trabajos tratan de capturar eventos en su lugar: cada cambio de precio, cada agotamiento de stock, cada edición. Si cada cambio importa individualmente, las páginas que cambian rápido necesitan más visitas, no menos, y la respuesta correcta puede ser una fuente completamente distinta, como una API, un feed o una página de listado que muestre el cambio sin necesidad de una captura completa. Decide qué problema estás resolviendo antes de afinar.
Puntúa cada visita por valor esperado por coste
Uniendo las piezas, cada visita candidata recibe una prioridad: cuánto importa la página, multiplicado por la actualidad que compraría una visita, dividido por lo que cuesta la visita.
import math
def freshness_gain(rate, days_since_visit, interval_days):
"""Expected fresh days bought by visiting now, under a Poisson change model."""
p_stale = 1 - math.exp(-rate * days_since_visit)
fresh_after = (1 - math.exp(-rate * interval_days)) / rate if rate > 0 else interval_days
return p_stale * fresh_after
def priority(page, today, interval_days=1.0):
gain = freshness_gain(page.change_rate, today - page.last_fetched, interval_days)
return page.value * gain / page.costEl planificador entonces trabaja a partir de una cola de prioridad: en cada ciclo, gasta el presupuesto en las visitas con mejor puntuación y se detiene. Tres entradas merecen atención especial.
- El valor es un juicio de negocio, no técnico. Un producto que se vende, un competidor que importa, una consulta que hacen tus clientes. Mantenlo simple; tres o cuatro niveles suelen ser suficientes.
- El coste debe ser el coste real de esa visita: bytes para ese tipo de página, créditos, y si necesita renderizado. Una página que necesita un navegador headless en un plan facturado por ancho de banda puede costar muchas veces más que una captura sencilla.
- La tasa de cambio proviene de tu historial, actualizada después de cada visita.
Señales baratas antes de capturas costosas
A menudo puedes averiguar si una página cambió por mucho menos del precio de capturarla.
- Solicitudes condicionales. Cuando un sitio respeta
ETagoLast-Modified, una respuesta304 Not Modifiedcuesta una fracción de los bytes. Registra por host si los validadores son fiables; algunos sitios los envían y los ignoran. - Páginas de listado como detectores de cambios. Una página de categoría o de búsqueda a menudo muestra el precio y la disponibilidad de decenas de artículos. Captura el listado, compara, y captura solo los artículos cuyo resumen cambió. Así es como la mayoría de los feeds de precios en tiempo real y los monitores de stock se mantienen asequibles.
- Sitemaps y feeds. Cuando incluyen fechas de modificación fiables, te dicen qué cambió sin necesidad de visitar nada más.
- Endpoints estructurados. Una respuesta JSON detrás de una página suele ser más pequeña y más estable que la propia página.
Reserva presupuesto para lo que el planificador no puede ver
Un planificador que solo optimiza páginas conocidas se quedará ciego poco a poco. Reserva parte de cada ciclo para tres cosas:
- Descubrimiento. Las URL nuevas no tienen historial y nunca superarían en puntuación a las páginas ya establecidas. Dales su propia asignación.
- Reestimación. Una página puntuada como invariable durante meses debería seguir visitándose de vez en cuando, porque las páginas cambian de comportamiento. Sin esto, una estimación errónea nunca se corrige.
- Verificación. Una pequeña muestra aleatoria, capturada independientemente de la puntuación, te dice si las suposiciones del modelo aún se cumplen.
Deja que el coste y el estado influyan en la planificación
La planificación es un plan, no una garantía. Cuando un sitio empieza a limitar el tráfico, el planificador debería enterarse y reordenar prioridades, en lugar de seguir encolando visitas que la etapa de captura no puede realizar. Esa vía de retroalimentación, desde los sistemas de captura hasta la frontera, se trata en backpressure y control de flujo en rastreadores distribuidos, y la condición general de un sitio en construir una puntuación de estado del objetivo. Una puntuación de estado en descenso también debería aumentar el coste efectivo de visitar ese sitio, que es exactamente la señal que necesita un planificador consciente del coste.
Conclusión
Un presupuesto de rastreo gastado de forma uniforme, o en proporción a lo ocupada que está cada página, se gasta principalmente en confirmar que no ha pasado nada. Estima con qué frecuencia cambia cada página a partir de tu propio historial, pon precio a cada visita según lo que va a comprar y lo que va a costar, y da el presupuesto primero a las mejores compras. Espera que esas sean las páginas que cambian aproximadamente al ritmo que puedes permitirte seguir, no las que cambian más rápido.
El beneficio no es solo una factura más pequeña. Un rastreador que captura menos, y captura con más cuidado, también supone una carga menor para los sitios de los que depende.
Fuentes y referencias
- Junghoo Cho y Hector Garcia-Molina, Effective Page Refresh Policies for Web Crawlers, ACM Transactions on Database Systems, Vol. 28, No. 4, December 2003.
- Shifter, Residential Proxies bandwidth and billing. Qué cuenta como tráfico.
- Shifter, Web Scraping API errors and limits. Costes de créditos, comportamiento ante fallos y reintentos.