RAIL ist ein nutzerorientiertes Leistungsmodell, das eine Struktur für die Leistungsanalyse bietet. Das Modell unterteilt die Nutzererfahrung in wichtige Aktionen (z. B. tippen, scrollen, laden) und hilft Ihnen, Leistungsziele für jede Aktion zu definieren.
RAIL steht für vier verschiedene Aspekte des Lebenszyklus von Web-Apps: Response, Animation, Idle und Load. Nutzer haben in den einzelnen Kontexten unterschiedliche Leistungserwartungen. Daher werden Leistungsziele basierend auf dem Kontext und UX-Studien dazu, wie Nutzer Verzögerungen wahrnehmen, definiert.
Optimale Suchergebnisse für Nutzer
Stellen Sie die Nutzer in den Mittelpunkt Ihrer Leistungsbemühungen. In der folgenden Tabelle werden die wichtigsten Messwerte beschrieben, die Aufschluss darüber geben, wie Nutzer Leistungsverzögerungen wahrnehmen:
Wahrnehmung von Leistungsverzögerungen durch Nutzer| 0 bis 16 ms | Nutzer sind sehr gut darin, Bewegungen zu verfolgen, und sie mögen es nicht, wenn Animationen nicht flüssig sind. Animationen werden als flüssig wahrgenommen, solange 60 neue Frames pro Sekunde 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. Eine App hat also etwa 10 ms Zeit, um einen Frame zu erstellen. |
| 0 bis 100 ms | Wenn Sie innerhalb dieses Zeitfensters auf Nutzeraktionen reagieren, haben Nutzer das Gefühl, dass das Ergebnis sofort angezeigt wird. Andernfalls geht die Verbindung zwischen Aktion und Reaktion verloren. |
| 100 bis 1.000 ms | Innerhalb dieses Zeitrahmens fühlen sich die Aufgaben als Teil eines natürlichen und kontinuierlichen Ablaufs 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 1.000 Millisekunden (1 Sekunde) verlieren Nutzer den Fokus auf die Aufgabe, die sie gerade ausführen. |
| 10.000 ms oder mehr | Nach 10.000 Millisekunden (10 Sekunden) sind Nutzer frustriert und brechen Aufgaben wahrscheinlich ab. Es ist möglich, dass sie später wiederkommen. |
Ziele und Richtlinien
Im Kontext von RAIL haben die Begriffe Ziele und Richtlinien eine bestimmte Bedeutung:
Ziele: Wichtige Leistungsmesswerte in Bezug auf die Nutzerfreundlichkeit. Sie können beispielsweise tippen, um in weniger als 100 Millisekunden zu malen. Da die menschliche Wahrnehmung relativ konstant ist, werden sich diese Ziele wahrscheinlich nicht so schnell ä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: Eine durch Nutzereingabe initiierte Übergangsanimation innerhalb von 100 ms abschließen, damit Nutzer den Eindruck haben, dass die Interaktionen sofort erfolgen.
Richtlinien:
Damit die Reaktion innerhalb von 100 ms sichtbar ist, müssen Nutzer-Eingabeereignisse 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. Das gilt nicht für Touch-Drag- oder Scroll-Vorgänge.
Auch wenn es kontraintuitiv klingen mag, ist es nicht immer die richtige Entscheidung, sofort auf Nutzereingaben zu reagieren. Sie können dieses 100-ms-Zeitfenster für andere aufwendige Aufgaben nutzen, sollten aber darauf achten, den Nutzer nicht zu blockieren. Wenn möglich, sollten Sie im Hintergrund arbeiten.
Bei Aktionen, die länger als 50 ms dauern, sollte immer Feedback gegeben werden.
50 ms oder 100 ms?
Das Ziel ist es, in weniger als 100 ms auf Eingaben zu reagieren. Warum beträgt unser Budget also nur 50 ms? Das liegt daran, dass in der Regel neben der Eingabebehandlung auch andere Aufgaben ausgeführt werden, die einen Teil der für eine akzeptable Eingabeantwort verfügbaren Zeit in Anspruch nehmen. Wenn eine Anwendung während der Leerlaufzeit in den empfohlenen 50-ms-Blöcken arbeitet, kann die Eingabe bis zu 50 ms lang in die Warteschlange gestellt werden, wenn sie während eines dieser Arbeitsblöcke erfolgt. Da dies berücksichtigt wird, kann davon ausgegangen werden, dass nur die verbleibenden 50 ms für die eigentliche Eingabebehandlung zur Verfügung stehen. Dieser Effekt wird im folgenden Diagramm veranschaulicht. Es zeigt, wie Eingaben, die während einer Leerlaufaufgabe empfangen werden, in die Warteschlange gestellt werden, wodurch die verfügbare Verarbeitungszeit reduziert wird:
Animation: einen Frame in 10 ms erstellen
Ziele:
Jeder Frame einer Animation muss in maximal 10 ms gerendert werden. Technisch gesehen beträgt das maximale Budget für jeden Frame 16 ms (1.000 ms / 60 Frames 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 Framerates variieren.
Richtlinien:
Bei Stellen, an denen der Druck hoch ist, wie z. B. bei Animationen, gilt es, so wenig wie möglich zu tun. Nutzen Sie nach Möglichkeit die 100-ms-Reaktion, um rechenintensive Vorgänge vorzuberechnen und so die Wahrscheinlichkeit zu maximieren, dass 60 fps erreicht werden.
Informationen zu verschiedenen Strategien zur Optimierung von Animationen finden Sie unter Rendering-Leistung.
- Visuelle Animationen wie Ein- und Ausblendungen, Zwischenbilder und Ladeanzeigen.
- Scrollen Dazu gehört auch das „Flinging“, bei dem der Nutzer mit dem Scrollen beginnt, dann loslässt und die Seite weiter scrollt.
- Ziehen Animationen folgen oft auf Nutzerinteraktionen wie das Schwenken einer Karte oder das Zoomen durch Auseinander- und Zusammenziehen der Finger.
Inaktiv: Inaktivitätszeit maximieren
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 Aufgaben zu erledigen. Laden Sie beispielsweise beim ersten Seitenaufbau so wenige Daten wie möglich und nutzen Sie dann die Leerlaufzeit, um den Rest zu laden.
Arbeiten während der Leerlaufzeit in maximal 50 ms ausführen. Andernfalls riskieren Sie, dass die App nicht innerhalb von 50 ms auf Nutzereingaben reagieren kann.
Wenn ein Nutzer während der Leerlaufzeit mit einer Seite interagiert, sollte die Nutzerinteraktion immer die höchste Priorität haben und die Leerlaufzeit unterbrechen.
Laden: Inhalte in weniger als 5 Sekunden bereitstellen und interaktiv werden
Wenn Seiten langsam geladen werden, lässt die Aufmerksamkeit der Nutzer nach und sie empfinden die Aufgabe als fehlerhaft. Auf Websites, die schnell geladen werden, sind durchschnittliche Sitzungen länger, Absprungraten niedriger und die Sichtbarkeit von Anzeigen höher.
Ziele:
Optimieren Sie die Ladeleistung in Bezug auf die Geräte- und Netzwerkfunktionen Ihrer Nutzer. Derzeit ist es ein gutes Ziel, die Seite bei ersten Ladevorgängen auf mittelklassefähigen Mobilgeräten mit langsamen 3G-Verbindungen in maximal 5 Sekunden zu laden und interaktiv zu machen.
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 am häufigsten vorkommen. Mit dem Bericht zur Nutzererfahrung in Chrome können Sie die Verteilung der Verbindungen Ihrer Nutzer ermitteln. Wenn die Daten für Ihre Website nicht verfügbar sind, wird im Bericht The Mobile Economy 2019 eine gute globale Baseline vorgeschlagen: ein Android-Smartphone der Mittelklasse wie das Moto G4 und ein langsames 3G-Netzwerk (definiert als 400 ms RTT und 400 kbps Übertragungsgeschwindigkeit). Diese Kombination ist in WebPageTest verfügbar.
Auch wenn das Gerät eines typischen Mobilnutzers eine 2G-, 3G- oder 4G-Verbindung anzeigt, ist die tatsächliche Verbindungsgeschwindigkeit aufgrund von Paketverlusten und Netzwerkschwankungen oft deutlich geringer.
Sie müssen nicht alles in weniger als 5 Sekunden laden, damit der Eindruck entsteht, dass die Seite vollständig geladen wurde. Erwägen Sie, Bilder per Lazy Loading zu laden, JavaScript-Bundles per Code-Splitting aufzuteilen und andere auf web.dev vorgeschlagene Optimierungen vorzunehmen.
Tools zur Messung 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 welche Art von Workflow Sie bevorzugen.
Chrome-Entwicklertools
Die Chrome-Entwicklertools bieten eine detaillierte Analyse aller Vorgänge, die beim Laden oder Ausführen Ihrer Seite stattfinden. Unter Laufzeitleistung analysieren finden Sie Informationen zur Benutzeroberfläche des Leistungsbereichs.
Die folgenden DevTools-Funktionen sind besonders relevant:
CPU drosseln, um ein weniger leistungsstarkes Gerät zu simulieren.
Netzwerk drosseln, um langsamere Verbindungen zu simulieren.
Aktivität des Haupt-Threads ansehen: Hier sehen Sie alle Ereignisse, die während der Aufzeichnung im Haupt-Thread aufgetreten sind.
Aktivitäten des Haupt-Threads in einer Tabelle ansehen, um Aktivitäten danach zu sortieren, welche am längsten gedauert haben.
Bilder pro Sekunde (FPS) analysieren, um zu prüfen, ob Ihre Animationen wirklich flüssig laufen.
Mit dem Leistungsmonitor können Sie CPU-Auslastung, JS-Heap-Größe, DOM-Knoten, Layouts pro Sekunde und mehr in Echtzeit überwachen.
Netzwerkanfragen visualisieren, die während der Aufzeichnung im Bereich Netzwerk aufgetreten sind.
Screenshots während der Aufzeichnung erfassen, um genau zu sehen, wie die Seite während des Ladens oder beim Auslösen einer Animation usw. aussah.
Mit Interaktionen ansehen können Sie schnell ermitteln, was auf einer Seite passiert ist, nachdem ein Nutzer mit ihr interagiert hat.
Scrollleistungsprobleme in Echtzeit erkennen: Die Seite wird hervorgehoben, wenn ein Listener ausgelöst wird, der möglicherweise Probleme verursacht.
Paint-Ereignisse in Echtzeit ansehen, um kostspielige Paint-Ereignisse zu identifizieren, die die Leistung Ihrer Animationen beeinträchtigen können.
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, das Tool simuliert ein Mittelklassegerät mit einer langsamen 3G-Verbindung, führt eine Reihe von Audits auf der Seite aus und erstellt dann einen Bericht zur Ladeleistung sowie Vorschläge zur Verbesserung.
Die folgenden Prüfungen sind besonders relevant:
Antwort
Maximaler potenzieller First Input Delay Schätzt, wie lange Ihre App benötigt, um auf Nutzereingaben zu reagieren, basierend auf der Leerlaufzeit des Hauptthreads.
Verwendet keine passiven Listener zur Verbesserung der Scrollleistung.
Total Blocking Time. Gibt die Gesamtzeit an, in der eine Seite nicht auf Nutzereingaben wie Mausklicks, Bildschirmberührungen oder Tastendrücke reagieren kann.
Zeit bis Interaktivität Wird gemessen, wenn ein Nutzer konsistent mit allen Seitenelementen interagieren kann.
Laden
Es wurde kein Service Worker registriert, der die Seite und die Start-URL steuert. Ein Service Worker kann häufig verwendete Ressourcen auf dem Gerät eines Nutzers im Cache speichern. So wird die Zeit reduziert, die für das Abrufen von Ressourcen über das Netzwerk benötigt wird.
In Mobilfunknetzen werden Seiten nicht schnell genug geladen.
Nicht sichtbare Bilder verzögern Verschieben Sie das Laden von nicht sichtbaren Bildern, bis sie benötigt werden.
Bilder richtig dimensionieren Bilder, die deutlich größer sind als die Größe, die im mobilen Darstellungsbereich gerendert wird, sollten nicht ausgeliefert werden.
Übermäßige DOM-Größe vermeiden Reduzieren Sie die Anzahl der Netzwerkbytes, indem Sie nur DOM-Knoten senden, die zum Rendern der Seite erforderlich sind.
WebPageTest
WebPageTest ist ein Tool zur Webanalyse, mit dem mit echten Browsern auf Webseiten zugegriffen und Zeitmesswerte erfasst werden. Geben Sie eine URL unter webpagetest.org/easy ein, um einen detaillierten Bericht zur Ladeleistung der Seite auf einem echten Moto G4 mit einer langsamen 3G-Verbindung zu erhalten. Sie können auch eine Lighthouse-Prüfung einbinden.
Zusammenfassung
RAIL ist ein Rahmenwerk, mit dem sich die Nutzerfreundlichkeit einer Website als eine Reihe von einzelnen Interaktionen betrachten lässt. Sie können nachvollziehen, wie Nutzer Ihre Website wahrnehmen, um Leistungsziele festzulegen, die sich am stärksten auf die Nutzerfreundlichkeit auswirken.
Optimale Suchergebnisse für Nutzer
In weniger als 100 ms auf Nutzereingaben reagieren.
Beim Animieren oder Scrollen muss ein Frame in weniger als 10 ms gerendert werden.
Maximieren Sie die Inaktivitätszeit des Hauptthreads.
Interaktive Inhalte in weniger als 5.000 ms laden