Une page web n'existe pas de la même manière pour un lecteur et pour un robot d'indexation. Cette séance propose de rendre cet écart observable, en instrumentant une page réelle plutôt qu'en s'en remettant à ce que la documentation officielle veut bien en dire.
Quand on publie une page, on suppose implicitement que le moteur de recherche la lira comme nous. C'est faux, et cette erreur coûte cher. Entre le moment où Google télécharge le code HTML et celui où il décide ce que la page contient réellement, il se passe une étape que presque personne n'observe directement : le rendu. Le moteur exécute le JavaScript, applique les feuilles de style, attend certaines ressources, en abandonne d'autres, puis fige un état de la page. C'est cet état-là, et pas le fichier que vous avez écrit, qui sert de base à l'indexation.
La difficulté, c'est que cette étape est presque entièrement opaque. Google en publie une description volontairement vague. Les outils de diagnostic officiels montrent un résultat, jamais le chemin qui y mène. Résultat : le métier fonctionne largement à partir de croyances transmises entre praticiens, dont certaines sont fausses depuis des années mais continuent de circuler parce que personne ne prend le temps de les vérifier.
La plus tenace de ces croyances est celle d'une limite de cinq secondes. On lit partout que Google accorde cinq secondes à une page pour se charger, après quoi il coupe. Cette affirmation est reprise dans des formations, des audits facturés, des cahiers des charges techniques. Elle a pourtant été contredite par plusieurs séries d'expériences publiques, qui montrent des pages rendues complètement bien au-delà de ce seuil.
La première hypothèse, la plus intéressante, tient en une phrase : le moteur de rendu ne vit pas dans le même temps que nous. Plutôt que d'attendre réellement, il manipulerait une horloge virtuelle. Le temps se figerait pendant que le processeur travaille, et s'accélérerait pendant les attentes réseau. Un délai de trente secondes demandé en JavaScript pourrait ainsi se déclencher presque immédiatement du point de vue de la machine, parce que l'horloge aurait simplement été avancée. Si c'est exact, mesurer « combien de temps Google attend » n'a aucun sens tant qu'on n'a pas précisé de quelle horloge on parle.
La seconde hypothèse est plus sobre : il n'existe pas de durée fixe du tout. Le moteur observerait la file d'attente des tâches du navigateur et déciderait que la page est terminée quand plus rien ne s'y exécute. La limite ne serait donc pas temporelle mais comportementale — une page qui continue de s'agiter serait suivie plus longtemps qu'une page qui se stabilise vite, jusqu'à un plafond de sécurité.
Ces deux hypothèses ne s'excluent pas. Elles se testent, et c'est précisément l'objet de la séance.
La page que vous lisez se mesure elle-même. Elle enregistre trois familles de traces.
La première compare systématiquement deux horloges. Côté navigateur, le code note l'heure qu'il croit être. Côté serveur, chaque signal reçu est horodaté à son arrivée. En rapprochant les deux, on obtient le rapport entre le temps vécu par le moteur de rendu et le temps réellement écoulé. Si ce rapport s'écarte de un, l'hypothèse de l'horloge virtuelle devient difficile à écarter.
La deuxième famille de traces s'intéresse à la géométrie. Le moteur de rendu ne regarde pas la page à travers une fenêtre de taille ordinaire : pour déclencher le chargement différé des images, il utiliserait une fenêtre d'une hauteur considérable, et la redimensionnerait en cours de route. Des sondes invisibles sont donc réparties sur toute la hauteur du document, de cinq cents à deux millions de pixels. Chacune ne se déclenche que si le moteur descend jusqu'à elle. La plus profonde atteinte donne une mesure directe de la hauteur réelle de la fenêtre de rendu — un chiffre que personne ne publie.
La troisième famille teste les limites. Une série de minuteurs s'échelonne de zéro à deux minutes ; une chaîne de requêtes réseau enchaîne des latences imposées par le serveur ; des calculs de charge connue occupent le processeur pendant des durées mesurables. Le point où les traces s'interrompent indique où le rendu s'est arrêté, et surtout pourquoi : par épuisement du temps, par inactivité, ou par abandon des requêtes en cours.
Le travail ne consiste pas à lancer le dispositif — il tourne seul. Il consiste à lire ce qu'il produit sans lui faire dire plus qu'il ne dit. Vous disposerez du journal complet des mesures, robot par robot, visite par visite.
Cette dernière possibilité est la plus importante. Une mesure ne tranche pas toujours, et un compte rendu qui sait dire « les données ne permettent pas de conclure » vaut mieux qu'un compte rendu qui affirme. C'est aussi la posture qu'on attend de vous face à un client : distinguer ce que vous avez mesuré de ce que vous avez supposé.
Un dernier point mérite d'être posé d'emblée. Nous observons un système que nous ne contrôlons pas, qui évolue sans préavis, et dont le comportement peut différer selon le site, le moment ou le type de robot. Les résultats d'aujourd'hui décrivent ce qui s'est produit aujourd'hui, sur cette page. Les généraliser demanderait de répéter l'expérience ailleurs, plusieurs fois, et d'accepter que la réponse change. C'est une contrainte ordinaire dès qu'on observe une boîte noire, et il vaut mieux l'assumer que la masquer.
L'image ci-dessous mesure exactement 8 000 pixels de haut et porte une graduation tous les 500 pixels. Contrairement aux sondes invisibles réparties plus bas dans le document, il s'agit ici de contenu réellement peint. Sur une capture d'écran du rendu, le dernier nombre lisible indique directement jusqu'où le moteur est descendu.