Besserer Messwert für die Reaktionszeit

Hier erfahren Sie, was wir von der Messung der Reaktionsschnelligkeit halten, und können Sie uns gern Feedback geben.

Das Chrome-Team für Geschwindigkeitsmetriken arbeitet daran, unser Verständnis dafür zu vertiefen, wie schnell Webseiten auf Nutzereingaben reagieren. Hier möchten wir einige Ideen zur Verbesserung der Messwerte für die Reaktionszeit mit Ihnen teilen und uns Ihr Feedback dazu anhören.

In diesem Beitrag werden zwei Hauptthemen behandelt:

1. Sehen Sie sich unseren aktuellen Messwert für die Reaktionsfähigkeit, First Input Delay (FID) an, und erklären Sie, warum wir uns anstelle einiger Alternativen für FID entschieden haben.
2. Präsentiere einige Verbesserungen, die wir in Betracht gezogen haben und die die End-to-End-Latenz einzelner Ereignisse besser erfassen sollten. Mit diesen Verbesserungen soll außerdem ein ganzheitlicheres Bild der Reaktionsfähigkeit einer Seite während ihrer Lebensdauer insgesamt erfasst werden.

Was ist First Input Delay?

Der Messwert First Input Delay (FID) misst, wie lange der Browser braucht, um mit der Verarbeitung der ersten Nutzerinteraktion auf einer Seite zu beginnen. Insbesondere wird der Unterschied zwischen dem Zeitpunkt gemessen, zu dem der Nutzer mit dem Gerät interagiert, und dem Zeitpunkt, zu dem der Browser tatsächlich mit der Verarbeitung von Event-Handlern beginnen kann. Die FID wird nur für das Antippen und Drücken von Tasten gemessen. Es wird also nur das allererste Auftreten der folgenden Ereignisse berücksichtigt:

• click
• keydown
• mousedown
• pointerdown (nur, wenn pointerup folgt)

Das folgende Diagramm veranschaulicht FID:

FID enthält weder die Zeit, die für die Ausführung dieser Event-Handler aufgewendet wurde, noch Änderungen, die der Browser danach zur Aktualisierung des Bildschirms ausführt. Sie misst, wie lange der Hauptthread ausgelastet war, bevor er eine Eingabe verarbeiten konnte. Diese Blockierzeit wird in der Regel durch lange JavaScript-Aufgaben verursacht, da diese nicht einfach jederzeit angehalten werden können. Daher muss die aktuelle Aufgabe abgeschlossen sein, bevor der Browser mit der Verarbeitung der Eingabe beginnen kann.

Warum haben wir uns für FID entschieden?

Wir glauben, dass es wichtig ist, die tatsächliche Nutzererfahrung zu messen, um sicherzustellen, dass Verbesserungen des Messwerts einen echten Nutzen für die Nutzer haben. Wir haben uns für die Messung von FID entschieden, weil sie den Teil der User Experience darstellt, wenn der Nutzer sich entscheidet, mit einer gerade geladenen Website zu interagieren. FID erfasst, wie lange ein Nutzer warten muss, bis er eine Antwort auf eine Interaktion mit einer Website sieht. Mit anderen Worten, FID ist eine Untergrenze für die Zeit, die ein Nutzer nach der Interaktion wartet.

Andere Messwerte wie Total Blocking Time (TBT) und Time To Interactive (TTI) basieren auf langen Aufgaben und messen wie FID auch die Blockierzeit des Hauptthreads während des Ladevorgangs. Da diese Messwerte sowohl in der Praxis als auch im Labor gemessen werden können, fragen viele Entwickler, warum wir keines davon gegenüber FID bevorzugen.

Dafür gibt es verschiedene Gründe. Der vielleicht wichtigste Grund ist, dass diese Messwerte die Nutzererfahrung nicht direkt messen. Mit diesen Messwerten wird gemessen, wie viel JavaScript auf der Seite ausgeführt wird. Während JavaScript mit langer Ausführungszeit auf Websites häufig Probleme verursacht, wirken sich diese Aufgaben nicht unbedingt auf die Nutzererfahrung aus, wenn sie nicht mit der Seite interagieren. Eine Seite kann bei TBT und TTI einen hohen Wert haben, sich aber langsam anfühlen, oder sie kann einen schlechten Wert haben, während sie sich für die Nutzer schnell fühlt. Unserer Erfahrung nach führen diese indirekten Messungen zu Messwerten, die für einige Websites gut funktionieren, für die meisten jedoch nicht. Kurz gesagt: Die Tatsache, dass lange Aufgaben und TTI nicht benutzerorientiert sind, macht diese schwächeren Kandidaten aus.

Die Lab-Messung ist sicherlich wichtig und ein wertvolles Tool für die Diagnose. Entscheidend ist jedoch, wie Nutzer Websites verwenden. Wenn Sie einen nutzerorientierten Messwert haben, der reale Nutzerbedingungen widerspiegelt, erfassen Sie garantiert aussagekräftige Informationen. Wir haben uns entschieden, mit einem kleinen Teil dieser Erfahrung zu beginnen, auch wenn wir wissen, dass dieser Teil nicht repräsentativ für die gesamte Erfahrung ist. Aus diesem Grund arbeiten wir daran, einen größeren Teil der Zeit zu erfassen, die ein Nutzer auf die Verarbeitung seiner Eingaben wartet.

Welche Verbesserungen planen wir?

Wir möchten einen neuen Messwert entwickeln, der das bisher von FID gemessene Verfahren erweitert und dennoch eine enge Verbindung zur Nutzererfahrung beibehält.

Der neue Messwert soll:

1. Berücksichtigen Sie, wie responsiv alle Nutzereingaben (nicht nur die erste) sind.
2. Erfassen Sie die gesamte Dauer jedes Ereignisses (nicht nur die Verzögerung).
3. Gruppieren Sie Ereignisse, die im Rahmen derselben logischen Nutzerinteraktion auftreten, und definieren Sie die Latenz dieser Interaktion als maximale Dauer aller zugehörigen Ereignisse.
4. Erstellen Sie eine Gesamtpunktzahl für alle Interaktionen, die während des gesamten Lebenszyklus auf einer Seite auftreten.

Um erfolgreich zu sein, sollten wir mit hoher Sicherheit behaupten können, dass eine Website nicht schnell auf Nutzerinteraktionen reagiert, wenn das Ergebnis mit dem neuen Messwert schlecht ist.

Die gesamte Dauer des Ereignisses erfassen

Die erste offensichtliche Verbesserung besteht darin, die breitere End-to-End-Latenz eines Ereignisses zu erfassen. Wie oben erwähnt, erfasst FID nur den Verzögerungsteil des Eingabeereignisses. Die Zeit, die der Browser zur Verarbeitung der Event-Handler benötigt, wird nicht berücksichtigt.

Der Lebenszyklus eines Ereignisses besteht aus verschiedenen Phasen, wie in diesem Diagramm dargestellt:

So verarbeitet Chrome eine Eingabe:

1. Die Eingabe der Nutzenden erfolgt. Der Zeitpunkt ist der timeStamp des Ereignisses.
2. Der Browser führt Treffertests durch, um zu entscheiden, zu welchem HTML-Frame (Hauptframe oder iFrame) ein Ereignis gehört. Anschließend sendet der Browser das Ereignis an den entsprechenden Renderer-Prozess, der für diesen HTML-Frame zuständig ist.
3. Der Renderer empfängt das Ereignis und stellt es in die Warteschlange, damit es verarbeitet werden kann, sobald es verfügbar ist.
4. Der Renderer verarbeitet das Ereignis, indem er seine Handler ausführt. Diese Handler können zusätzliche asynchrone Arbeit wie setTimeout und Abrufe in die Warteschlange stellen, die Teil der Eingabeverarbeitung sind. Aber an diesem Punkt ist die synchrone Arbeit abgeschlossen.
5. Auf dem Bildschirm wird ein Frame angezeigt, der das Ergebnis der ausgeführten Event-Handler widerspiegelt. Asynchrone Aufgaben, die von den Event-Handlern in die Warteschlange gestellt wurden, können noch nicht abgeschlossen sein.

Die Zeit zwischen den Schritten (1) und (3) oben ist eine Verzögerung, die von FID gemessen wird.

Die Zeit zwischen den Schritten (1) und (5) oben ist die Dauer eines Ereignisses. Das wird mit dem neuen Messwert gemessen.

Die Dauer des Ereignisses beinhaltet die Verzögerung, aber auch die Arbeit in Event-Handlern sowie die Arbeit, die der Browser ausführen muss, um den nächsten Frame zu zeichnen, nachdem diese Handler ausgeführt wurden. Die Dauer eines Ereignisses ist derzeit in der Event Timing API über das Attribut duration des Eintrags verfügbar.

Ereignisse in Interaktionen gruppieren

Die Ausweitung der Messwertmessung von Verzögerung auf Dauer ist ein guter erster Schritt. Im Messwert bleibt jedoch eine kritische Lücke: Er konzentriert sich auf einzelne Ereignisse und nicht auf die Nutzererfahrung bei der Interaktion mit der Seite.

Viele verschiedene Ereignisse können als Ergebnis einer einzelnen Nutzerinteraktion ausgelöst werden und eine separate Messung jedes Ereignisses liefert kein klares Bild davon, was der Nutzer sieht. Unser Messwert soll die gesamte Zeit erfassen, die ein Nutzer beim Antippen, Drücken von Tasten, Scrollen und Ziehen so genau wie möglich auf eine Antwort warten muss. Deshalb führen wir das Konzept der Interaktionen ein, mit dem die Latenz der jeweiligen Interaktionen gemessen wird.

Interaktionstyp

In der folgenden Tabelle sind die vier Interaktionen aufgeführt, die definiert werden sollen, sowie die zugehörigen DOM-Ereignisse. Beachten Sie, dass dies nicht ganz dasselbe ist wie die Gruppe aller Ereignisse, die ausgelöst werden, wenn eine solche Nutzerinteraktion eintritt. Wenn ein Nutzer beispielsweise scrollt, wird ein Scroll-Ereignis ausgelöst, aber nachdem der Bildschirm aktualisiert wurde, um das Scrollen widerzuspiegeln. Daher betrachten wir dies nicht als Teil der Interaktionslatenz.

Die ersten drei oben aufgeführten Interaktionen (Tastatur, Tippen und Ziehen) sind derzeit von FID abgedeckt. In unseren neuen Messwert für die Reaktionsfähigkeit soll auch das Scrollen einbezogen werden, da das Scrollen im Web sehr verbreitet ist und ein entscheidender Aspekt dafür ist, wie responsiv eine Seite für Nutzer anfühlt.

Tastatur

Eine Tastaturinteraktion besteht aus zwei Teilen: wenn der Nutzer die Taste drückt und wenn er sie loslässt. Mit dieser Nutzerinteraktion sind drei Ereignisse verknüpft: keydown, keyup und keypress. Das folgende Diagramm zeigt die Verzögerungen und Dauer von keydown und keyup für eine Tastaturinteraktion:

Im obigen Diagramm ist die Dauer getrennt, da der Frame aus keydown-Aktualisierungen vor dem keyup-Vorgang vorhanden ist. Das muss jedoch nicht immer der Fall sein. Beachten Sie außerdem, dass ein Frame in der Mitte einer Aufgabe im Renderer-Prozess dargestellt werden kann, da die letzten für die Frame-Erstellung erforderlichen Schritte außerhalb des Renderer-Prozesses ausgeführt werden.

keydown und keypress treten auf, wenn der Nutzer die Taste drückt. keyup wird ausgelöst, wenn der Nutzer die Taste loslässt. Im Allgemeinen erfolgt die Aktualisierung des Hauptinhalts, wenn die Taste gedrückt wird: Text erscheint auf dem Bildschirm oder der Modifikatoreffekt wird angewendet. Wir möchten jedoch auch die selteneren Fälle erfassen, in denen keyup auch interessante Aktualisierungen der Benutzeroberfläche bieten würde. Daher möchten wir uns die Gesamtdauer ansehen.

Um die Gesamtzeit der Tastaturinteraktion zu erfassen, können wir die maximale Dauer der keydown- und keyup-Ereignisse berechnen.

Tap

Eine weitere wichtige Interaktion ist das Tippen oder Klicken auf eine Website. Ähnlich wie bei keypress werden einige Ereignisse ausgelöst, wenn der Nutzer nach unten drückt, andere werden beim Loslassen ausgelöst (siehe Abbildung oben). Die mit einem Tippen verbundenen Ereignisse unterscheiden sich auf Computern und Mobilgeräten leicht.

Beim Tippen oder Klicken löst der Release die meisten Reaktionen aus. Allerdings soll wie bei Tastaturinteraktionen die gesamte Interaktion erfasst werden. In diesem Fall ist das wichtiger, weil einige UI-Aktualisierungen beim Drücken des Tippens nicht so ungewöhnlich sind.

Wir möchten die Ereignisdauer für alle diese Ereignisse einbeziehen, aber da sich viele davon vollständig überschneiden, müssen Sie nur pointerdown, pointerup und click messen, um die gesamte Interaktion abzudecken.

Strömungswiderstand

Wir haben uns dafür entschieden, auch das Ziehen einzubeziehen, da es ähnliche Ereignisse hat und im Allgemeinen wichtige UI-Aktualisierungen von Websites verursacht. Für unsere Metrik wollen wir jedoch nur den Anfang und das Ende des Ziehens berücksichtigen, d. h. den Anfangs- und den letzten Teil des Drag. Dies erleichtert die Begründung und sorgt dafür, dass die Latenzen mit den anderen berücksichtigten Interaktionen vergleichbar sind. Dies entspricht unserer Entscheidung, kontinuierliche Ereignisse wie mouseover auszuschließen.

Auch über die Drag & Drop API implementierte Drag-and-drops sind nicht in Betracht gezogen, da sie nur auf dem Desktop funktionieren.

Scrollen

Eine der häufigsten Formen der Interaktion mit einer Website ist das Scrollen. Für unseren neuen Messwert möchten wir die Latenz für die erste Scroll-Interaktion des Nutzers messen. Uns ist vor allem die anfängliche Reaktion des Browsers auf die Tatsache wichtig, dass der Nutzer ein Scrollen angefordert hat. Wir werden nicht das gesamte Scrollen abdecken. Beim Scrollen entstehen also viele Frames und wir konzentrieren uns auf den ersten Frame, der als Reaktion auf das Scrollen entsteht.

Warum gerade die erste? Zum einen können nachfolgende Frames von einem separaten Angebot für die Glättung erfasst werden. Sobald dem Nutzer das erste Ergebnis des Scrollens gezeigt wurde, sollten die übrigen Ergebnisse daran gemessen werden, wie reibungslos sich das Scrollen anfühlt. Deshalb gehen wir davon aus, dass sich dies durch eine reibungslose Vorgehensweise besser erfassen ließe. Wie bei FID entscheiden wir uns für eigenständige User Experiences, d. h. solche mit klaren Zeitpunkten, für die sich die Latenz einfach berechnen lässt. Das Scrollen als Ganzes ist ein fortlaufendes Erlebnis, daher haben wir nicht die Absicht, alles in diesem Messwert zu messen.

Warum sollten Sie Scrollvorgänge messen? Die von uns in Chrome erfasste Scrollleistung zeigt, dass das Scrollen im Allgemeinen sehr schnell ist. Dennoch möchten wir aus verschiedenen Gründen die anfänglichen Scrolllatenzen in unseren neuen Messwert aufnehmen. Erstens: Das Scrollen ist nur deshalb schnell, weil es so stark optimiert wurde, weil es so wichtig ist. Es gibt jedoch immer noch Möglichkeiten für eine Website, einige der Leistungssteigerungen des Browsers zu umgehen. Die häufigste Methode in Chrome besteht darin, das Scrollen im Hauptthread zu erzwingen. Unsere Metrik sollte also in der Lage sein zu sagen, wann dies geschieht, und verschlechtert die Scrollleistung für Benutzer. Zweitens ist das Scrollen einfach zu wichtig, um es zu ignorieren. Wir befürchten, dass wir einen großen Schwachpunkt haben, wenn wir das Scrollen ausschließen, und die Scrollleistung könnte mit der Zeit abnehmen, ohne dass Webentwickler das richtig bemerken.

Wenn ein Nutzer scrollt, werden verschiedene Ereignisse ausgelöst, z. B. touchstart, touchmove und scroll. Mit Ausnahme des Scroll-Ereignisses hängt dies vor allem vom Gerät ab, das für das Scrollen verwendet wird: Touch-Ereignisse werden auf Mobilgeräten beim Scrollen mit dem Finger ausgelöst, während Rad-Ereignisse beim Scrollen mit einem Mausrad ausgelöst werden. Die Scroll-Ereignisse werden ausgelöst, nachdem das erste Scrollen abgeschlossen ist. Und im Allgemeinen blockiert kein DOM-Ereignis das Scrollen, es sei denn, die Website verwendet nicht passive Ereignis-Listener. Das Scrollen ist also vollständig von DOM-Ereignissen entkoppelt. Was wir messen wollen, ist die Zeit von einer Bewegung des Nutzers bis zum ersten Frame, der das Scrollen anzeigt.

Wie wird die Latenz einer Interaktion definiert?

Wie bereits erwähnt, müssen Interaktionen mit den Komponenten „nach unten“ und „nach oben“ separat betrachtet werden, damit nicht die Zeit zugeordnet werden kann, in der der Nutzer seinen Finger gedrückt hält.

Bei dieser Art von Interaktionen soll die Latenz die Dauer aller mit ihnen verbundenen Ereignisse umfassen. Da sich die Ereignisdauer für jeden „down“- und „up“-Teil der Interaktion überlappen kann, ist die einfachste Definition der Interaktionslatenz, mit der dies erreicht wird, die maximale Dauer eines mit ihr verbundenen Ereignisses. In Bezug auf das Tastaturdiagramm von vorhin wäre dies die keydown-Dauer, da sie länger als keyup ist:

Die Zeiträume für keydown und keyup können sich ebenfalls überschneiden. Dies kann beispielsweise der Fall sein, wenn der Frame, der für beide Ereignisse dargestellt wird, identisch ist, wie im folgenden Diagramm dargestellt:

Dieser Ansatz, das Maximum zu nutzen, hat Vor- und Nachteile. Wir würden gerne Ihr Feedback hören:

• Pro: Sie entspricht unserer geplanten Scroll-Messung, da nur ein einzelner Dauerwert gemessen wird.
• Pro: Die Funktion zielt darauf ab, Geräusche wie Tastaturinteraktionen zu reduzieren, bei denen der keyup normalerweise nichts tut und bei denen der Nutzer die Taste schnell oder langsam drücken und loslassen kann.
• Nachteil: Es wird nicht die volle Wartezeit des Nutzers erfasst. So wird zum Beispiel der Anfang oder das Ende eines Drag-Vorgangs erfasst, nicht beides.

Beim Scrollen (dem nur ein einziges Ereignis zugeordnet ist) möchten wir die Latenz als die Zeit definieren, die der Browser benötigt, um den ersten Frame nach dem Scrollen zu erzeugen. Das heißt, die Latenz ist das Delta zwischen dem Ereignis timeStamp des ersten DOM-Ereignisses (z. B. touchmove bei Verwendung eines Fingers), das groß genug ist, um ein Scrollen auszulösen, und dem First Paint, der das Scrolling widerspiegelt.

Alle Interaktionen pro Seite aggregieren

Nachdem wir die Latenz einer Interaktion definiert haben, müssen wir einen Gesamtwert für einen Seitenaufbau berechnen, bei dem viele Nutzerinteraktionen auftreten können. Mit einem aggregierten Wert haben wir folgende Möglichkeiten:

• Korrelationen mit Geschäftsmesswerten bilden.
• Korrelationen mit anderen Leistungsmesswerten auswerten Im Idealfall ist unser neuer Messwert ausreichend unabhängig davon, dass er den vorhandenen Messwerten einen Mehrwert bietet.
• Stellen Sie Werte in Tools auf einfache Weise zur Verfügung.

Um diese Aggregation durchzuführen, müssen wir zwei Fragen beantworten:

1. Welche Zahlen versuchen wir zu aggregieren?
2. Wie werden diese Zahlen aggregiert?

Wir prüfen und evaluieren mehrere Optionen. Wir freuen uns über Ihr Feedback zu dieser Zusammenfassung.

Eine Möglichkeit besteht darin, ein Budget für die Latenz einer Interaktion festzulegen, das vom Typ (Scrollen, Tastatur, Tippen oder Ziehen) abhängen kann. Wenn das Budget für das Antippen beispielsweise 100 ms beträgt und die Latenz einer Transaktion 150 ms beträgt, würde der Betrag über das Budget für diese Interaktion 50 ms betragen. Dann könnten wir die maximale Latenz berechnen, die das Budget für jede Nutzerinteraktion auf der Seite überschreitet.

Eine weitere Option besteht darin, die durchschnittliche oder mittlere Latenz der Interaktionen während der Lebensdauer der Seite zu berechnen. Bei Latenzen von 80 ms, 90 ms und 100 ms läge die durchschnittliche Latenz für die Seite bei 90 ms. Wir könnten auch den durchschnittlichen oder mittleren Wert für „über dem Budget“ berücksichtigen, um je nach Art der Interaktion unterschiedliche Erwartungen zu berücksichtigen.

Wie sieht das bei Web Performance APIs aus?

Was fehlt beim Timing der Veranstaltung?

Leider können nicht alle in diesem Beitrag präsentierten Ideen mithilfe der Event Timing API umgesetzt werden. Insbesondere gibt es keine einfache Möglichkeit, die Ereignisse zu ermitteln, die einer bestimmten Nutzerinteraktion mit der API zugeordnet sind. Dazu haben wir vorgeschlagen, der API ein interactionID hinzuzufügen.

Ein weiterer Nachteil der Event Timing API besteht darin, dass es keine Möglichkeit gibt, die Scroll-Interaktion zu messen. Wir arbeiten daher daran, diese Messungen zu aktivieren (über Event Timing oder eine separate API).

Was kannst du jetzt ausprobieren?

Derzeit ist es immer noch möglich, die maximale Latenz für Tipp- und Ziehbewegungen sowie für Tastaturinteraktionen zu berechnen. Mit dem folgenden Code-Snippet werden diese beiden Messwerte generiert.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

Feedback

Teile uns deine Meinung zu diesen Ideen per E-Mail mit: web-vitals-feedback@googlegroups.com!