RAIL ist ein nutzerorientiertes Leistungsmodell, das eine Struktur für die Betrachtung der Leistung bietet. Das Modell unterteilt die Nutzererfahrung in wichtige Aktionen (z. B. Tippen, Scrollen, Laden) und hilft Ihnen, Leistungsziele für jede dieser Aktionen zu definieren.
RAIL steht für vier verschiedene Aspekte des Lebenszyklus von Web-Apps: Response (Antwort), Animation, Idle (Inaktivität) und Load (Laden). Nutzer haben für jeden dieser Kontexte unterschiedliche Leistungserwartungen. Daher werden Leistungsziele basierend auf dem Kontext und der UX-Recherche dazu, wie Nutzer Verzögerungen wahrnehmen, definiert.
Optimale Suchergebnisse für Nutzer
Stellen Sie die Nutzer in den Mittelpunkt Ihrer Leistungsoptimierung. In der folgenden Tabelle werden wichtige Messwerte dazu beschrieben, wie Nutzer Leistungsverzögerungen wahrnehmen:
Wahrnehmung von Leistungsverzögerungen durch Nutzer| 0 bis 16 ms | Nutzer sind außergewöhnlich gut darin, Bewegungen zu verfolgen, und sie mögen es nicht, wenn Animationen nicht flüssig sind. Animationen werden als flüssig wahrgenommen, solange jede Sekunde 60 neue Frames gerendert werden. Das sind 16 ms pro Frame, einschließlich der Zeit, die der Browser benötigt, um den neuen Frame auf dem Bildschirm darzustellen. Einer App bleiben also etwa 10 ms, um einen Frame zu erzeugen. |
| 0 bis 100 ms | Wenn Sie innerhalb dieses Zeitfensters auf Nutzeraktionen reagieren, haben Nutzer das Gefühl, dass das Ergebnis sofort eintritt. Wenn es länger dauert, geht die Verbindung zwischen Aktion und Reaktion verloren. |
| 100 bis 1.000 ms | In diesem Fenster fühlen sich die Dinge wie ein natürlicher und kontinuierlicher Fortschritt von Aufgaben an. Für die meisten Nutzer im Web ist das Laden von Seiten oder das Ändern von Ansichten eine Aufgabe. |
| 1.000 ms oder mehr | Nach mehr als 1.000 Millisekunden (1 Sekunde) verlieren Nutzer den Fokus auf die Aufgabe, die sie gerade ausführen. |
| 10.000 ms oder mehr | Nach mehr als 10.000 Millisekunden (10 Sekunden) sind Nutzer frustriert und brechen Aufgaben wahrscheinlich ab. Es kann sein, dass sie später wiederkommen, aber das ist nicht sicher. |
Ziele und Richtlinien
Im Kontext von RAIL haben die Begriffe Ziele und Richtlinien eine bestimmte Bedeutung:
Ziele: Wichtige Leistungsmesswerte im Zusammenhang mit der Nutzererfahrung. Beispielsweise können Sie tippen, um in weniger als 100 Millisekunden zu malen. Da die menschliche Wahrnehmung relativ konstant ist, werden sich diese Ziele in absehbarer Zeit wahrscheinlich nicht ändern.
Richtlinien. Empfehlungen, die Ihnen helfen, Ihre Ziele zu erreichen. Diese können sich auf die aktuelle Hardware und die Netzwerkverbindung beziehen und sich daher im Laufe der Zeit ändern.
Antwort: Ereignisse in weniger als 50 ms verarbeiten
Ziel: Einen Übergang, der durch eine Nutzereingabe initiiert wurde, innerhalb von 100 ms abschließen, damit Nutzer das Gefühl haben, dass die Interaktionen sofort erfolgen.
Richtlinien:
Damit innerhalb von 100 ms eine sichtbare Reaktion erfolgt, sollten Nutzereingabeereignisse innerhalb von 50 ms verarbeitet werden. Das gilt für die meisten Eingaben, z. B. das Klicken auf Schaltflächen, das Umschalten von Formularsteuerelementen oder das Starten von Animationen. Dies gilt nicht für Zieh- oder Scrollbewegungen.
Auch wenn es unlogisch klingen mag, ist es nicht immer die richtige Entscheidung, sofort auf Nutzereingaben zu reagieren. Sie können dieses 100-ms-Fenster für andere aufwendige Aufgaben nutzen, aber achten Sie darauf, den Nutzer nicht zu blockieren. Führen Sie nach Möglichkeit Arbeiten im Hintergrund aus.
Gib bei Aktionen, die länger als 50 ms dauern, immer Feedback.
50 ms oder 100 ms?
Das Ziel ist es, auf Eingaben in weniger als 100 ms zu reagieren. Warum beträgt unser Budget also nur 50 ms? Das liegt daran, dass neben der Eingabeverarbeitung in der Regel auch andere Aufgaben ausgeführt werden, die einen Teil der Zeit in Anspruch nehmen, die für eine akzeptable Eingabeantwort zur Verfügung steht. Wenn eine Anwendung während der Leerlaufzeit Aufgaben in den empfohlenen 50-ms-Blöcken ausführt, bedeutet das, dass Eingaben bis zu 50 ms lang in die Warteschlange gestellt werden können, wenn sie während eines dieser Arbeitsblöcke erfolgen. Wenn wir das berücksichtigen, können wir davon ausgehen, dass nur die verbleibenden 50 ms für die eigentliche Eingabeverarbeitung verfügbar sind. Dieser Effekt wird im folgenden Diagramm veranschaulicht. Es zeigt, wie Eingaben, die während einer inaktiven Aufgabe empfangen werden, in die Warteschlange gestellt werden, wodurch sich die verfügbare Verarbeitungszeit verringert:
Animation: Frame in 10 ms erstellen
Ziele:
Jeder Frame einer Animation muss in maximal 10 ms erstellt werden. Technisch gesehen beträgt das maximale Budget für jeden Frame 16 ms (1.000 ms / 60 Bilder pro Sekunde ≈ 16 ms). Browser benötigen jedoch etwa 6 ms, um jeden Frame zu rendern. Daher gilt die Richtlinie von 10 ms pro Frame.
Achten Sie auf eine flüssige Darstellung. Nutzer bemerken, wenn die Framerate variiert.
Richtlinien:
Bei kritischen Punkten wie Animationen ist es wichtig, nichts zu tun, wo es möglich ist, und das absolute Minimum, wo es nicht möglich ist. Nutze nach Möglichkeit die 100-ms-Antwort, um rechenintensive Aufgaben vorab zu berechnen, damit du die Wahrscheinlichkeit maximierst, 60 fps zu erreichen.
Unter Rendering-Leistung finden Sie verschiedene Strategien zur Optimierung von Animationen.
- Visuelle Animationen wie Ein- und Ausblendungen, Tweens und Ladeanzeigen.
- Scrollen. Dazu gehört auch das sogenannte „Flinging“, bei dem der Nutzer mit dem Scrollen beginnt, dann loslässt und die Seite weiter scrollt.
- Ziehen. Animationen folgen oft Nutzerinteraktionen, z. B. dem Schwenken einer Karte oder dem Zoomen durch Auseinander- und Zusammenziehen der Finger.
Inaktiv: Maximale Inaktivitätszeit
Ziel: Die Leerlaufzeit maximieren, um die Wahrscheinlichkeit zu erhöhen, dass die Seite innerhalb von 50 ms auf Nutzereingaben reagiert.
Richtlinien:
Nutzen Sie die Leerlaufzeit, um aufgeschobene Arbeiten zu erledigen. Laden Sie beispielsweise für den ersten Seitenaufbau so wenig Daten wie möglich und verwenden Sie dann die Inaktivitätszeit, um den Rest zu laden.
Führen Sie Arbeiten während der Inaktivität in maximal 50 ms aus. Wenn es länger dauert, besteht die Gefahr, dass die App nicht mehr innerhalb von 50 ms auf Nutzereingaben reagieren kann.
Wenn ein Nutzer während der Ausführung von Aufgaben im Leerlauf mit einer Seite interagiert, sollte die Nutzerinteraktion immer die höchste Priorität haben und die Aufgaben im Leerlauf unterbrechen.
Laden: Inhalte bereitstellen und in weniger als 5 Sekunden interaktiv werden
Wenn der Seitenaufbau langsam ist, lässt die Aufmerksamkeit der Nutzer nach und sie nehmen die Aufgabe als fehlerhaft wahr. Websites, die schnell geladen werden, haben längere durchschnittliche Sitzungen, niedrigere Absprungraten und eine höhere Sichtbarkeit von Anzeigen.
Ziele:
Optimieren Sie die Ladeleistung im Hinblick auf die Geräte- und Netzwerkfunktionen Ihrer Nutzer. Derzeit ist ein gutes Ziel für das erste Laden, dass die Seite auf Mittelklasse-Mobilgeräten mit langsamen 3G-Verbindungen in höchstens 5 Sekunden geladen und interaktiv ist.
Bei nachfolgenden Ladevorgängen sollte die Seite in weniger als 2 Sekunden geladen werden.
Richtlinien:
Testen Sie die Ladeleistung auf den Mobilgeräten und Netzwerkverbindungen, die bei Ihren Nutzern üblich sind. Im Chrome User Experience Report finden Sie Informationen zur Verbindungsverteilung Ihrer Nutzer. Wenn die Daten für deine Website nicht verfügbar sind, wird in The Mobile Economy 2019 ein Mittelklasse-Android-Smartphone wie ein Moto G4 und ein langsames 3G-Netzwerk (definiert als 400 ms RTT und 400 Kbit/s Übertragungsgeschwindigkeit) als gute globale Baseline empfohlen. Diese Kombination ist auf WebPageTest verfügbar.
Beachte, dass das Gerät eines typischen mobilen Nutzers zwar angeben kann, dass es eine 2G-, 3G- oder 4G-Verbindung hat, die effektive Verbindungsgeschwindigkeit jedoch aufgrund von Paketverlusten und Netzwerkabweichungen oft deutlich langsamer ist.
Sie müssen nicht alles in weniger als 5 Sekunden laden, um den Eindruck eines vollständigen Ladevorgangs zu erwecken. Sie können Lazy Loading für Bilder, Code-Splitting für JavaScript-Bundles und andere auf web.dev vorgeschlagene Optimierungen in Betracht ziehen.
Tools zum Messen von RAIL
Es gibt einige Tools, mit denen Sie Ihre RAIL-Messungen automatisieren können. Welche Sie verwenden, hängt davon ab, welche Art von Informationen Sie benötigen und welchen Workflow Sie bevorzugen.
Chrome-Entwicklertools
Die Chrome-Entwicklertools bieten eine detaillierte Analyse aller Vorgänge, die beim Seitenaufbau oder Ausführen einer Seite stattfinden. Unter Erste Schritte mit der Analyse der Laufzeitleistung finden Sie Informationen zur Benutzeroberfläche des Bereichs Leistung.
Die folgenden DevTools-Funktionen sind besonders relevant:
Drosseln Sie die CPU, um ein weniger leistungsstarkes Gerät zu simulieren.
Drosseln Sie das Netzwerk, um langsamere Verbindungen zu simulieren.
Aktivität des Hauptthreads ansehen, um alle Ereignisse zu sehen, die während der Aufzeichnung im Hauptthread aufgetreten sind.
Aktivitäten im Hauptthread in einer Tabelle anzeigen, um Aktivitäten danach zu sortieren, welche am meisten Zeit in Anspruch genommen haben.
Analysieren Sie die Bilder pro Sekunde (fps), um zu messen, ob Ihre Animationen wirklich flüssig laufen.
Überwachen Sie die CPU-Auslastung, die JS-Heap-Größe, die DOM-Knoten, die Layouts pro Sekunde und mehr in Echtzeit mit dem Leistungsmonitor.
Visualisieren Sie Netzwerkanfragen, die während der Aufzeichnung im Bereich Netzwerk aufgetreten sind.
Screenshots während der Aufzeichnung erstellen, um genau wiederzugeben, wie die Seite beim Seitenaufbau oder beim Auslösen einer Animation aussah.
Interaktionen ansehen, um schnell zu erkennen, was auf einer Seite passiert ist, nachdem ein Nutzer mit ihr interagiert hat.
Leistungsprobleme beim Scrollen in Echtzeit finden, indem die Seite hervorgehoben wird, wenn ein potenziell problematischer Listener ausgelöst wird.
Paint-Ereignisse in Echtzeit ansehen, um kostspielige Paint-Ereignisse zu identifizieren, die die Leistung Ihrer Animationen beeinträchtigen könnten.
Leuchtturm
Lighthouse ist in den Chrome-Entwicklertools, in PageSpeed Insights, als Chrome-Erweiterung, als Node.js-Modul und in WebPageTest verfügbar. Sie geben eine URL ein, es wird ein Mittelklassegerät mit einer langsamen 3G-Verbindung simuliert, eine Reihe von Prüfungen auf der Seite durchgeführt und dann ein Bericht zur Ladeleistung sowie Vorschläge zur Verbesserung erstellt.
Die folgenden Prüfungen sind besonders relevant:
Antwort
Maximales potenzielles First Input Delay. Schätzt anhand der Leerlaufzeit des Hauptthreads, wie lange es dauert, bis Ihre App auf Nutzereingaben reagiert.
Verwendet keine passiven Listener, um die Scrollleistung zu verbessern.
Total Blocking Time: Gibt an, wie lange eine Seite nicht auf Nutzereingaben wie Mausklicks, Berührungen des Bildschirms oder Tastatureingaben reagiert.
Time to Interactive: Misst, wann ein Nutzer mit allen Seitenelementen interagieren kann.
Laden
Registriert keinen Service Worker, der die Seite und die start_url steuert. Ein Service Worker kann gängige Ressourcen auf dem Gerät eines Nutzers im Cache speichern, sodass weniger Zeit für das Abrufen von Ressourcen über das Netzwerk aufgewendet werden muss.
Der Seitenaufbau in Mobilfunknetzen ist nicht schnell genug.
Bilder, die nicht auf dem Bildschirm zu sehen sind, zurückstellen Das Laden von nicht sichtbaren Bildern sollte verzögert werden, bis sie benötigt werden.
Bilder richtig dimensionieren: Stelle keine Bilder bereit, die deutlich größer sind als die im mobilen Darstellungsbereich gerenderte Größe.
Zu großes DOM vermeiden. Reduziere die Netzwerkbytes, indem du nur DOM-Knoten sendest, die zum Rendern der Seite erforderlich sind.
WebPageTest
WebPageTest ist ein Tool zur Messung der Webleistung, das echte Browser verwendet, um auf Webseiten zuzugreifen und Zeitmesswerte zu erfassen. Geben Sie unter webpagetest.org/easy eine URL ein, um einen Detailbericht zur Ladeleistung der Seite auf einem echten Moto G4-Gerät mit einer langsamen 3G-Verbindung zu erhalten. Sie können es auch so konfigurieren, dass eine Lighthouse-Prüfung enthalten ist.
Zusammenfassung
RAIL ist ein Modell, mit dem die User Experience einer Website als eine Abfolge von verschiedenen Interaktionen betrachtet wird. Sie können nachvollziehen, wie Nutzer Ihre Website wahrnehmen, und Leistungsziele festlegen, die sich am stärksten auf die Nutzerfreundlichkeit auswirken.
Optimale Suchergebnisse für Nutzer
Reagieren Sie auf Nutzereingaben in weniger als 100 ms.
Beim Animieren oder Scrollen sollte ein Frame in weniger als 10 ms erstellt werden.
Maximieren Sie die Leerlaufzeit des Hauptthreads.
Interaktive Inhalte werden in weniger als 5.000 ms geladen.