RAIL ist ein nutzerorientiertes Leistungsmodell, das eine Struktur für Überlegungen zur Leistung bietet. Das Modell schlüsselt die Nutzererfahrung in wichtige Aktionen (z. B. Tippen, Scrollen, Laden) auf und hilft Ihnen, für jede Aktion Leistungsziele zu definieren.
RAIL steht für vier verschiedene Aspekte des Lebenszyklus von Webanwendungen: Antwort, Animation, inaktiv und Last. Nutzer haben in jedem dieser Kontexte unterschiedliche Leistungserwartungen. Leistungsziele werden daher basierend auf dem Kontext und UX-Untersuchungen dazu, wie Nutzer Verzögerungen wahrnehmen, definiert.
Optimale Suchergebnisse für Nutzer
Nutzer in den Mittelpunkt Ihrer Bemühungen stellen In der folgenden Tabelle sind die wichtigsten Messwerte dazu aufgeführt, wie Nutzer Leistungsverzögerungen wahrnehmen:
Wahrnehmung von Leistungsverzögerungen durch Nutzer| 0 bis 16 ms | Nutzer können Bewegungen besonders gut erfassen, und sie mögen es nicht, wenn Animationen nicht flüssig sind. Animationen werden als flüssig empfunden, solange pro 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, bis eine App ungefähr 10 ms benötigt, um einen Frame zu erzeugen. |
| 0 bis 100 ms | Reagieren Sie innerhalb dieses Zeitfensters auf die Nutzeraktionen und die Nutzenden haben das Gefühl, dass sich das Ergebnis sofort ergibt. und auch die Verbindung zwischen Aktion und Reaktion wird unterbrochen. |
| 100 bis 1.000 ms | Innerhalb dieses Fensters fühlen sich die Dinge als Teil eines natürlichen und kontinuierlichen Fortschritts von Aufgaben an. Für die meisten Webnutzer stellt das Laden von Seiten oder das Ändern der Ansicht eine Aufgabe dar. |
| 1.000 ms oder mehr | Über 1.000 Millisekunden (1 Sekunde) verlieren die Nutzenden den Fokus auf die von ihnen ausgeführte Aufgabe. |
| 10.000 ms oder mehr | Nach diesen 10.000 Millisekunden (10 Sekunden) sind Nutzende frustriert und es ist wahrscheinlich, dass sie Aufgaben abbrechen. Sie werden vielleicht später wiederkommen. |
Ziele und Richtlinien
Im Zusammenhang mit RAIL haben die Begriffe Ziele und Richtlinien eine bestimmte Bedeutung:
Zielvorhaben: Wichtige Leistungsmesswerte im Zusammenhang mit der Nutzererfahrung. Tippen Sie zum Beispiel, 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, mit denen Sie Ihre Ziele erreichen können. Sie können sich speziell auf die aktuellen Hardware- und Netzwerkverbindungsbedingungen beziehen und sich daher im Laufe der Zeit ändern.
Antwort: Verarbeitungsereignisse in weniger als 50 ms
Ziel: Durch Nutzereingabe innerhalb von 100 ms eingeleitet wird, sodass die Nutzer das Gefühl haben, dass die Interaktionen sofort erfolgen
Richtlinien:
Damit innerhalb von 100 ms eine sichtbare Antwort angezeigt wird, sollten Sie Nutzereingabeereignisse innerhalb von 50 ms verarbeiten. Dies gilt für die meisten Eingaben, z. B. das Klicken auf Schaltflächen, das Wechseln von Formularsteuerelementen oder das Starten von Animationen. Dies gilt nicht für das Ziehen oder Scrollen.
Auch wenn dies widersprüchlich klingen mag, ist es nicht immer der richtige Aufruf, sofort auf Nutzereingaben zu reagieren. Sie können dieses 100-ms-Fenster für andere teure Arbeiten verwenden, aber achten Sie darauf, den Nutzer nicht zu blockieren. Arbeiten Sie möglichst im Hintergrund.
Wenn Aktionen länger als 50 ms dauern, geben Sie immer Feedback.
50 ms oder 100 ms?
Ziel ist es, in weniger als 100 ms auf Eingaben zu reagieren. Warum ist unser Budget also nur 50 ms? Das liegt daran, dass neben der Eingabeverarbeitung in der Regel noch weitere Arbeitsschritte 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 Inaktivität in den empfohlenen 50-ms-Blöcken arbeitet, kann die Eingabe bis zu 50 ms in die Warteschlange gestellt werden, wenn sie während eines dieser Arbeitsblöcke erfolgt. Daher kann davon ausgegangen werden, dass nur die verbleibenden 50 ms für die eigentliche Eingabeverarbeitung verfügbar sind. Dieser Effekt wird im folgenden Diagramm veranschaulicht:
Animation: Frame in 10 ms erstellen
Ziele:
Erzeugen Sie jeden Frame in einer Animation in 10 ms oder weniger. Technisch gesehen beträgt das maximale Budget für jeden Frame 16 ms (1.000 ms ÷ 60 Frames pro Sekunde ÷ 16 ms), aber Browser benötigen etwa 6 ms zum Rendern jedes Frames, daher ist die Richtlinie von 10 ms pro Frame.
Das Ziel sollte eine möglichst flüssige visuelle Darstellung sein. Nutzer bemerken, wenn die Framerates variieren.
Richtlinien:
An Stellen mit hohem Druck wie Animationen ist es wichtig, nichts zu tun, wo es möglich ist, und ein absolutes Minimum zu erreichen, wo dies nicht möglich ist. Nutzen Sie nach Möglichkeit die Antwort von 100 ms, um teure Arbeit im Voraus zu berechnen, damit Sie Ihre Chancen auf 60 fps maximieren.
Informationen zu verschiedenen Strategien zur Optimierung der Animation finden Sie unter Renderingleistung.
- Visuelle Animationen, z. B. Ein- und Ausstiege, Tweens und Ladeanzeigen.
- Scrollen. Dazu gehört das „Schleudern“ – der Nutzer beginnt zu scrollen, lässt ihn dann los und die Seite scrollt weiter.
- Wird verschoben. Animationen folgen häufig Nutzerinteraktionen, z. B. Schwenken einer Karte oder Zusammenziehen der Finger.
Inaktiv: Inaktivitätszeit maximieren
Ziel: Maximieren Sie die Leerlaufzeit, um die Wahrscheinlichkeit zu erhöhen, dass die Seite innerhalb von 50 ms auf Nutzereingaben reagiert.
Richtlinien:
Inaktivitätszeit verwenden, um zurückgestellte Arbeiten abzuschließen. Laden Sie beispielsweise beim ersten Laden der Seite so wenig Daten wie möglich und nutzen Sie dann die Inaktivitätszeit, um den Rest zu laden.
Arbeiten Sie bei Inaktivität in 50 ms oder weniger. Ist das nicht der Fall, riskieren Sie, dass die Fähigkeit der App, innerhalb von 50 ms auf Nutzereingaben zu reagieren, beeinträchtigt wird.
Wenn ein Nutzer während der Inaktivität mit einer Seite interagiert, sollte die Nutzerinteraktion immer die höchste Priorität haben und die Arbeit unterbrechen.
Laden: Inhalte bereitstellen und in weniger als 5 Sekunden interaktiv werden
Wenn Seiten langsam geladen werden, wandern die Aufmerksamkeit der Nutzer und Nutzer nehmen die Aufgabe als fehlerhaft wahr. Websites, die schnell geladen werden, haben längere durchschnittliche Sitzungen, niedrigere Absprungraten und eine höhere Anzeigensichtbarkeit.
Ziele:
Optimieren Sie die Ladegeschwindigkeit im Verhältnis zu den Geräte- und Netzwerkfunktionen Ihrer Nutzer. Derzeit empfiehlt es sich, die Seite beim ersten Laden zu laden und auf mittelpreisigen Mobilgeräten mit langsamen 3G-Verbindungen in höchstens 5 Sekunden interaktiv zu sein.
Bei nachfolgenden Ladevorgängen sollte die Seite in weniger als zwei Sekunden geladen werden.
Richtlinien:
Testen Sie die Lastleistung auf den Mobilgeräten und Netzwerkverbindungen, die Ihre Nutzer gemeinsam haben. Mit dem Bericht zur Nutzererfahrung in Chrome können Sie die Verteilung der Verbindungen Ihrer Nutzer ermitteln. Wenn die Daten für Ihren Standort nicht verfügbar sind, deutet die Mobile Economy 2019 darauf hin, dass Android-Smartphones im mittleren Preissegment (z. B. Moto G4) und ein langsames 3G-Netzwerk (definiert als 400 ms RTT und 400 kbit/s Übertragungsgeschwindigkeit) eine gute globale Basis sind. Diese Kombination ist auf WebPageTest verfügbar.
Auch wenn das Gerät eines typischen mobilen Nutzers angibt, dass es sich um eine 2G-, 3G- oder 4G-Verbindung handelt, ist die effektive Verbindungsgeschwindigkeit aufgrund von Paketverlusten und Netzwerkabweichungen häufig deutlich langsamer.
Sie müssen nicht alles in weniger als fünf Sekunden laden, um den Eindruck einer vollständigen Ladung zu erzeugen. Ziehen Sie Lazy Loading, JavaScript-Bundles zur Codeaufteilung und andere Optimierungen, die auf web.dev empfohlen wurden, in Betracht.
Tools zur Messung von RAIL
Es gibt einige Tools, mit denen Sie Ihre RAIL-Messungen automatisieren können. Welche davon 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 detaillierte Analysen zu allem, was beim Laden oder Ausführen einer Seite geschieht. Lesen Sie Erste Schritte mit der Analyse der Laufzeitleistung, um sich mit der Benutzeroberfläche des Steuerfelds Leistung vertraut zu machen.
Die folgenden Entwicklertools sind besonders relevant:
Drosseln Sie Ihre CPU, um ein weniger leistungsstärkeres Gerät zu simulieren.
Drosseln Sie das Netzwerk, um langsamere Verbindungen zu simulieren.
Sehen Sie sich die Aktivitäten des Hauptthreads an, um alle Ereignisse anzusehen, die während der Aufzeichnung im Hauptthread aufgetreten sind.
Sehen Sie sich die Aktivitäten des Hauptthreads in einer Tabelle an, um die Aktivitäten danach zu sortieren, welche die meiste Zeit in Anspruch genommen haben.
Analysieren Sie die Bilder pro Sekunde (Frames per Second, FPS), um zu messen, ob Ihre Animationen wirklich reibungslos laufen.
Netzwerkanfragen, die während der Aufzeichnung aufgetreten sind, im Bereich Netzwerk visualisieren
Erfassen Sie während der Aufnahme Screenshots, um genau wiederzugeben, wie die Seite beim Laden der Seite aussah, oder um eine Animation auszulösen.
Sehen Sie sich Interaktionen an, um schnell zu ermitteln, was auf einer Seite passiert ist, nachdem ein Nutzer damit interagiert hat.
Sie können Probleme mit der Scrollleistung in Echtzeit ermitteln, indem Sie die Seite markieren, wenn ein potenziell problematischer Listener ausgelöst wird.
Sehen Sie sich die Paint-Ereignisse in Echtzeit an, um kostspielige Paint-Ereignisse zu identifizieren, die die Leistung Ihrer Animationen beeinträchtigen können.
Leuchtturm
Lighthouse ist in den Chrome-Entwicklertools, unter PageSpeed Insights, als Chrome-Erweiterung, als Node.js-Modul und in WebPageTest verfügbar. Sie geben eine URL ein, es simuliert ein Gerät im mittleren Preissegment mit einer langsamen 3G-Verbindung, führt eine Reihe von Audits auf der Seite aus und liefert Ihnen einen Bericht zur Ladeleistung sowie Verbesserungsvorschläge.
Die folgenden Prüfungen sind besonders relevant:
Antwort
Maximales potenzielles First Input Delay. Schätzt, wie lange Ihre Anwendung benötigt, um auf Nutzereingaben zu reagieren, basierend auf der Leerlaufzeit des Hauptthreads.
Verwendet keine passiven Listener zur Verbesserung der Scrollleistung.
Total Blocking Time (Gesamte Blockierzeit). Gibt an, wie lange eine Seite insgesamt daran gehindert wird, auf Nutzereingaben wie Mausklicks, Bildschirmtippen oder Tastatureingaben zu reagieren.
Time To Interactive. Dieser Wert gibt an, wann ein Nutzer konsistent mit allen Seitenelementen interagieren kann.
Laden
Registriert keinen Service Worker, der die Seite und start_url steuert. Ein Service Worker kann allgemeine Ressourcen auf dem Gerät eines Nutzers im Cache speichern, wodurch der Zeitaufwand für das Abrufen von Ressourcen über das Netzwerk reduziert wird.
Nicht sichtbare Bilder zurückstellen: Verzögern Sie das Laden von nicht sichtbaren Bildern, bis sie benötigt werden.
Bilder in der richtigen Größe: Stellen Sie keine Bilder bereit, die deutlich größer sind als die im mobilen Darstellungsbereich gerenderte Größe.
Vermeiden Sie eine zu große DOM-Größe. Reduzieren Sie die Netzwerkbyte, indem Sie nur DOM-Knoten versenden, die für das Rendern der Seite erforderlich sind.
WebPageTest
WebPageTest ist ein Tool für die Webleistung, das mit echten Browsern auf Webseiten zugreift und Zeitmesswerte erfasst. Geben Sie unter webpagetest.org/easy eine URL ein, um einen detaillierten Bericht zur Ladeleistung der Seite auf einem echten Moto G4-Gerät mit einer langsamen 3G-Verbindung zu erhalten. Sie können sie auch so konfigurieren, dass sie eine Lighthouse-Prüfung enthält.
Zusammenfassung
RAIL dient dazu, die User Experience einer Website als eine Reise zu betrachten, die sich aus verschiedenen Interaktionen zusammensetzt. Wenn Sie verstehen, wie Nutzer Ihre Website wahrnehmen, können Sie Leistungsziele mit den größten Auswirkungen auf die Nutzererfahrung festlegen.
Optimale Suchergebnisse für Nutzer
Reagieren Sie in weniger als 100 ms auf Nutzereingaben.
Erzeugen Sie beim Animieren oder Scrollen einen Frame in weniger als 10 ms.
Maximieren Sie die Inaktivitätszeit des Hauptthreads.
Interaktive Inhalte in weniger als 5.000 ms laden.