Temps de lecture
Une page peut attirer des visiteurs et être abandonnée en trois secondes. Le temps de lecture est l’indicateur qui distingue les deux — et c’est l’indicateur que la plupart des outils d’analyse calculent mal, d’une manière qui reste invisible jusqu’à ce que vous examiniez les chiffres bruts.
Ce que vous obtenez#
Chaque page de votre documentation indique un temps de lecture moyen, et les cartes Pages et
Titres peuvent être classées selon celui-ci. Une page sans mesure affiche un tiret,
jamais 0 — un zéro donnerait l'impression que « personne n'est resté » alors que la réalité est que « rien n'a été
mesuré ».
Le temps de lecture est comptabilisé par page, et non par visite : un lecteur qui ouvre trois pages attribue à chacune ses propres secondes, plutôt que de donner aux trois l'apparence d'être aussi consultées que la plus consultée.
La lecture de ce rapport ne coûte rien sur le solde de votre projet, et il est disponible avec tous les forfaits.
Comment cela est construit#
Un segment, pas un chronomètre. Le tracker démarre une horloge lorsqu’une page s’ouvre et
la lit lorsque le lecteur la quitte — sur pagehide, lors d’une navigation interne vers
une autre page, et sur visibilitychange → hidden sur iOS, où pagehide est
peu fiable. Chaque lecture émet un événement docs.read_time transportant cette durée
en secondes, puis réinitialise l’horloge. Un lecteur qui masque l’onglet et revient
produit donc deux segments plutôt qu’une seule durée comptée deux fois.
Les segments de moins de 3 secondes ne sont jamais émis. En dessous de ce seuil, le lecteur est simplement passé par là ; l’enregistrer ajouterait du bruit à la moyenne d’une page sans ajouter de lecture.
La transmission se fait par beacon. Le temps de lecture, les consultations de titres et les sorties passent par
navigator.sendBeacon vers un point de terminaison de même origine, regroupés par lots de 100 événements
maximum par beacon, car le transport de journalisation ordinaire applique une temporisation de deux secondes
sur fetch et ne survit pas à la fermeture d’un onglet. Chaque collecteur est idempotent : il
ne renvoie que les événements qui n’ont pas encore été envoyés, de sorte qu’un envoi lors du masquage sur iOS suivi
d’une véritable sortie ne compte pas deux fois, et qu’une page restaurée depuis le cache retour/avance puisse effectuer un nouvel envoi.
Chaque segment est plafonné à 300 secondes avant toute addition. C’est le nombre sur lequel repose l’ensemble du rapport. L’émetteur continue de compter lorsqu’un onglet de bureau reste en arrière-plan et, lors d’un balayage de calibration portant sur 11,176 sessions réelles réparties sur 7 espaces de travail : 40 segments individuels dépassaient deux heures, le 99e percentile était de 81,342 secondes — 22 heures — et l’addition des segments bruts a fait passer le temps de lecture total de 42,160 secondes à 1,268,422, soit environ trente fois plus.
Le plafonnement est défini une seule fois, dans un module sans importations, puis réexporté vers tout ce qui cite une durée — la moyenne par page, le résumé de la visite, la colonne « temps passé sur le site » du tableau de discussion, la couche des objectifs et les outils MCP. Une seconde définition, plus généreuse, du « temps passé sur le site », située à une colonne de la première, explique exactement comment deux nombres concernant le même lecteur commencent à diverger.
La moyenne est divisée par le nombre de segments, et non par le nombre de visites. Un lecteur qui passe à un autre onglet puis revient contribue deux segments à une seule visite ; faire la moyenne par visite attribuerait deux fois le poids à cette visite.
Les robots sont exclus par le même filtre User-Agent que celui utilisé par le reste du tableau de bord, afin que le temps de lecture d’une page corresponde à son nombre de vues. Le filtrage des robots comportementaux — une visite sans événement émis par JavaScript est considérée comme provenant d’un robot, quelles que soient les déclarations de son User-Agent — nécessite une reconstruction complète de la session et est appliqué dans la couche des visites ; voir Comment fonctionne la mesure.
Ce que le temps de lecture d’une page vous apprend#
Le temps de lecture est une comparaison, pas un verdict : il ne prend son sens qu’en fonction de la longueur de la page et du rôle qu’elle joue.
| Situation | Lecture probable | Action |
|---|---|---|
| Temps de lecture faible sur une page complexe | Peu claire, trop longue ou mal structurée | Restructurer avant de réécrire |
| Temps de lecture élevé sur une page courte | Les lecteurs relisent, ils n’apprécient pas leur lecture | Clarifier le paragraphe sur lequel ils bloquent |
| Temps de lecture constant dans un tutoriel | Les lecteurs progressent comme prévu | Rien |
| Beaucoup de vues, temps de lecture presque nul | La page obtient le clic, mais perd le lecteur | Son introduction ne correspond pas à la question qui les a amenés ici |
Associez-le aux vues des titres : le temps de lecture indique combien de temps ils sont restés, les vues des titres indiquent jusqu’où ils sont descendus. Un temps de lecture long concentré sur les deux premiers titres indique qu’un lecteur est bloqué, pas qu’il est captivé.
Pourquoi cette méthode est la bonne#
| Règle | Pourquoi cela fonctionne | Source |
|---|---|---|
Les événements au moment de la sortie doivent passer par beacon, et non par un fetch avec temporisation |
Les requêtes beacon « sont garanties d’être lancées avant le déchargement de la page et sont autorisées à s’exécuter jusqu’à leur terme » | API Beacon du W3C |
Écouter sur pagehide, et en plus lors d’un changement de visibilité |
unload « reste peu fiable, évitez donc de l’utiliser sauf en cas d’absolue nécessité » ; pagehide « se déclenche dans tous les cas où l’événement unload se déclenche », ainsi que lors de l’entrée dans le bfcache |
web.dev : bfcache |
| Une page qui continue à compter lorsqu’elle est masquée mesure la mauvaise chose | L’API Page Visibility existe parce que les développeurs « concevaient les pages web comme si elles étaient toujours visibles » | Page Visibility niveau 2 du W3C |
| L’objectif recommandé est le temps passé au premier plan | GA4 définit l’engagement de l’utilisateur comme « la durée pendant laquelle une personne consulte votre page web au premier plan » | GA4 : engagement de l’utilisateur |
| Une mesure par page est préférable à une mesure dérivée de la session | Universal Analytics calculait une session sans interactions d’engagement sur la dernière page comme suit : « l’heure de la première interaction sur la dernière page - la première interaction sur la première page » — la dernière page, celle que le lecteur a choisi de quitter, ne contribue à rien | Universal Analytics : durée de la session |
| Un tiret vaut mieux qu’un zéro | Un 0 présenté comme certain sur une page non mesurée est impossible à distinguer d’un abandon mesuré, et un seul des deux permet d’agir |
Mécanisme, cette page |
Cette dernière ligne est la raison même pour laquelle Docsbook émet son propre événement de sortie au lieu d’inférer le temps à partir de l’écart entre les pages vues. La dernière page d’une visite — celle sur laquelle le lecteur s’est arrêté, et qui est généralement celle que vous souhaitez le plus évaluer — est précisément la page qu’une mesure fondée sur l’écart ne peut pas voir.
Limites et questions en suspens#
- Le temps de lecture est tronqué, et non conditionné par la visibilité. Sur ordinateur, un onglet en arrière-plan continue d’accumuler les secondes jusqu’à ce que le tronquage à 300 secondes l’arrête. L’erreur a donc une direction connue (vers le haut) et une limite connue (300 secondes par segment), ce qui explique pourquoi cette mesure est exploitable — mais ce n’est pas la même mesure qu’un temps d’engagement conditionné par le focus, et cette page ne prétend pas le contraire. Si vos lecteurs laissent habituellement la documentation ouverte dans un onglet en arrière-plan, considérez cette valeur comme une limite supérieure.
- Une page ouverte pendant plus de cinq minutes d’affilée est enregistrée comme cinq minutes. Pour un long tutoriel qu’un lecteur parcourt réellement, cela sous-estime la durée. Le tronquage privilégie une sous-estimation limitée pour les lectures longues rares, plutôt qu’une surestimation multipliée par trente pour les onglets inactifs.
- Point en suspens : le « temps de lecture moyen » n’est pas l’« attention moyenne ». Ce qui est vérifiable, c’est le mécanisme décrit ci-dessus — les segments, le seuil minimal, le tronquage, le diviseur. Ce qui n’est pas vérifiable à partir de ces données, c’est de savoir si le lecteur regardait l’écran. Aucun produit d’analyse web ne peut mesurer cela, et aucun ne devrait le laisser entendre.
- Les lecteurs dont JavaScript est désactivé, ainsi que les robots d’exploration, ne contribuent absolument pas au temps de lecture. Leurs pages vues sont tout de même comptabilisées, de sorte qu’une page fortement explorée peut afficher un nombre élevé de vues associé à un échantillon de temps de lecture limité.
- Trente jours constituent l’intégralité de l’historique. Il n’est pas possible d’en tirer une tendance du temps de lecture à long terme.
Comment ouvrir le rapport sur le temps de lecture#
- Ouvrez votre site de documentation.
- Float Widget → onglet Analyses.
- Classez la carte Pages ou Titres par
Reading time.
Reading time est proposé uniquement pour les pages et les titres. Cela signifie quelque chose pour une
ligne qui désigne un emplacement dans votre documentation, et rien pour une ligne qui désigne un
pays ou un navigateur ; il est donc proposé ici et nulle part ailleurs.
Associés#
- Fonctionnement de la mesure — le clip, le chemin du beacon et les filtres anti-robots en détail
- Vue d’ensemble des analyses — la carte Pages où se trouve ce classement
- Référence des événements suivis — les vues des titres, qui indiquent jusqu’où les lecteurs descendent dans une longue page
- Objectifs et entonnoirs — mesurer ce que la visite a permis d’accomplir, et pas seulement sa durée