Zugleich erwarten Mobile-Nutzer aber, dass dieselbe Seite schneller lädt (in unter einer 1 Sekunde) als ihr Desktop-Pendant (in weniger als 2 Sekunden) (Quelle). Das stellt einen schwierig zu lösenden Konflikt dar.
Das Problem bei mobilen Netzwerken ist die hohe Latenz. Latenz ist die Verzögerung innerhalb des Netzwerks bei der Übertragung von Datenpaketen.
Latenz bei den unterschiedlichen Mobilfunknetzen:
Bis die erste Ressource, nämlich das HTML-Dokument übertragen ist, müssen verschiedene Schritte erfolgen, welche bereits 3 Round Trips erzeugen.
Abgesehen von der Serverantwortzeit kann man in dieser Schrittfolge keinerlei Optimierungen vornehmen. Man hat einfach keinen weiteren Einfluss und ist von der Latenz abhängig.
Beispiel: 3 Round Trips x 200 ms + Serverantwortzeit von 200 ms = 800 ms
Dass die Latenz bereits mehr als die Hälfte oder gar die gesamte Zeit der Zielvorgabe von 1.000 ms kostet, ist keine Seltenheit.
Beim Aufbau einer Seite gibt es viele Anfragen und Antworten, die zwischen Browser und Server ausgetauscht werden, und somit entsprechend viele Round Trips. Die Erhöhung der übertragbaren Datenmenge bzw. Bandbreite, hat im Mobile-Bereich gar keinen so großen Einfluss darauf, wann die ersten sichtbaren Effekte auf den Nutzer wirken können.
Der Latenz kommt eine wesentliche bedeutendere Rolle zu, wie man anhand der unterschiedlichen Mobilnetze sehen kann. Das bedeutet, dass man in puncto Page Speed im Mobile-Bereich (angesichts der schwierigen Zielvorgabe von 1 Sekunde bei zugleich hoher Latenz) andere Schwerpunkte bei der Optimierung setzen muss.
Beispiele für die Latenz in verschiedenen Mobilnetzen:
Für Redirects ist keine Zeit
Bei einigen Websites kommt es gerade bei deren mobilen Seitenversionen zu Weiterleitungen.
Beispiele:
beispiel.de → www.beispiel.de → m.beispiel.de
beispiel.de → beispiel.de/damen
Weiterleitungen fügen der ganzen Schrittfolge noch einen weiteren Netzwerk Round Trip hinzu, sogar zwei, sofern noch ein weiterer DNS Lookup notwendig wird, z. B. beim Wechsel der Domain. Da hier erneut eine Abhängigkeit der Netzwerklatenz besteht, werden unnötige Millisekunden hinzugefügt.
Beispiel: 5 Round Trips x 200 ms + Serverantwortzeit von 200 ms = 1.200 ms > 1 Sekunde
Für Weiterleitungen gibt es beim Laden einer mobilen Seite einfach keine Zeit. Die optimale Anzahl an Weiterleitungen in der mobilen Internetwelt ist daher null!
Time to first byte muss kürzer als 200 ms sein
Die Serverantwortzeit nennt man auch „Time to first byte“ (TTFB). Sie sollte bei 200 ms oder (optimalerweise noch) weniger liegen.
Die TTFB findet man beispielsweise über die Chrome Developer Tools heraus:
Chrome Developer Tools > Network Ansicht > Timing
Es gibt jede Menge Ursachen für langsame Serverantwortzeiten: hohe Auslastung, langsame Datenbankabfragen, langsames Routing, Frameworks, Libraries, CPU-Mangel oder Speicherprobleme. Um die Zeit zu verbessern, sollte man sich mit den potenziellen Problemverursachern eingehend befassen, z. B. auch mithilfe von Tools wie Newrelic – oder aber, man investiert in stärkere Hardware.
Nachdem die Kommunikation zwischen Server und Browser erläutert worden ist und die Informationen vom Server übertragen werden, ist die Zeit dafür gekommen, dass die Informationen auf dem Endgerät weiterverarbeitet werden und die Seite im Browser aufgebaut wird. Diesen Prozess kennt man als Rendering.
Wie funktioniert Rendering?
An einem kleinen Beispiel sollen die Vorgänge während des Parsings, Renderings und Layoutings verdeutlicht werden, die bis zum sogenannten „First Paint“ ablaufen, dem ersten optischen Feedback für den Nutzer.
Ziel dieses Artikels ist es nicht, sämtliche Page-Speed-Optimierungsmaßnahmen aufzulisten und zu erläutern; es sollen stattdessen ausschließlich jene Maßnahmen vorgestellt werden, die den „First Paint“ in einem mobilen Netzwerk (mit dessen hoher Latenz) so weit wie möglich in der Zeit nach vorne verlagern, sodass der Nutzer schneller ein visuelles Feedback von einer Webseite erhält.
Beispiel HTML:
Beim Parsen wird jedes Element innerhalb des HTML-Dokuments durchlaufen. Das Stylesheet „beispiel.css“ wird als erstes entdeckt und der Ladeprozess beginnt. Da es sich um ein externes Stylesheet handelt, muss es im Rahmen eines Round Trips vom Server geladen werden, was wiederum stark von der Latenz des Netzwerks abhängig ist.
Das Stylesheet wurde geparst, aber noch nicht komplett geladen. Zu diesem Zeitpunkt wird noch nichts auf dem Display des mobilen Endgeräts angezeigt.
Während das Stylesheet heruntergeladen wird, wird das HTML-Dokument weiter geparst und das Bild sowie das JavaScript Dokument werden identifiziert.
Zwar sind nunmehr alle Ressourcen erkannt, jedoch kann die Seite nicht gerendert werden, bevor alle Ressourcen komplett übertragen worden sind, was wiederum von der Latenz abhängig ist.
Im nächsten Schritt ist das Stylesheet vollständig geladen worden. Trotzdem zögert der Ladevorgang des JavaScript-Dokuments immer noch das Rendering heraus. Bevor beide Ressourcen nicht komplett geladen worden sind, kann kein im Quellcode nachfolgender Inhalt angezeigt werden.
In dem Moment in dem alles geladen ist, kann zum ersten Mal etwas auf dem Display angezeigt werden, der „First Paint“.
Tipp: Über den Lighthouse Audit in den Chrome Developer Tools kann man die „First Paint“-Zeit herausfinden:
Above the fold sollte in 14 kB passen
Um den „First Paint“ noch rascher eintreten zu lassen, sollte man sich auf alle Maßnahmen konzentrieren, die Round Trips einsparen und somit Abhängigkeiten von der Latenz verringert. Es reicht vollkommen aus, sich nur auf den sichtbaren Teil des Displays zu fokussieren.
Externe Ressourcen – wie im Rendering-Beispiel – sind nicht per se schlecht und haben für Desktop-Seiten durchaus ihre Berechtigung, beispielsweise deshalb, weil sie über mehrere Requests gecacht werden können. Im Mobile-Bereich erfordern sie allerdings immer wieder neue Requests, was man sich bis zum Erreichen des „First Paint“ zeitlich nicht leisten kann.
Wichtige Inhalte im sichtbaren Bereich sollten demzufolge priorisiert und innerhalb dieses ersten Round Trips bereits im HTML-Dokument mitgeliefert werden, indem man sie inline einfügt. Es sollte natürlich nicht alles inline eingebunden werden, sondern nur die wirklich absolut notwendigen Abschnitte. Dabei sollte die TCP-Range von 14 kB pro Round Trip nicht überschritten werden.
Mittels komprimierter Übertragung kann man die Datenmenge bis zum Erreichen der Grenze von 14 kB erweitern. Wird dieser faktische Wert dann allerdings überschritten, wird ein weiterer Round Trip erforderlich und somit stellen die Abhängigkeiten der Latenz wieder ein Problem dar.
Zusammengefasst:
- genau überlegen, was Above the fold und vor allem für den „First Paint“ wichtig ist
- aufpassen, dass der Inline-Code in die TCP-Vorgabe passt
CSS priorisiert splitten
Standardmäßig ist CSS eine Ressource, die das Rendering blockiert, da die Darstellung ohne CSS beeinträchtig ist. Aus diesem Grund sollte man das benötigte CSS in verschiedene Teile aufspalten:
- Eine geringe Menge CSS, welche für den „First Paint“ im Above-the-fold-Bereich benötigt wird, sollte inline in das HTML-Dokument eingebunden werden.
- Ein externes Stylesheet sollte alle weiteren Styles beinhalten. So kann es geladen werden, ohne dabei das Rendering des kritischen Bereichs zu blockieren.
- Je nach Menge des CSS kann es ebenfalls Sinn machen, die Styles zu splitten in eine base.css, die Styles für alle Seitentypen umfasst, und ein Stylesheet, das alle Styles beinhaltet, welche explizit nur auf dieser Seite oder für diesen Seitentyp benötig werden.
- Da durch Inlinen das Caching verlorengeht und das Inlinen und Splitten von der Menge des CSS abhängt, sollte man testen, welche Variante am besten funktioniert.
Tipp: Zukünftig wird über HTML-Imports eine Möglichkeit unterstützt, Stylesheets zu laden, die den Rendering-Prozess blockieren.
JavaScript wird optimalerweise Above-the-fold nicht benötigt
Findet der Browser beim Parsing des HTML-Dokuments ein Script-Tag, muss er die DOM-Erstellung unterbrechen und an die JavaScript Engine übergeben. JavaScript kann das DOM und CSSOM abfragen und Teile davon verändern. Aus diesem Grund wird die Erstellung von DOM und CSSOM blockiert, wenn JavaScript ausgeführt wird.
Die Position des Scripts im Dokument ist daher entscheidend. Blockieren an entscheidenden Stellen keine Scripts das Rendern, kann das DOM schneller aufgebaut, der DOM-Content schneller geladen und somit dem User früher angezeigt werden.
Inline
Scripts, die für den Above-the-fold-Bereich unabdingbar sind, sollten genau wie CSS inline eingebunden werden, um weitere Round Trips zu unterbinden. Es muss allerdings darauf geachtet werden, dass das Inline-JavaScript sehr klein ist und schnell ausgeführt wird.
Außerdem sollte man beachten, dass das Inline-JavaScript die Größe des HTML-Dokuments erhöht und der gleiche Code auf mehreren Seiten eingebunden werden muss.
Damit die nicht sofort benötigten Script-Teile das Parsen und Rendern nicht stören, können diese an das Ende des HTML-Dokuments gelegt werden. Oder man verlagert sie per „defer“ oder „async“, wenn das für die jeweilige Seite eine bessere Lösung darstellt.
„async“ vermittelt dem Browser, dass das Script nicht genau an dieser Stelle ausgeführt werden muss. Auf diese Weise kann der Browser mit der DOM-Erstellung weitermachen. Das Script wird ausgeführt, sobald es vollständig geladen ist.
<script async src=“/beispiel.js“>
„defer“ vermittelt dem Browser, dass das Script erst am Ende geladen und ausgeführt werden muss.
<script defer src=“/beispiel.js“>
Mit gzip das Potenzial von 14 kB erweitern
Die Verwendung von gzip-Komprimierung kann die Größe der zu übertragenden Daten um bis zu 90 % reduzieren, was die mögliche Datenmenge des ersten Round Trips erhöhen und somit die Zeit bis zum „First Paint“ signifikant verbessern kann.
Alle textbasierten Ressourcen können komprimiert übertragen werden. Die Einstellung in der Server-Config kann rasch vorgenommen werden, wodurch diese Maßnahme somit eine „low-hanging fruit“ darstellt.
Beispiel-Konfiguration für einen Nginx-Server
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
Beispiel-Konfiguration für einen Apache-Server
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddType x-font/otf .otf
AddType x-font/ttf .ttf
AddType x-font/eot .eot
AddType x-font/woff .woff
AddType image/x-icon .ico
AddType image/png .png
</IfModule>
Einstellung für Microsoft IIS
Gehe innerhalb der IIS-Plattform zu der Komprimierungsseite für die Webseite, für welche du gzip-Komprimierung freischalten möchtest. Sofern das „Dynamic Content Compression Modul“ installiert ist, kannst du gzip einfach anwählen, indem du das Häkchen bei „Enable dynamic content compression“ setzt. Andernfalls installierst du das Modul zuvor mittels „Turn Windows features on or off“.
Welche Dateiformate können komprimiert übertragen werden?
text/html
text/css
text/plain
text/xml
text/x-component
text/javascript
application/x-javascript
application/javascript
application/json
application/manifest+json
application/xml
application/xhtml+xml
application/rss+xml
application/atom+xml
application/vnd.ms-fontobject
application/x-font-ttf
application/x-font-opentype
application/x-font-truetype
image/svg+xml
image/x-icon
image/vnd.microsoft.icon
font/ttf
font/eot
font/otf
font/opentype
Checkliste: Latenzreduzierung für höheren Page Speed
Zusammenfassend ergibt sich folgende Checkliste an Optimierungsmaßnahmen, die den „First Paint“ innerhalb von Netzwerken mit hoher Latenz beschleunigen können:
- Der Fokus gilt der Verringerung der Zahl benötigter Round Trips.
- Im besten Fall ist nur ein Round Trip für Above the fold notwendig.
- Das TCP-Fenster von 14 kB darf nicht überschritten werden (gzip).
- Falls weitere Round Trips notwendig sind, sollten alle wichtigen Ressourcen auf der gleichen Domain eingebunden werden, damit kein weiterer DNS Lookup notwendig wird, der ebenfalls von der Latenz abhängig wäre.
- Es dürfen keine Weiterleitungen eingebaut sein.
- Der Server sollte so schnell wie möglich antworten (max. 200 ms).
- Verhindern von rendering-blockierenden Round Trips (Latenz)
- Above-the-fold-CSS sollte inline eingebunden werden.
- Es sollte so wenig Above-the-fold-JavaScript eingebunden werden wie möglich, im besten Fall gar nicht.
- Alle weiteren Stylesheets und Scripts sollten mindestens nach den Above-the-fold-Bereich verlagert werden.
