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 dieser Zeitspanne gerendert werden, sondern wir müssen den ohne Scrollen sichtbaren Inhalt (Above The Fold, ATF) in weniger als einer Sekunde bereitstellen, damit der Nutzer so früh 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 wesentlich höher als bei einer Kabelverbindung und verbrauchen einen beträchtlichen Teil unseres 1.000-Millisekunden-Budgets für das Rendering des ATF-Inhalts:

  • 200-300 ms: Roundtrip-Zeiten für 3G-Netze
  • 50-100 ms: Roundtrip-Zeiten für 4G-Netze

Der weltweit gängigste Netztyp ist 3G. Zwar nehmen 4G-Bereitstellungen immer mehr zu, doch sollten Sie weiter davon ausgehen, dass die Mehrzahl der Nutzer über ein 3G-Netz auf Ihre Seite zugreift. Deshalb ist mit einer durchschnittlichen Dauer von 200 Millisekunden pro Netzwerkanfrage zu rechnen.

Mit dieser Zahl im Kopf können wir zurückgehen. Wenn wir uns einen typischen Kommunikationsablauf zwischen einem Browser und einem Server anschauen, wurden 600 ms der Zeit bereits 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 schließlich ein ganzer Netzwerk-Roundtrip zum Senden der HTTP-Anfrage. Damit bleiben nur noch 400 ms übrig.

Bedingungen für das Rendering einer Seite unter einer Minute

Nach Abzug der Netzwerklatenz sind nur noch 400 Millisekunden übrig und noch ist viel zu tun: Der Server muss die Antwort rendern, der clientseitige Anwendungscode muss ausgeführt werden und der Browser muss das Layout vornehmen und den Inhalt rendern. Demzufolge sollten die folgenden Kriterien zur Einhaltung des Budgets beitragen:

(1) Der Server muss die Antwort rendern (< 200 ms).
Die Antwortzeit des Servers ist die Zeit, die ein Server braucht, um den anfänglichen HTML-Code zurückzugeben, wobei die Netzwerktransportzeit nicht mitgerechnet wird. Da uns so wenig Zeit zur Verfügung steht, sollte diese Zeit möglichst kurz sein und idealerweise unter 200 Millisekunden liegen.
(2) Die Anzahl der Weiterleitungen sollte minimiert werden.
Zusätzliche HTTP-Weiterleitungen können ein oder zwei zusätzliche Netzwerk-Roundtrips bedeuten (zwei, wenn ein zusätzliches DNS-Lookup benötigt wird), wodurch Hunderte von Millisekunden an zusätzlicher Latenz in 3G-Netzen entstehen. 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.

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 ohne Scrollen sichtbare Inhalt 14 KB nicht überschreiten – auf diese Weise kann der Browser die Seite nach nur einem Roundtrip darstellen. Weiterhin ist zu beachten, dass das Limit von zehn Paketen (IW10) ein aktuelles Update des TCP-Standards darstellt. Sie sollten deshalb sicherstellen, dass Ihr Server auf die neuste Version aktualisiert ist, um von dieser Änderung profitieren zu können, denn sonst liegt das Limit bei 3 bis 4 Paketen.

(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 der HTML- und CSS-Ressourcen und Ausführen von JavaScript beansprucht Zeit und Clientressourcen. 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.
Komplizierte Skripts und ineffizienter Code können mehrere Hundert Millisekunden in Anspruch nehmen. Verwenden Sie integrierte Entwicklertools im Browser, um Ihren Code anzupassen und zu optimieren. Eine nützliche Einführung erhalten Sie im interaktiven Kurs für Chrome Developer Tools.

Häufig gestellte Fragen

Wie wirken sich 4G-Netze auf die oben genannten mobilen Kriterien aus?
Zu den wichtigsten Verbesserungen in 4G-Netzen gehören niedrigere Roundtrip-Latenzen. Dies ist eine enorme Verbesserung, weil sich dadurch die gesamte Netzwerk-Overhead-Zeit reduziert, die in 3G-Netzen aktuell über 50 % unseres Ein-Sekunden-Budgets einnimmt. Allerdings ist 3G der weltweit gängigste Netztyp und wird dies auch noch einige Jahre lang sein. Sie sollten bei der Seitenoptimierung also in erster Linie an 3G-Nutzer denken.
Was muss ich bei der Verwendung einer JavaScript-Bibliothek wie jQuery beachten?
Viele JavaScript-Bibliotheken, wie z. B. jQuery, werden zur Anreicherung von Seiten mit zusätzlichen interaktiven Elementen, Animationen und anderen Effekten verwendet. 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 clientseitigen JavaScript-Code erstellt wird, prüfen Sie die Möglichkeit, die entsprechenden JavaScript-Module inline einzufügen, 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.
Welche Vorteile bieten SPDY und HTTP 2.0?
SPDY und HTTP 2.0 sorgen für eine Reduzierung der Latenz beim Laden von Seiten, indem die zugrunde liegende TCP-Verbindung effizienter genutzt wird (mittels Multiplexing, Header-Komprimierung, Priorisierung). Darüber hinaus kann der Server-Push zur Leistungsverbesserung beitragen, indem er zusätzliche Netzwerklatenz vermeidet. Sie sollten also das Hinzufügen der Unterstützung für SPDY auf Ihren Servern und einen Wechsel zu HTTP 2.0 erwägen, sobald der Standard zur Verfügung steht.
Wie erkenne ich kritische CSS-Ressourcen auf meiner Seite?
Öffnen Sie den Audit-Bereich in den Chrome Developer Tools und führen Sie einen Bericht zur Webseiten-Performance aus. Suchen Sie im erstellten Bericht nach nicht verwendeten CSS-Regeln, um diese zu 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?
Stellen Sie zunächst sicher, dass Ihr Server unter einer aktuellen Betriebssystemversion ausgeführt wird. Um die Vorteile eines größeren anfänglichen TCP-Überlastungsfensters (IW10) nutzen zu können, benötigen Sie Linux Kernel 2.6.39+. Informationen zu anderen Betriebssystemen finden Sie in der jeweiligen Dokumentation.
Verwenden Sie Codeinstrumentierung, um die Antwortzeit Ihres Servers zu verbessern, oder eine Lösung zur Anwendungsüberwachung, um den Engpass zu ermitteln – z. B. Scripting-Laufzeit, Datenbankabrufe, RTC-Anfragen, Rendering etc. Ziel ist, die HTML-Antwort innerhalb von 200 Millisekunden zu rendern.
Was heißt das für die Content Security Policy?
Wenn Sie CSP verwenden, müssen Sie Ihre Standardrichtlinie eventuell aktualisieren.
So sollten CSS-Attribute möglichst nicht inline in HTML-Elemente wie z. B. &lt p style=...&gt eingefügt werden, da dadurch oft unnötig Code dupliziert wird. Außerdem wird Inline-CSS-Code in HTML-Elementen gemäß der CSP standardmäßig blockiert (bzw. per "unsafe inline" in "style-src" deaktiviert). Ist CSP aktiviert, werden alle Inline-Skript-Tags standardmäßig blockiert. Wenn Sie Inline-JavaScript-Attribute verwenden, müssen Sie die CSP-Richtlinie aktualisieren oder Sie verwenden Skript-Hashes oder -Nonces oder "unsafe-inline", um die Ausführung aller Inline-Skripts zu ermöglichen. Wenn Sie Inline-Styles verwenden, müssen Sie die CSP-Richtlinie entweder aktualisieren oder aber Style-Hashes oder -Nonces oder "unsafe-inline" verwenden, um die Verarbeitung aller Inline-Style-Blöcke zu ermöglichen.

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