Lesezeit
Eine Seite kann bei den Aufrufen ganz oben stehen und innerhalb von drei Sekunden verlassen werden. Die Lesezeit ist die Kennzahl, die die beiden unterscheidet – und es ist die Kennzahl, die die meisten Analysetools falsch berechnen, auf eine Weise, die unsichtbar bleibt, bis man sich die Rohzahlen ansieht.
Was Sie erhalten#
Jede Seite Ihrer Dokumentation weist eine durchschnittliche Lesezeit auf, und die Karten „Seiten“ und
„Überschriften“ können danach sortiert werden. Eine Seite ohne Messwerte zeigt einen Gedankenstrich,
niemals 0 — eine Null würde so wirken, als wäre „niemand geblieben“, obwohl tatsächlich „nichts
gemessen wurde“.
Die Lesezeit wird pro Seite, nicht pro Besuch gezählt: Ein Leser, der drei Seiten öffnet, trägt für jede davon ihre eigenen Sekunden bei, anstatt alle drei so geschäftig erscheinen zu lassen wie die geschäftigste Seite.
Das Lesen dieses Berichts belastet das Guthaben Ihres Projekts nicht und ist in jedem Tarif verfügbar.
Wie es aufgebaut ist#
Ein Segment, keine Stoppuhr. Der Tracker startet eine Uhr, wenn eine Seite geöffnet wird, und
liest sie aus, wenn der Leser sie verlässt — bei pagehide, bei der Navigation innerhalb der Website zu
einer anderen Seite und bei visibilitychange → hidden unter iOS, wo pagehide unzuverlässig ist. Jede
Auslesung erzeugt ein docs.read_time-Ereignis, das diese Anzahl Sekunden enthält, und setzt die Uhr
zurück. Ein Leser, der den Tab ausblendet und zurückkehrt, erzeugt daher zwei Segmente statt eines
doppelt gezählten Zeitraums.
Segmente unter 3 Sekunden werden niemals übermittelt. Darunter ist ein Leser nur hindurchgegangen; die Aufzeichnung würde den Mittelwert einer Seite verrauschen, ohne eine Messung hinzuzufügen.
Die Übermittlung erfolgt per Beacon. Lesezeit, Überschriftenansichten und Verlassensereignisse werden über
navigator.sendBeacon an einen Endpunkt desselben Ursprungs gesendet, gebündelt mit bis zu 100 Ereignissen
pro Beacon, da der gewöhnliche Protokollierungstransport über fetch zwei Sekunden lang
entprellt wird und das Schließen eines Tabs nicht überlebt. Jeder Collector ist idempotent: Er gibt nur die
Ereignisse zurück, die er noch nicht gesendet hat, sodass ein iOS-Flush im ausgeblendeten Zustand gefolgt
von einem tatsächlichen Verlassen nicht doppelt gezählt wird und eine aus dem Back-/Forward-Cache
wiederhergestellte Seite erneut flushen kann.
Jedes Segment wird auf 300 Sekunden begrenzt, bevor irgendetwas es summiert. Darauf stützt sich der gesamte Bericht. Der Emitter zählt weiter, während ein Desktop-Tab im Hintergrund geöffnet ist, und bei einem Kalibrierungsdurchlauf von 11,176 echten Sitzungen in 7 Arbeitsbereichen überschritten 40 einzelne Segmente zwei Stunden, das 99. Perzentil lag bei 81,342 Sekunden — 22 Stunden — und die Summierung roher Segmente erhöhte die gesamte Lesezeit von tatsächlich 42,160 Sekunden auf 1,268,422, also ungefähr um das Dreißigfache.
Die Begrenzung wird einmalig in einem einzigen Modul ohne Importe definiert und für alles erneut exportiert, was eine Zeitangabe zitiert — den Durchschnitt pro Seite, die Besuchszusammenfassung, die Spalte „Verweildauer“ der Chat-Tabelle, die Zielebene und die MCP-Tools. Eine zweite, großzügigere Definition von „Verweildauer“ eine Spalte neben der ersten ist genau der Grund, warum zwei Zahlen über denselben Leser voneinander abzuweichen beginnen.
Der Durchschnitt wird durch die Anzahl der Segmente geteilt, nicht durch die Anzahl der Besuche. Ein Leser, der den Tab verlässt und zurückkehrt, trägt zwei Segmente zu einem Besuch bei; eine Mittelung nach Besuchen würde diesem Besuch doppelte Bedeutung geben.
Bots werden durch denselben User-Agent-Filter ausgeschlossen, den der übrige Teil des Dashboards verwendet, sodass sich die Lesezeit einer Seite mit ihrer Ansichtsanzahl deckt. Die verhaltensbasierte Crawler-Sperre — ein Besuch ohne ein von JavaScript erzeugtes Ereignis ist unabhängig von den Angaben seines User-Agents ein Crawler — erfordert eine vollständige Rekonstruktion der Sitzung und wird stattdessen in der Besuchsebene angewendet; siehe So funktioniert die Messung.
Was Ihnen die Lesezeit einer Seite sagt#
Lesezeit ist ein Vergleich, kein Urteil: Sie sagt im Verhältnis zur Länge der Seite und zu ihrer Aufgabe etwas aus.
| Merkmal | Wahrscheinliche Interpretation | Maßnahme |
|---|---|---|
| Kurze Lesezeit auf einer komplexen Seite | Unklar, zu lang oder schlecht strukturiert | Vor einer Überarbeitung neu strukturieren |
| Lange Lesezeit auf einer kurzen Seite | Leser lesen erneut, statt die Seite zu genießen | Den Absatz klären, bei dem sie festhängen |
| Konstante Lesezeit in einem Tutorial | Leser kommen wie vorgesehen voran | Nichts |
| Viele Aufrufe, Lesezeit nahe null | Die Seite gewinnt den Klick und verliert den Leser | Ihr Einstieg passt nicht zu der Frage, die sie hergeführt hat |
Kombinieren Sie sie mit den Aufrufen der Überschriften: Die Lesezeit zeigt, wie lange sie geblieben sind, die Aufrufe der Überschriften zeigen, wie weit sie nach unten gekommen sind. Eine lange Lesezeit, die sich auf die ersten beiden Überschriften konzentriert, bedeutet, dass ein Leser feststeckt, nicht dass er engagiert ist.
Warum dies der richtige Weg ist#
| Regel | Warum sie funktioniert | Quelle |
|---|---|---|
Ereignisse zum Verlassen der Seite müssen über Beacon gesendet werden, nicht über einen verzögerten fetch |
Beacon-Anfragen „werden garantiert vor dem Entladen der Seite gestartet und dürfen vollständig ausgeführt werden“ | W3C Beacon API |
Auf pagehide lauschen und zusätzlich auf Änderungen der Sichtbarkeit reagieren |
unload „ist weiterhin unzuverlässig, vermeiden Sie daher seine Verwendung, sofern sie nicht unbedingt erforderlich ist“; pagehide „wird in allen Fällen ausgelöst, in denen das Ereignis unload ausgelöst wird“, und zusätzlich beim Eintritt in den bfcache |
web.dev: bfcache |
| Eine Seite, die auch im Hintergrund weiterzählt, misst das Falsche | Die Page Visibility API existiert, weil Entwickler „Webseiten so gestaltet haben, als wären sie immer sichtbar“ | W3C Page Visibility Level 2 |
| Das Ziel der bewährten Praxis ist die Zeit im Vordergrund | GA4 definiert Nutzerinteraktion als „die Zeit, die jemand mit Ihrer fokussierten Webseite verbringt“ | GA4: Nutzerinteraktion |
| Eine Messung pro Seite ist besser als eine aus der Sitzung abgeleitete | Universal Analytics berechnete eine Sitzung ohne Interaktions-Treffer auf der letzten Seite als „Der Zeitpunkt des ersten Treffers auf der letzten Seite – der erste Treffer auf der ersten Seite“ — die letzte Seite, auf der der Leser seine Sitzung beendet hat, trägt nichts dazu bei | Universal Analytics: Sitzungsdauer |
| Ein Gedankenstrich ist besser als eine Null | Ein verlässliches 0 auf einer nicht gemessenen Seite ist nicht von einem gemessenen Abbruch zu unterscheiden, und nur einer dieser Fälle lässt sich beheben |
Mechanismus, diese Seite |
Diese letzte Zeile ist der gesamte Grund dafür, dass Docsbook ein eigenes Ereignis zum Verlassen der Seite ausgibt, anstatt die Zeit aus der Lücke zwischen Seitenaufrufen abzuleiten. Die letzte Seite eines Besuchs — die Seite, bei der der Leser aufgehört hat und die normalerweise diejenige ist, die Sie am dringendsten bewerten möchten — ist genau die Seite, die eine lückenbasierte Messung nicht erfassen kann.
Grenzen und offene Fragen#
- Die Lesezeit wird begrenzt, nicht an die Sichtbarkeit gekoppelt. Auf dem Desktop sammelt ein Hintergrund-Tab weiterhin Sekunden, bis die Begrenzung von 300 Sekunden greift. Der Fehler weist daher in eine bekannte Richtung (nach oben) und hat eine bekannte Obergrenze (300 Sekunden pro Segment), weshalb der Wert verwendbar ist — aber er ist nicht dieselbe Messung wie eine an den Fokus gekoppelte Interaktionszeit, und diese Seite behauptet auch nicht, dass dies der Fall ist. Wenn Ihre Leser Dokumentationen gewohnheitsmäßig in einem Hintergrund-Tab geöffnet lassen, betrachten Sie den Wert als Obergrenze.
- Eine Seite, die länger als fünf Minuten am Stück geöffnet ist, wird als fünf Minuten erfasst. Bei einem langen Tutorial, das ein Leser tatsächlich durcharbeitet, führt dies zu einer Unterschätzung. Die Begrenzung nimmt bei seltenen langen Lesevorgängen eine begrenzte Unterschätzung zugunsten einer dreißigfachen Überschätzung bei inaktiven Tabs in Kauf.
- Ungeklärt: „durchschnittliche Lesezeit“ ist nicht „durchschnittliche Aufmerksamkeit“. Verifizierbar ist der oben beschriebene Mechanismus — Segmente, der Mindestwert, die Begrenzung, der Divisor. Nicht aus diesen Daten verifizierbar ist, ob der Leser auf den Bildschirm geschaut hat. Kein Webanalyseprodukt kann das messen, und keines sollte dies suggerieren.
- Leser mit deaktiviertem JavaScript und Crawler tragen überhaupt keine Lesezeit bei. Ihre Seitenaufrufe werden dennoch gezählt, sodass eine stark gecrawlte Seite eine hohe Aufrufzahl im Verhältnis zu einer kleinen Lesezeit-Stichprobe aufweisen kann.
- Dreißig Tage bilden die gesamte Historie. Es gibt keinen langfristigen Trend der Lesezeit, den man ableiten könnte.
So öffnen Sie den Bericht zur Lesezeit#
- Öffnen Sie Ihre Dokumentationsseite.
- Float Widget → Registerkarte Analysen.
- Sortieren Sie die Karte Seiten oder Überschriften nach
Reading time.
Reading time ist nur für Seiten und Überschriften verfügbar. Es hat eine Bedeutung für eine Zeile, die einen Ort in Ihrer Dokumentation bezeichnet, und keine für eine Zeile, die ein Land oder einen Browser bezeichnet. Daher ist es dort und nirgendwo sonst verfügbar.
Verwandte Inhalte#
- Wie die Messung funktioniert — der Clip, der Beacon-Pfad und die Bot-Filter im Detail
- Analytics-Übersicht — die Seiten-Karte, in der dieses Ranking zu finden ist
- Referenz zu erfassten Ereignissen — Überschriftenansichten, die zeigen, wie weit Leser auf einer langen Seite nach unten gelangen
- Ziele und Trichter — messen, was der Besuch erreicht hat, nicht nur, wie lange er gedauert hat