Mobile Analyse in PageSpeed Insights

PageSpeed Insights analysiert eine Seite, um festzustellen, ob diese unseren Empfehlungen für das Rendering einer Seite in einem Mobilfunknetz in weniger als einer Sekunde entspricht. Studien haben gezeigt, dass bei einer Dauer von mehr als einer Sekunde der Gedankenfluss des Nutzers unterbrochen und das Nutzererlebnis dadurch beeinträchtigt wird. Unser Ziel ist es, dafür zu sorgen, dass der Nutzer sich kontinuierlich mit der Seite beschäftigt und unabhängig von Geräte- oder Netztyp ein optimales Erlebnis erhält.

Es ist nicht einfach, ein Zeitbudget von einer Sekunde einzuhalten. Glücklicherweise muss nicht die gesamte Seite innerhalb dieses Budgets gerendert werden. Stattdessen müssen wir den ohne Scrollen sichtbaren Inhalt (ohne Scrollen sichtbar) in weniger als einer Sekunde bereitstellen und rendern, damit der Nutzer so schnell wie möglich mit der Seite interagieren kann. Während der Nutzer dann mit dem Inhalt auf der ersten Seite beschäftigt ist, kann der Rest der Seite nach und nach im Hintergrund bereitgestellt werden.

Anpassung an Mobilfunknetze mit hoher Latenz

Die Einhaltung des ATF-Kriteriums von einer Sekunde für Mobilgeräte stellt eine Herausforderung dar, die für andere Netzwerke nicht gilt. Nutzer können über eine Vielzahl unterschiedlicher 2G-, 3G- und 4G-Netze auf Ihre Website zugreifen. Die Netzwerklatenzen sind deutlich höher als bei einer kabelgebundenen Verbindung und verbrauchen einen erheblichen Teil unseres 1.000-ms-Budgets für das Rendern der ATF-Inhalte.

4G ist der weltweit dominante Netzwerktyp. Sie sollten davon ausgehen, dass die Mehrheit der Nutzer über ein 4G-Netzwerk auf Ihre Seite zugreift. Aus diesem Grund müssen wir davon ausgehen, dass jede Netzwerkanfrage durchschnittlich 100 Millisekunden dauert.

Mit dieser Zahl im Kopf können wir zurückgehen. Wenn wir uns eine typische Abfolge der Kommunikation zwischen Browser und Server ansehen, wurden bereits 300 ms durch Netzwerk-Overhead verbraucht: ein DNS-Lookup zur Auflösung des Hostnamens (z.B. google.com) in eine IP-Adresse, ein Netzwerk-Roundtrip zur Durchführung des TCP-Handshakes und eine optionale TLS-Verbindung. Jetzt bleiben uns noch 700 ms.

Bedingungen für das Rendering einer Seite unter einer Minute

Nachdem wir die Netzwerklatenz abgezogen haben, verbleiben uns nur noch 700 Millisekunden in unserem Budget und es gibt noch viel zu tun: Der Server muss die Antwort rendern, der clientseitige Anwendungscode muss ausgeführt werden und der Browser muss das Layout und das Rendering der Inhalte vornehmen. Demzufolge sollten die folgenden Kriterien zur Einhaltung des Budgets beitragen:

(1) Der Server muss die Antwort rendern (< 200 ms).
Die Serverantwortzeit ist die Zeit, die ein Server benötigt, um den ursprünglichen HTML-Code zurückzugeben, ohne die Netzwerktransportzeit. Da uns nur so wenig Zeit zur Verfügung steht, sollte diese Zeit möglichst kurz sein – idealerweise unter 200 Millisekunden, besser noch weniger!
(2) Die Anzahl der Weiterleitungen sollte minimiert werden.
Zusätzliche HTTP-Weiterleitungen können zu einem oder zwei zusätzlichen Netzwerk-Roundtrips führen (zwei, wenn ein zusätzlicher DNS-Lookup erforderlich ist), was Hunderte von Millisekunden an Latenz in 4G-Netzen verursacht. Aus diesem Grund empfehlen wir Webmastern dringend, die Anzahl der Weiterleitungen zu minimieren oder diese im Idealfall ganz wegzulassen. Dies gilt besonders für das HTML-Dokument: Sie sollten "m dot"-Weiterleitungen möglichst vermeiden.
(3) Die Anzahl der Roundtrips zum ersten Rendering sollte minimiert werden.

Aufgrund der Art und Weise, wie TCP die Kapazität einer Verbindung schätzt (d. h. TCP Slow Start), kann eine neue TCP-Verbindung nicht sofort die gesamte verfügbare Bandbreite zwischen Client und Server nutzen. Aus diesem Grund kann der Server in einem ersten Roundtrip bis zu zehn TCP-Pakete über eine neue Verbindung (~14 KB) senden und muss dann warten, bis der Client diese Daten bestätigt hat, bis er sein Überlastungsfenster vergrößern und mit der Übermittlung weiterer Daten fortfahren kann.

Außerdem ist zu beachten, dass das Limit von zehn Paketen (IW10) ein aktuelles Update des TCP-Standards ist. Sie sollten darauf achten, dass Ihr Server auf die neueste Version aktualisiert wird, um diese Änderung nutzen zu können. Andernfalls liegt das Limit wahrscheinlich bei 3–4 Paketen.

Aufgrund dieses TCP-Verhaltens ist es wichtig, dass Sie Ihre Inhalte optimieren, um die Anzahl der Roundtrips, die erforderlich sind, um die notwendigen Daten für das erste Rendering der Seite zu liefern, möglichst gering zu halten. Idealerweise sollte der ATF-Inhalt weniger als 98 KB groß sein. Auf diese Weise kann der Browser die Seite nach nur drei Roundtrips darstellen, um genügend Zeit für die Serverantwortlatenz und das Client-Rendering zu haben.

(4) Vermeiden Sie externe JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten, die ohne Scrollen sichtbar sind.

Vor dem Rendering einer Seite für den Nutzer muss der Browser die Seite parsen. Wenn er beim Parsen auf ein nicht asynchrones oder blockierendes externes Skript stößt, muss er stoppen und diese Ressource herunterladen. Dabei wird jedes Mal ein Netzwerk-Roundtrip hinzugefügt, wodurch das erste Rendering der Seite verzögert wird.

Deshalb sollten die zum Rendern des ohne Scrollen sichtbaren Bereichs erforderlichen JavaScript- und CSS-Ressourcen inline eingefügt werden. Außerdem sollten die zum Hinzufügen zusätzlicher Funktionen zur Seite erforderlichen JavaScript- und CSS-Ressourcen geladen werden, nachdem der ohne Scrollen sichtbare Inhalt bereitgestellt wurde.

(5) Reservieren Sie Zeit für Browserlayout und Rendering (200 ms).
Das Parsen von HTML und CSS und das Ausführen von JavaScript nimmt Zeit und Clientressourcen in Anspruch. Je nach Geschwindigkeit des Mobilgeräts und Komplexität der Seite kann dieser Prozess Hunderte von Millisekunden in Anspruch nehmen. Wir empfehlen deshalb, 200 Millisekunden für den Browser-Overhead zu reservieren.
(6) Optimieren Sie JavaScript-Ausführung und Rendering-Zeit.
Komplexe Skripts und ineffizienter Code können mehrere Hundert Millisekunden in Anspruch nehmen. Nutzen Sie die im Browser integrierten Entwicklertools, um Ihren Code zu profilieren und zu optimieren. Eine hilfreiche Einführung finden Sie im interaktiven Kurs für Chrome-Entwicklertools.

Häufig gestellte Fragen

Was muss ich bei der Verwendung einer JavaScript-Bibliothek wie jQuery beachten?
Viele JavaScript-Bibliotheken wie JQuery werden verwendet, um die Seite durch zusätzliche Interaktivität, Animationen und andere Effekte zu ergänzen. Viele dieser Funktionen können aber auch ganz einfach nach dem Rendern des ohne Scrollen sichtbaren Inhalts hinzugefügt werden. Überprüfen Sie, ob Sie solchen JavaScript-Code nach dem Laden der Seite laden und ausführen lassen können.
Was muss ich beim Erstellen einer Seite mithilfe eines JavaScript-Frameworks beachten?
Wenn der Inhalt der Seite über clientseitiges JavaScript erstellt wird, sollten Sie prüfen, ob die relevanten JavaScript-Module inline eingefügt werden, um zusätzliche Netzwerk-Roundtrips zu vermeiden. Ein serverseitiges Rendern kann die für das erste Laden der Seite erforderliche Zeit ebenfalls erheblich verkürzen: Rendern Sie JavaScript-Vorlagen auf dem Server, fügen Sie die Ergebnisse inline in den HTML-Code ein und verwenden Sie anschließend clientseitige Vorlagen nach dem Laden der Anwendung.
Wie erkenne ich kritische CSS-Ressourcen auf meiner Seite?
Öffnen Sie in den Chrome-Entwicklertools den Bereich „Audits“ und erstellen Sie einen Bericht zur Webseitenleistung. Suchen Sie im erstellten Bericht nach „Nicht verwendete CSS-Regeln entfernen“. Sie können auch Drittanbietertools oder ein Skript verwenden, um festzustellen, welche CSS-Selektoren auf den einzelnen Seiten angewendet werden.
Lassen sich diese Verfahren automatisieren?
Ja. Es gibt zahlreiche kommerzielle und Open-Source-Produkte zur Optimierung der Webperformance, mit deren Hilfe Sie einige oder alle der oben genannten Kriterien erfüllen können. Open-Source-Lösungen finden Sie unter den PageSpeed-Optimierungstools.
Wie optimiere ich meinen Server, um diese Kriterien zu erfüllen?
Prüfen Sie zuerst, ob auf Ihrem Server eine aktuelle Version des Betriebssystems ausgeführt wird. Damit Sie von der erhöhten anfänglichen TCP-Überlastungsfenstergröße (IW10) profitieren können, benötigen Sie Linux Kernel 2.6.39 oder höher. Informationen zu anderen Betriebssystemen finden Sie in der Dokumentation.
Um die Serverantwortzeit zu optimieren, sollten Sie Ihren Code instrumentieren oder einen Engpass identifizieren, z.B. Scripting-Laufzeit, Datenbankaufrufe, RPC-Anfragen oder Rendering. Ziel ist es, die HTML-Antwort innerhalb von 200 Millisekunden zu rendern.
Was heißt das für die Content Security Policy?
Wenn Sie die CSP verwenden, müssen Sie möglicherweise Ihre Standardrichtlinie aktualisieren.
Inline-CSS-Attribute in HTML-Elementen(z.B. < p style=...>) sollten vermieden werden, da sie häufig zu unnötiger Duplizierung von Code führen und standardmäßig durch die CSP blockiert werden (über „unsafe inline“ bei „style-src“ deaktiviert). Wenn CSP aktiviert ist, werden alle Inline-Skript-Tags standardmäßig blockiert. Wenn Sie Inline-JavaScript verwenden, müssen Sie die CSP-Richtlinie so aktualisieren, dass entweder Skript-Hashes oder -Nonces oder „unsafe-inline“ verwendet werden, damit alle Inline-Skripts ausgeführt werden können. Wenn Sie Inline-Styles verwenden, müssen Sie die CSP-Richtlinie so aktualisieren, dass entweder Style-Hashes oder -Nonces oder „unsafe-inline“ verwendet werden, damit alle Inline-Style-Blöcke verarbeitet werden können.

Hast du noch Fragen? In unserer Diskussionsgruppe unter pagespeed-insights-discuss können Sie Fragen stellen und Feedback geben.

Feedback

War diese Seite hilfreich?