Mobile Analyse in PageSpeed Insights

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 die gesamte Seite nicht im Rahmen dieses Budgets gerendert werden. Wir müssen Inhalte „above the fold“ (ohne Scrollen sichtbar) in weniger als einer Sekunde bereitstellen, 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 Kabelverbindung und verbrauchen einen beträchtlichen Teil unseres 1.000-ms-Budgets für das Rendern des ATF-Inhalts.

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

Mit dieser Zahl im Kopf können wir zurückgehen. Wenn wir eine typische Kommunikationssequenz zwischen einem Browser und einem Server betrachten, wurden bereits 300 ms dieser Zeit durch den Netzwerk-Overhead verbraucht: ein DNS-Lookup zur Auflösung des Hostnamens (z.B. google.com) zu einer IP-Adresse, ein Netzwerk-Roundtrip für den TCP-Handshake und eine optionale TLS-Verbindung. Wir haben also 700 ms.

Bedingungen für das Rendering einer Seite unter einer Minute

Nach Abzug der Netzwerklatenz haben wir nur noch 700 Millisekunden in unserem Budget übrig und der Server muss noch viel tun: Der Server muss die Antwort rendern, der clientseitige Anwendungscode muss ausgeführt werden und der Browser muss das Layout und den Inhalt rendern. 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 braucht, um den anfänglichen HTML-Code zurückzugeben. Dabei wird die Netzwerktransportzeit berücksichtigt. 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.
Mit zusätzlichen HTTP-Weiterleitungen können ein oder zwei zusätzliche Netzwerk-Roundtrips hinzugefügt werden (zwei, wenn ein zusätzlicher DNS-Lookup erforderlich ist), was in 4G-Netzwerken zu einer zusätzlichen Latenz von mehreren hundert Millisekunden führt. 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.

Das Limit von 10 Paketen (IW10) ist ein aktuelles Update des TCP-Standards. Es ist wichtig, dass Ihr Server auf die neueste Version aktualisiert wird, um diese Änderung zu nutzen. Andernfalls liegt das Limit 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 98 KB nicht überschreiten. So kann der Browser die Seite nach nur drei Roundtrips darstellen, um ein ausreichendes Zeitbudget für Serverlatenz und 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 erfordern 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.
Die Ausführung von komplizierten Skripts und ineffizientem Code kann mehrere hundert oder mehrere Millisekunden in Anspruch nehmen. Mit den integrierten Entwicklertools können Sie im Browser ein Profil erstellen und Ihren Code optimieren. Eine gute Einführung finden Sie in unserem interaktiven Kurs zu Chrome-Entwicklertools.

FAQ

Was muss ich bei der Verwendung einer JavaScript-Bibliothek wie jQuery beachten?
Viele JavaScript-Bibliotheken, z. B. JQuery, werden verwendet, um die Seite zu optimieren und zusätzliche Interaktivität, Animationen und andere Effekte hinzuzufügen. 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 von clientseitigem JavaScript erstellt wird, sollten Sie die relevanten JavaScript-Module untersuchen, 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 führen Sie einen Leistungsbericht für die Webseite aus. Suchen Sie im generierten 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 in den PageSpeed-Optimierungstools.
Wie optimiere ich meinen Server, um diese Kriterien zu erfüllen?
Zuerst solltest du prüfen, ob auf deinem Server die aktuelle Version des Betriebssystems installiert ist. Damit Sie von der größeren Größe des anfänglichen TCP-Überlastungsfensters (IW10) profitieren können, benötigen Sie Linux Kernel 2.6.39 oder höher. Informationen zu anderen Betriebssystemen finden Sie in der Dokumentation.
Wenn Sie die Serverantwortzeit optimieren möchten, instrumentieren Sie Ihren Code oder verwenden Sie eine Anwendungsmonitoringlösung, um Ihren Engpass zu identifizieren, z.B. Skriptlaufzeit, Datenbankaufrufe, RPC-Anfragen, Rendering usw. Das 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.
Zuerst Inline-CSS-Attribute zu HTML-Elementen(z.B. < p style=...>). 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 haben, müssen Sie die CSP-Richtlinie aktualisieren, um entweder Stil-Hashes oder -Nonces oder „In-Inline-Styles“ zu verwenden, damit alle Inline-Style-Blöcke verarbeitet werden können.

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

Feedback

War diese Seite hilfreich?