Regardez les journaux de récupération de presque n’importe quel crawler de longue durée et le même schéma apparaît. La grande majorité des requêtes renvoient une page identique à la dernière copie. Chacune de ces récupérations a coûté de la bande passante ou des crédits, occupé un emplacement de concurrence et généré une charge sur le serveur de quelqu’un d’autre, pour ne produire absolument rien.
Ce n’est pas un bug du fetcher. C’est une décision d’ordonnancement, généralement prise par défaut : revisiter tout selon le même cycle, ou revisiter plus souvent les éléments importants. Les deux paraissent raisonnables, et les deux gaspillent la majeure partie du budget. Cet essai porte sur la manière de prendre cette décision délibérément, en évaluant chaque visite selon ce qu’elle est susceptible d’apporter.
Mesurer la bonne unité
Les équipes suivent généralement le coût par page récupérée. Le chiffre qui compte est le coût par changement détecté.
Un crawler qui récupère un million de pages par jour et détecte dix mille changements a dépensé cent récupérations par observation utile. Diviser par deux le nombre de récupérations sans perdre de changements divise par deux le coût du jeu de données. Doubler le nombre de récupérations sans trouver plus de changements le double pour rien. Placez « récupérations n’ayant trouvé aucun changement » sur un tableau de bord, par site et par type de page, et il devient évident où va l’argent.
Savoir ce que coûte réellement une récupération
Le coût d’une visite dépend de votre mode de facturation, et les deux modèles courants récompensent des optimisations différentes.
| Modèle de facturation | Ce que vous payez | Ce qui rend une visite moins chère |
|---|---|---|
| Bande passante de proxy résidentiel | Octets transitant par la passerelle | Réponses plus petites : pas de rendu, pas d’images, transfert compressé |
| Crédits d’API de scraping | Réponses réussies | Moins de récupérations ; la taille de chacune compte beaucoup moins |
Sur la passerelle résidentielle de Shifter, chaque octet envoyé ou reçu compte, en-têtes inclus, et les requêtes échouées comptent si des octets ont été transférés avant l’erreur. Réduire chaque récupération est directement rentable, et les tactiques pour cela sont détaillées dans réduire les coûts de bande passante des proxys. Sur l’API Web Scraping, une requête réussie coûte un crédit, que le rendu JavaScript soit activé ou non, et les requêtes échouées ainsi que les erreurs de cible ne coûtent rien. Là, une page rendue et une page brute coûtent le même prix, et le seul levier qui influe sur la facture est le nombre de récupérations réussies demandées.
Dans les deux cas, l’ordonnanceur est le plus grand levier dont vous disposez, car la récupération la moins chère est celle que vous avez décidé de ne pas faire.
À quelle fréquence chaque page change-t-elle ?
Ordonnancer selon la valeur attendue nécessite une estimation de la fréquence de changement de chaque page. L’hypothèse de travail standard dans la recherche sur les crawlers est que les changements arrivent à peu près aléatoirement à un taux moyen par page, ce qui donne la probabilité qu’une page ait changé depuis votre dernière visite :
P(changed) = 1 - e^(-rate × time since last visit)
Vous estimez le taux à partir de votre propre historique. Chaque visite vous indique si la page a changé depuis la précédente. Divisez le nombre de changements observés par le temps observé, par page, et lissez-le vers la moyenne des pages similaires afin qu’une page visitée trois fois n’obtienne pas une estimation extrême.
Deux mises en garde. D’abord, une visite ne peut vous dire qu’une page a changé, pas combien de fois, donc les pages qui changent plus vite que vous ne les visitez paraissent plus lentes qu’elles ne le sont réellement. Ensuite, définissez « changé » en fonction des champs qui vous importent. Une page dont l’horodatage, l’emplacement publicitaire ou le jeton de session diffère à chaque chargement change constamment et cela ne signifie rien. Hachez l’enregistrement extrait, pas le HTML.
Le résultat contre-intuitif : ne poursuivez pas les pages les plus rapides
La politique évidente consiste à visiter les pages proportionnellement à la fréquence de leurs changements. Elle est aussi fausse, et la preuve date de plus de vingt ans.
Dans « Effective Page Refresh Policies for Web Crawlers » (ACM Transactions on Database Systems, 2003), Junghoo Cho et Hector Garcia-Molina ont comparé des politiques d’allocation pour maintenir une copie locale à jour avec un budget de visites fixe. Leur conclusion, dans leurs propres termes, est que « la politique uniforme est toujours plus efficace que la politique proportionnelle, quel que soit le scénario ». Leur politique optimale va plus loin, et ils la résument directement : « Pour améliorer la fraîcheur, nous devrions pénaliser les éléments qui changent trop souvent. »
L’intuition est simple une fois énoncée. Une page qui change toutes les quinze minutes redevient obsolète presque aussitôt récupérée. La visiter n’achète que quelques minutes de fraîcheur. Une page qui change environ une fois par jour, visitée quotidiennement, reste correcte pendant la majeure partie de la journée après chaque visite. Avec un budget limité, la seconde est un bien meilleur achat.
On peut y mettre un chiffre. Sous le même modèle de changement, la fraîcheur qu’une visite achète est la probabilité que la page soit actuellement obsolète multipliée par la durée pendant laquelle elle restera probablement correcte ensuite. Pour un crawler pouvant revisiter environ une fois par jour :
| Fréquence de changement de la page | Fraîcheur achetée par visite (jours) |
|---|---|
| Environ toutes les 15 minutes | 0,010 |
| Environ toutes les heures | 0,042 |
| Environ toutes les 6 heures | 0,241 |
| Environ tous les jours | 0,400 |
| Environ toutes les semaines | 0,124 |
| Environ tous les mois | 0,032 |
| Environ tous les ans | 0,003 |
Les meilleurs achats sont les pages qui changent à peu près au rythme que vous pouvez vous permettre de revisiter. Les pages qui changent beaucoup plus vite sont presque impossibles à maintenir fraîches à un coût abordable ; les pages qui changent beaucoup plus lentement sont presque toujours déjà fraîches.
Il existe une exception importante. Ce résultat porte sur la fraîcheur : la fréquence à laquelle votre copie correspond à la page en direct. Certaines tâches consistent plutôt à capturer des événements : chaque changement de prix, chaque rupture de stock, chaque modification. Si chaque changement compte individuellement, les pages qui changent rapidement ont besoin de plus de visites, pas de moins, et la bonne réponse peut être une source entièrement différente, comme une API, un flux ou une page de listing qui montre le changement sans récupération complète. Décidez quel problème vous résolvez avant d’ajuster.
Évaluer chaque visite par valeur attendue rapportée au coût
En assemblant ces éléments, chaque visite candidate reçoit une priorité : combien la page compte, multiplié par la fraîcheur qu’une visite achèterait, divisé par le coût de la visite.
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.costL’ordonnanceur travaille alors à partir d’une file de priorité : à chaque cycle, dépenser le budget sur les visites les mieux notées, puis s’arrêter. Trois entrées méritent une attention particulière.
- La valeur est un jugement métier, pas technique. Un produit qui se vend, un concurrent qui compte, une requête que vos clients exécutent. Restez grossier ; trois ou quatre niveaux suffisent généralement.
- Le coût doit être le coût réel de cette visite : octets pour ce type de page, crédits, et si un rendu est nécessaire. Une page nécessitant un navigateur headless sur un plan facturé à la bande passante peut coûter plusieurs fois plus qu’une récupération simple.
- Le taux de changement provient de votre historique, mis à jour après chaque visite.
Des signaux bon marché avant des récupérations coûteuses
Souvent, vous pouvez apprendre si une page a changé pour bien moins cher que le prix de sa récupération.
- Requêtes conditionnelles. Là où un site honore
ETagouLast-Modified, une réponse304 Not Modifiedcoûte une fraction des octets. Suivez par hôte si les validateurs sont fiables ; certains sites les envoient mais les ignorent. - Les pages de listing comme détecteurs de changement. Une page de catégorie ou de recherche affiche souvent le prix et la disponibilité de dizaines d’articles. Récupérez le listing, comparez, et ne récupérez que les articles dont le résumé a changé. C’est ainsi que la plupart des flux de prix en temps réel et des moniteurs de stock restent abordables.
- Sitemaps et flux. Lorsqu’ils portent des dates de modification fiables, ils vous indiquent ce qui a changé sans avoir à visiter quoi que ce soit d’autre.
- Points d’accès structurés. Une réponse JSON derrière une page est généralement plus petite et plus stable que la page elle-même.
Réserver du budget pour ce que l’ordonnanceur ne peut pas voir
Un ordonnanceur qui optimise uniquement les pages connues finira par devenir aveugle peu à peu. Réservez une partie de chaque cycle pour trois choses :
- La découverte. Les nouvelles URL n’ont pas d’historique et ne surpasseraient jamais les pages établies. Donnez-leur leur propre allocation.
- La ré-estimation. Une page notée comme immuable pendant des mois devrait tout de même être visitée occasionnellement, car les pages changent de comportement. Sans cela, une estimation erronée n’est jamais corrigée.
- La vérification. Un petit échantillon aléatoire, récupéré indépendamment du score, vous indique si les hypothèses du modèle tiennent toujours.
Laisser le coût et l’état de santé influencer l’ordonnancement
Le calendrier est un plan, pas une garantie. Quand un site commence à limiter le débit, l’ordonnanceur devrait en être informé et reclasser en conséquence, plutôt que de continuer à mettre en file des visites que l’étape de récupération ne peut pas effectuer. Ce chemin de retour, des fetchers vers la frontière, est traité dans contre-pression et contrôle de flux dans les crawlers distribués, et l’état général d’un site dans construire un score de santé de cible. Un score de santé en baisse devrait également augmenter le coût effectif de la visite de ce site, ce qui est exactement le signal dont un ordonnanceur sensible au coût a besoin.
L’essentiel à retenir
Un budget de crawl dépensé uniformément, ou proportionnellement à l’activité de chaque page, sert surtout à confirmer que rien ne s’est passé. Estimez la fréquence de changement de chaque page à partir de votre propre historique, évaluez chaque visite selon ce qu’elle apportera et ce qu’elle coûtera, et allouez le budget en priorité aux meilleurs achats. Attendez-vous à ce que ce soient les pages qui changent au rythme que vous pouvez vous permettre de suivre, et non celles qui changent le plus vite.
Le bénéfice n’est pas seulement une facture plus légère. Un crawler qui récupère moins, et récupère avec plus de soin, est aussi plus léger pour les sites dont il dépend.
Sources et références
- Junghoo Cho et Hector Garcia-Molina, Effective Page Refresh Policies for Web Crawlers, ACM Transactions on Database Systems, Vol. 28, No. 4, décembre 2003.
- Shifter, Residential Proxies bandwidth and billing. Ce qui compte comme trafic.
- Shifter, Web Scraping API errors and limits. Coûts en crédits, comportement en cas d’échec et nouvelles tentatives.