C'est une croyance qui circule depuis des années, surtout chez les développeurs : Google arrêterait de rendre une page au bout de 5 secondes, et tout ce qui arrive après serait perdu. Dave Smart, consultant SEO technique chez Tame the Bots, a monté une série de tests pour vérifier. Verdict : la limite n'existe pas, mais il comprend très bien pourquoi tout le monde y croit.
- Il n'existe pas de limite fixe de 5 secondes dans le Web Rendering Service (WRS) de Google
- Le WRS utilise une horloge virtuelle qu'il peut accélérer, ralentir ou geler : les temps mesurés en JavaScript ne reflètent pas la réalité
- Le rendu s'arrête quand la boucle d'événements devient inactive, pas quand un chronomètre expire
- Sur une page qui ne s'arrête jamais, la coupure observée tourne autour de 30 secondes en indexation réelle
D'où vient le chiffre de 5 secondes
Le test est facile à reproduire, et c'est bien le problème. Dave Smart a créé une page avec un simple setInterval qui incrémente un compteur toutes les secondes et écrit le résultat dans la balise title. Passée dans l'outil d'inspection d'URL de la Search Console, la page rendue affiche un compteur arrêté à 5 secondes.
Conclusion logique en apparence : le WRS coupe à 5 secondes. Sauf que la page contenait aussi deux appels fetch vers un script serveur qui temporise volontairement entre 3 et 6 secondes chacun. Soit 6 à 12 secondes cumulées, largement au-dessus de la fameuse limite. Et pourtant les deux réponses sont bien arrivées dans le DOM rendu.
Le WRS ne mesure pas le temps comme ton navigateur
Petit rappel sur la mécanique : quand Google rend une page, Googlebot récupère le HTML, puis le passe au WRS, qui est au fond une instance de Chrome headless. Contrairement à un navigateur classique, ce n'est pas Chrome qui va chercher les CSS et les JS : c'est l'infrastructure de crawl qui les récupère et les lui repasse. Cette plomberie explique déjà pourquoi les temps observés n'ont rien à voir avec ceux d'un vrai navigateur.
Mais la vraie clé, c'est l'horloge. Le WRS n'utilise pas l'horloge matérielle de la machine. Il tourne sur une horloge virtuelle que Google contrôle entièrement. Il peut donc accélérer le temps, le ralentir, ou carrément le geler pendant qu'une requête réseau est en cours.
Le détail le plus parlant du test : le script mesure le temps total des deux appels API et affiche 0,02 seconde. Ce n'est pas une erreur. Les 9 secondes réelles d'attente serveur ont été gelées côté horloge virtuelle, et seul le temps de traitement et d'insertion dans le DOM a été compté.
Autrement dit, le compteur bloqué à 5 secondes ne mesure pas la patience de Google, il mesure une horloge que Google manipule. Toute mesure de durée faite en JavaScript depuis l'intérieur du WRS est donc à jeter.
À noter aussi : lors d'une indexation réelle (et non d'un test en direct), l'horloge du WRS démarre systématiquement à minuit UTC. Un timestamp injecté dans la page par du JavaScript au moment du rendu affichera donc minuit, quelle que soit l'heure réelle du passage de Google.
Le rendu s'arrête sur l'inactivité, pas sur un chrono
Google doit bien décider à un moment que la page est prête à être indexée. Ce déclencheur n'est pas une durée, c'est l'observation de la boucle d'événements : quand plus rien ne tourne, que la file d'attente est vide et que la page est au repos, le rendu est considéré comme terminé. C'est exactement ce que Martin Splitt explique dans ses interventions sur le sujet.
C'est une différence de nature, pas de degré. Une page qui met 8 secondes à charger ses données mais qui se stabilise ensuite sera rendue entièrement. Une page qui garde en permanence un appel en vol ne sera jamais considérée comme au repos.
Il y a quand même une limite, mais elle est loin
Le WRS ne peut évidemment pas rendre à l'infini. Pour trouver le plafond, Dave Smart a créé une page qui relance sans arrêt un appel serveur temporisé à 3 secondes. Les résultats :
- Outil de test en direct : coupure après 16 à 18 appels, soit 48 à 54 secondes
- Indexation réelle : coupure après 10 appels, soit environ 30 secondes
Ces valeurs sont variables d'un passage à l'autre, ce ne sont pas des seuils à graver dans le marbre. Mais l'ordre de grandeur est clair : la patience du WRS se compte en dizaines de secondes, pas en unités. Et de toute façon, aucun utilisateur réel n'attendra 30 secondes devant une page blanche, donc le vrai sujet reste la performance perçue, pas la peur du couperet de Google.
- Arrête de conclure quoi que ce soit d'un compteur JavaScript observé dans le DOM rendu : l'horloge est virtuelle
- Raisonne en boucle d'événements qui se vide, pas en budget de X secondes
- Traque les polling permanents, websockets et autres appels sans fin qui empêchent la page d'être au repos
Source : Tamethebots.com
Cet article a été rédigé avec l’assistance d’un modèle de langage (LLM).
