Geschrieben von

Pagespeed

24. März 2018• WebDev

Warum PageSpeed wichtig ist

  • Crawling: Eine bessere Ladegeschwindigkeit hat positive Auswirkungen auf das Crawling der Inhalte.
  • Positive Nutzererfahrung: Heute muss alles schnell gehen! Nutzer erwarten das auch von Webseiten. Eine schnelle Ladegeschwindigkeit führt zu kleineren Absprungraten und längerer Verweildauer. 47 % der Nutzer erwarten, dass eine Seite innerhalb von 2 Sekunden lädt und 40 % verlassen die Seite innerhalb von 3 Sekunden, wenn diese nicht vollständig geladen wird (Quelle).
  • Mehr Umsätze: Bereits 100 ms können entscheidend sein, um 1 % mehr Umsatz zu generieren (Amazon-Beispiel). Eine Verzögerung von 1 Sekunde führt schon zu 7 % weniger Conversions, 16 % weniger Kundenzufriedenheit und 11 % weniger Seitenaufrufe (Quelle).

Wie schnell muss eine Seite laden (in Zahlen)?

Diese Antwort ist nicht so leicht. Die Gegenfrage wäre hier, ob das die richtige Frage wäre. Laut Google gäbe es hierzu keine einzelne Zahl, die dies beantworten würde. Die Antwort hängt vom Ziel, der Nutzer und dem Kontext ab:

  • Ziel: Hier geht es vor allem um die Frage, ob es um die Verweildauer geht, um die Nutzer-Zufriedenheit oder um die Erledigung bestimmter Aufgaben. Es gibt hierzu verschiedene Studien, die zu unterschiedlichen Zahlen kommen. Bspw. sind Nutzer auf vertrauten Seiten etwas geduldiger, während auf unbekannten Websites Nutzer bei einer Verzögerung von 2 Sekunden größtenteils schon abspringen.
  • Nutzer: Hier geht es um die persönlichen Erwartungen der Nutzer, deren Erfahrungen und wie dringend sie bestimmte Aufgaben erledigen müssen. Das hat alles Auswirkungen auf die Fragen, wie schnell eine Seite eigentlich laden muss.
  • Kontext: Zudem spielt die Situation eine wichtige Rolle. Ob der Nutzer eine News-Website besucht oder ein Reiseportal, stellen unterschiedliche Szenarien dar.

Trotz dieser Umstände gibt es immer diverse Empfehlungen hinsichtlich der Ladezeiten. Bei den Web Vitals hat Google diese konkret genannt.

Laut John Müller sollte eine Webseite zwischen 2 und 3 Sekunden geladen werden, damit Sie als “Schnell” eingestuft wird.

Aus Usability-Sicht ist eine Seitenladegeschwindigkeit unter 1 Sekunde maßgebend, um den Fokus des Nutzers auf der Webseite zu behalten. Laut Nielsen kann die Wahrnehmung der Zeit aus Nutzer-Sicht folgendermaßen dargestellt werden:

  • 0-100 ms: Keine Verzögerung spürbar
  • 100-300 ms: Leicht spürbare Verzögerung
  • 300ms-1000ms: Spürbare Verzögerung, jedoch bleibt der Arbeitsfluss ungebrochen
  • 1000+ ms: Leichte gedankliche Abschweifung
  • 10000+ ms: Die Aufgabe wird unterbrochen

Oberstes Ziel sollte es also sein, die Ladegeschwindigkeit unter 100 ms zu bringen. Das ist gar nicht so leicht, wenn man nun bedenkt, was alles passieren muss, bevor eine Seite im Browserfenster dargestellt werden kann (Parsing, Erstellung Baumstruktur, Layout, Painting, etc.). Man kann jedoch dem Nutzer das Gefühl geben, dass die Seite schneller lädt als sie es eigentlich tut.

Objektive und subjektive Zeit

Was ist der Unterschied?

  • Objektive Zeit: Die objektive Zeit wird in Einheiten gemessen: Tage, Stunden, Sekunden, etc. Beispiel: Wir fahren mit dem Zug von München nach Salzburg und diese dauert 1 Stunde und 40 Minuten. Das können wir an unserer Uhr ablesen.
  • Subjektive Zeit: Die subjektive Zeit ist abhängig vom persönlichen Empfinden. Um beim obigen Beispiel zu bleiben: Wenn wir die ganze Fahrt lang auf unsere Uhr starren, spüren wir wie lange 1 Stunde und 40 Minuten dauern. Lesen wir während der Fahrt jedoch ein Buch, hören Musik oder schauen uns eine Serie an, so kommen wir ebenfalls in 1 Stunde und 40 Minuten in Salzburg an. Jedoch mit einem Unterschied: Wir haben die Fahrt nicht so lange empfunden. Es kommt uns vor, als ob wir nur 30 Minuten unterwegs waren, weil wir mit anderen Dingen beschäftigt waren. Jeder hatte sicher mal so ein Erlebnis, wo die Zeit wie im Flug vergeht.

Viele PageSpeed-Analyse-Tools analysieren die Seitenladeschwindigkeit der Webseiten und geben diese in Sekunden wieder (objektive Zeit). Dabei wird ermittelt, wie lange die Seite braucht, bis sie vollständig geladen wurde. Bei einer Seite, wo viele Ressourcen geladen werden müssen, kann das schon einige Sekunden in Anspruch nehmen (nehmen wir an unsere Seite braucht 5 Sekunden). Wir können dem Nutzer aber dennoch das Gefühl geben, dass unsere Seite innerhalb von 2 Sekunden lädt (subjektive Zeit). Wie? Indem wir zuerst nur alle Inhalte und Ressourcen laden, die für den ersten sichtbaren Bereich (Above the fold) notwendig sind. Mit der Optimierung des Critical Rendering Paths können wir gezielt die subjektiv empfundene Zeit des Nutzers ansprechen.

Pagespeed messen

Es gibt grundsätzlich 2 Möglichkeiten den Pagespeed bzw. die Performance einer Seite zu messen:

  • “In the lab”: Hier kommen Tools zum Einsatz, um die Seitenladegeschwindigkeit in einer konsistenten Umgebung zu simulieren. Vorteil dieser Methode ist, dass die Ergebnisse reproduzierbar sind. In der Regel werden immer die gleichen Ergebnisse geliefert, solange die Parameter nicht geändert werden.
  • “In the field”: Hier wird auf Basis von echten Nutzer-Daten die Geschwindigkeit gemessen. Ruft ein Nutzer die Website auf, fließt genau diese Ladegeschwindigkeit in die Daten ein. Diese Daten werden mittels JavaScript auf der eignen Website gemessen. Oder man verwendet Tools, die auf die Chrome-API zugreifen, die wiederum die Daten für einen Teil der Nutzer misst.

Im Labor können Websites und Teile von getestet werden, wenn neue Features und Funktionen geplant sind. So kann man vor dem Live-Betrieb noch Potentiale entdecken und diese optimieren. Wichtig ist es aber, diese Funktionalitäten auch direkt bei Nutzern zu testen. Denn: Nutzer sind mit unterschiedlichen Geräten und Internetverbindungen unterwegs. Daher kann der Pagespeed für viele Nutzer variieren. Auch ist es somit möglich, dass die Labor- und Feld-Daten unterschiedlich ausfallen. Das ist aber ganz normal. Labor-Daten sollten als Grundlage für Verbesserungen dienen, während Feld-Daten zur Erfolgskontrolle eingesetzt werden.

Auch können aufgrund Content-Personalisierungen unterschiedliche Ladezeiten entstehen. Diese Unterschiede erfassen Labor-Tools eher weniger. Aus diesem Grund ist für die Pagespeed-Messung das Real User Monitoring (RUM) extrem wichtig. Behalte daher folgendes im Hinterkopf:

  • Eine Seite kann für einen Nutzer schnell laden, aber für einen anderen Nutzer langsam.
  • Zwei Seiten können exakt gleich lange für das vollständige Laden benötigen. Der Seitenaufbau einer Seite kann sich jedoch schneller anfühlen.
  • Eine Seite kann zwar schnell fertig laden, aber die Interaktionen mit der Seite können langsam sein.

Pagespeed-Kennzahlen

Bei Pagespeed-Kennzahlen herrscht immer wieder Verwirrung. Grund dafür sind die verschiedenen Tools und die unterschiedlichen Kennzahlen, die daraus entstehen. Wichtig ist zunächst zu verstehen, dass sich Pagespeed nicht an einer einzigen Kennzahl vollständig messen lässt. Die Nutzererfahrung an nur einem Zeitpunkt zu messen und als Indikator für einen guten oder schlechten Pagespeed heranzuziehen, ist keine gute Idee. Um wichtige Kennzahlen abzuleiten muss man auch immer den Unterschied zwischen “Lab data” und “Field data” im Hinterkopf behalten.

Bei den “Labor-Tools” kommen oft die nachfolgenden Kennzahlen zum Einsatz. Nicht alle sind direkt Pagespeed-Metriken, die als Zeit wiedergegeben werden. Zahlen wie “Anzahl HTTP-Requests” sind mit Vorsicht zu genießen. Ein hohe Anzahl von HTTP-Requests muss nicht immer negativ sein. 5 Requests mit je 5 MB könnten länger zum Laden brauchen als 10 Requests mit je 10 KB. Auch ist die Anzahl der HTTP-Requests seit HTTP/2 kein großes Problem mehr.

  • Time to Frist Byte: Time to Frist Byte ist die Zeit, die benötigt wird, bis das erste Byte vom Server an den Browser übertragen wird.
  • DOMContentLoaded: Das DOMContentLoaded-Event wird ausgelöst, sobald das DOM steht. Externe Ressoucen wie CSS, Bilder und Frames sind noch nicht geladen.
  • load: Das load-Event wird ausgelöst, sobald eine Ressource und die von ihr abhängigen Ressourcen das Laden beendet hat. Hier sind also auch alle externen Ressourcen wie CSS, Bilder und Frames geladen. Nachteil ist, dass nach dem load-Event dennoch Ressourcen im Hintergrund laden und somit die Interaktion mit der Seite beeinträchtigen können.
  • Page Size: Dies ist die Gesamtgröße der Seite in Megabyte. Dies ist keine direkte Pagespeed-Kennzahl, kann aber ein Indikator sein, warum eine Seite langsam lädt.
  • Anzahl HTTP-Requests: Siehe Anmerkungen oben.

Bei den Kennzahlen, die auf “Feld-Daten” basieren, unterteilt web.dev die Pagespeed-Kennzahlen zunächst in folgende Kategorien:

  • Wahrgenommene Ladegeschwindigkeit: Hier geht es darum wie schnell alle visuellen Elemente laden und auf dem Bildschirm gerendert werden.
  • Interaktionsfähigkeit: Wie schnell kann die Website alle erforderlichen JavaScript-Dateien laden, damit alle Elemente auf Benutzereingaben reagieren können?
  • Reaktionsfähigkeit: Wie schnell kann die Seite auf Benutzereingaben reagieren?
  • Visuelle Stabilität: Gibt es Elemente auf der Website, die sich während dem Ladevorgang z.B. verschieben und dadurch die Interaktionsfähigkeit beeinträchtigen?
  • Reibungsloser Ablauf: Fließen Übergänge flüssig von einem Zustand zum anderen?

Daraus ergeben sich folgende Metriken:

  • First contentful paint (FCP)
  • Largest contentful paint (LCP)
  • First input delay (FID)
  • Time to Interactive (TTI)
  • Total blocking time (TBT)
  • Cumulative layout shift (CLS)

Wenn du mehr über diese Kennzahlen erfahren möchtest, dann empfehle ich dir meinen Betrag “User-centric Performance Metrics”. Wem das an dieser Stelle nicht genug ist und noch genauere Kennzahlen, angepasst auf die eignen Bedürfnisse, braucht, hat die Möglichkeit auch eigene Kennzahlen zu definieren. Dies ist über folgende APIs möglich:

Zudem wurden am 5. Mai 2020 die Web Vitals vorgestellt anhand derer man die User Experience einer Seite messen kann. Dabei geht es um die Kennzahlen LCP, FID und CLS.

In the lab: Tools

Eins vorab: Empfehlungen von Pagespeed-Tools sollten als erste Indikatoren für mögliche Optimierungen angesehen werden. Die Empfehlungen sollten im zweiten Schritt mit den technischen Möglichkeiten der jeweiligen Website abgeglichen werden.

In der Webdeveloper Console lässt sich der Pagespeed einer Seiten ebenfalls gut analysieren. Dazu wechselt man z.B. im Chrome mit F12 in die Developer Tools und wählt dann den Tab “Performance”. Nach einem Reload der Seite wird ein Chart angezeigt mit verschiedenen Farben:

  • Grün: Zeitpunkt, wo das erste Pixel ausgegeben wird (First Paint).
  • Blau: Der Parser hat das Dokument verarbeitet und das DOM steht bereit (DOMContentLoaded). Ab hier kann JavaScript auf alle Elemente zugreifen. Bilder und CSS können hier noch fehlen.
  • Rot: Dokument ist fertig inkl. Bilder und CSS (Load).

In the field: Tools

Möchte man echte Nutzer-Daten für die Pagespeed-Bewertung heranziehen eignet sich Google Analytics mit Google Tag Manager z.B. sehr gut. Eine Anleitung dazu findest du ebenfalls in meinem oben schon verlinkten Beitrag “User-centric Performance Metrics”.

Pagespeed-Optimierung

Vorab: Pagespeed-Optimierung ist kein Projekt! Jede Anpassung und Erweiterung auf der Website muss aus Pagespeed-Sicht erneut geprüft werden. Betrachte Pagespeed-Optimierung als Prozess und behalte die Website-Entwicklung auf dem Schirm, um rechtzeitig reagieren zu können.

  • Bilder
  • Webfonts
  • CSS
  • JavaScript
  • Server
  • Quellcode
  • Sonstige Optimierungen

Bilder

Bilder sind der größte Optimierungshebel. Die Optimierung der Ladegeschwindigkeit wird hier näher beleuchtet.

Webfonts

Mehr dazu findest du hier.

CSS

CSS blockiert standardmäßig das Rendering, da ohne CSS die Webseite nicht richtig dargestellt werden kann. Es gibt jedoch verschiedene Methoden wie man CSS optimieren kann. Ziel ist es dabei, dass der Nutzer nicht lange warten muss, bis er ein optisches Feedback der Webseite erhält.

Zusammengefasst kann man sagen, dass CSS in 2 Bereiche gegliedert werden sollte: Style-Angaben für den sichtbaren Bereich (Above-the-Fold) sollen unbedingt sofort und bevorzugt geladen werden. Style-Angaben, die erst später gebraucht werden (Below-the-Fold) können später geladen werden. Hier spricht man auch von der Optimierung des kritischen Rendering-Pfads.

Die wichtigsten CSS-Optimierung sind:

Inline CSS
Dabei geht es darum, dass man Style-Angaben nicht in eine eigene CSS-Datei schreibt, sondern direkt ins HTML. Vorteil ist, dass hier keine extra Ressource beim Server angefragt werden muss. Die Angaben werden direkt im HTML mitgegeben. Nachteil ist, dass das HTML größer wird und dass Style-Angaben innerhalb von HTML nicht gecached werden können. Daher sollte Inline-CSS nur für den sofort sichtbaren Bereich eingesetzt werden (Above-the-Fold). Zudem sollte hier beachtet werden, dass der kritische Rendering-Pfad nicht größer sein darf als 14 KB. 14 KB kann max. innerhalb des ersten Roundtrips mitgegeben werden. Das CSS sollte daher so schlank wie möglich gehalten werden, da noch HTML und JS innerhalb von 14 KB passen muss.

Verlagertes CSS
Alle weiteren CSS-Angaben, welche nicht für Above-the-Fold benötigt werden, kommen in eine eigene CSS-Datei. So stellt man sicher, dass der kritische Bereich nicht ein großes Stylesheet laden muss.

Wichtig hierbei ist, dass max. 1 oder 2 CSS-Dateien angelegt werden, da jedes CSS dabei einen HTTP-Request erzeugt, was den Ladevorgang verlangsamt (bis HTTP/2). Sollten mehrere CSS-Dateien existieren, sollten diese zusammengefasst werden. Da CSS dateiunabhängig ist, kann man per Copy&Paste alles in eine Datei packen.

@Imports vermeiden
Die @Import-Funktion innerhalb von CSS-Dateien ermöglicht, dass weitere CSS-Dateien integriert werden können. Dies verursacht jedoch einen weiteren HTTP-Request. Sprich: CSS-Dateien sollen wirklich zusammengefasst und nicht per @Import integriert werden. Es soll jedoch zukünftig eine HTML-Imports-Funktion geben, die die Integration ohne Blockierung des Rendering-Prozesses unterstützen soll.

CSS3 anstelle von Grafiken
Grafiken, die keine Fotos sind, können mit CSS erzeugt werden. Ein Button sollte z.B. besser mit CSS definiert werden, anstatt eine Bild-Datei dafür zu benutzen.

JavaScript

Wie CSS blockieren auch JavaScript-Dateien standardmäßig das Rendering. Hauptgrund ist, das JS die Seite im Nachhinein verändern kann. Daher muss auf diese Dateien gewartet werden. Entscheidend ist hier die Position des Skripts im HTML-Code. Wenn im Above-the-Fold-Bereich keine Skripte geladen werden müssen, beschleunigt dies den Seitenaufbau. Hier kann man dann die Skripte in den Footer verschieben und später laden lassen.

Inline JavaScript
JS-Inhalte, die für Above-the-Fold benötigt werden, können – wie CSS – Inline im Head-Bereich geladen werden. Dieser Teil muss sehr klein sein, um in den ersten Roundtrip von 14 KB zu passen.

Verlagertes JavaScript
JS, welches nicht für Above-the-Fold gebraucht werden, sollte ganz am Ende des Dokuments laden. Einen ähnlichen Effekt bekommt man mit den Attributen “async” und “defer”:

  • Async: Das Skript wird nicht genau an der eingebundenen Stelle ausgeführt. Es ladet parallel zum Seitenaufbau, ohne diesen zu blockieren und wird darauffolgend ausgeführt.
  • Defer: Das Skript wird erst am Ende ausgeführt. Es ladet parallel zum Seitenaufbau, ohne diesen zu blockieren und wird am Ende des Ladeprozesses ausgeführt.

Die Herausforderung ist, dass JS-Skripte asynchron oder verlagert geladen werden ohne die Funktionalität der Seite einzuschränken.

Wie bei CSS sollten auch JS-Dateien zusammengefasst werden, um die Requests zu minimieren. Hier ist das aber nicht so leicht, da es Abhängigkeiten gibt, die dazuführen können, dass die Seite nicht korrekt dargestellt wird.

Server

Time to First Byte
“Time to Frist Byte” ist eine Kennzahl und beschreibt die Zeit, die benötigt wird, bis das erste Byte vom Server an den Browser übertragen wird. Laut Google sollte dies in max. 200 ms stattfinden. Grund: Dauert dies zu lange, nimmt der Bot an, dass der Server Probleme hat. Daraufhin kann der Crawling-Prozess zunächst abgebrochen werden. Laut Google wären Werte über 1.000 ms zu hoch.

Sollte die “Time to Frist Byte” zu hoch sein, können folgende Fragen helfen Probleme zu identifizieren:

  1. Wie stark ist der Server durch den Traffic belastet (Serverlast)?
  2. Ist die Server-Software optimal konfiguriert?
  3. Wie ist die Hosting-Leistung bzw. auch die Leistung der Gesamt-Hardware?

Bei Punkt 1 kommt es darauf an wie groß die Seite ist (Anzahl Datenbankabfragen im Hintergrund, Belastung Server, etc.). Bei Punkt 2 geht es um Einstellungen des Servers (Caching, Keepalive, etc.). Bei Punkt 3 sollte man sich Gedanken um ein besseres Hosting machen (z.B. Shared-Hosting vermeiden).

Server-Caching
Server-Caching hat das Ziel, dass weniger Daten aus der Datenbank beim Aufruf einer Seite abfragt werden müssen. Befindet sich also eine Seite im Server-Cache muss der komplexe Abfragenprozess nicht komplett durchlaufen werden.

Jedoch muss man beachten, dass man den Server-Cache löscht und neu erstellt, wenn sich Daten auf der Website ändern. Zudem sollte man prüfen, ob es Bereiche auf der Website gibt, die man lieber nicht cachen sollte. Beispiel: Conversion-Funnels bzw. -Prozesse wie Formulare, etc.

Keepalive
Keepalive teilt dem Server mit, dass die Verbindung am Leben erhalten werden soll. Dabei werden für die gleiche TCP-Verbindung mehrere Anfragen zugelassen, anstatt bei jeder Anfrage eine neue Verbindung aufzubauen. Wie findet man heraus ob Keepalive aktiv ist? Dazu ruft man die Seite auf und wechselt in die Developer Tools. Im Tab “Network” wählt man das Dokument aus. Es öffnet sich rechts ein Feld mit verschiedenen Angaben. Im Bereich “Response Headers” sollte “Connection: keepalive” stehen. Falls Keepalive nicht aktiviert ist, kann man mittels folgenden Codes in der .htaccess-Datei dies aktivieren:

<ifModule mod_headers.c>
Header set Connection keep-alive </ifModule>

GZip
Hierbei werden Datenmengen verkleinert und somit an Größe gespart, was zu einer schnelleren Ladezeit führt. Um zu testen, ob Gzip aktiv ist, ruft man sie Seite auf und wechselt in die Developer Tools. Im Tab “Network” wählt man das Dokument aus. Es öffnet sich rechts ein Feld mit verschiedenen Angaben. Im Bereich “Response Headers” sollte “Content-Encoding: gzip” stehen. Wenn nicht, kann man dies mit folgendem Code aktivieren:

# Enable gzip compression.
# Default: off
gzip on;

Quellcode

Für den Quellcode gilt allgemein: Nur was notwendig ist rein. Unnötige Angaben und Meta-Angaben raus nehmen.

Sonstige Optimierungen

Browser-Caching
Wichtig: Server- und Browser-Caching nicht verwechseln. Beim Server-Caching werden gecachte Daten auf dem Server abgelegt, während Browser-Caching direkt auf dem Client stattfindet.

Jedes mal wenn eine Seite angefordert wird, werden die benötigten Ressourcen vom Browser geladen. Beim Caching geht es darum, das sich der Browser diese Ressourcen merkt. Wenn ein Nutzer zum zweiten Mal eine Ressource aufruft, braucht der Browser nicht mehr lange zum Laden der Ressource, da er die Ressourcen schon kennt. Daher ist der First View immer langsamer als der Repeat View. Wie funktioniert das? Beim ersten Aufruf speichert der Browser wichtige Dateien selbst ab, sodass beim nächsten Aufruf nicht alles neu geladen werden muss. Wie lange der Browser diese Dateien beibehalten darf, hängt von den Einstellungen ab, die man vornimmt. Dabei sind für unterschiedliche Dateien unterschiedliche Cache-Zeiten sinnvoll. Bilder können bspw. eine lange Cache-Zeit haben (1 Jahr), da sie in der Regel nicht oft ausgetauscht werden und gleich bleiben. Je länger die Caching-Zeit umso besser. Aber auch kurze Cache-Zeiten (z.B. für oft geändertes CSS) sind sinnvoll. Falls aber lange Cache-Zeiten angegeben worden sind und man doch eine Änderung braucht, so kann man mit URL-Fingerprinting arbeiten. Wie das aussieht und mehr Informationen zu Caching findest du in meinem Beitrag zu HTTP-Caching.

Caching wird in der Serverkonfigurationsdatei oder in .htaccess aktiviert. Ein beispielhafter Code:

ExpiresActive On
ExpiresByType image/png "access 3 month"
ExpiresByType image/jpg "access 3 month"
ExpiresByType text/css "access 2 month"
ExpiresDefault "access 1 month"

Minification
Bei Minifizierung geht es darum, Dateien in kleinstmöglichen Größe zu speichern. Beim Minifizierungsprozess werden bspw. Leerzeichen und Zeilenumbrüche entfernt. Dadurch wird die Datei kleiner.

CSS-Tools, die dabei helfen:

  • CSS Nano: https://github.com/ben-eb/cssnano
  • CSSO: https://github.com/css/csso
  • https://unused-css.com/
  • https://csscompressor.com/
  • https://cssminifier.com/

JS-Tools, die dabei helfen:

  • Uglify: https://github.com/mishoo/UglifyJS
  • Google Closure Compiler: https://developers.google.com/closure/compiler/
  • http://refresh-sf.com/
  • https://jscompress.com/

Einfacher geht es mit Build-Tools wie Grunt oder Gulp, wo man den Prozess automatisieren kann (mit Funktionen wie gulp-minify oder gulp-uglify).

Weiterleitungen und Weiterleitungsketten
Bei Weiterleitungen wird von Browser ein Dokument angefragt, welches nicht mehr existiert. Der Server antwortet, indem er sagt, unter welchen neuen URL die ursprüngliche Seite erreichbar ist. Daraufhin sendet der Browser an den Server wieder eine Anfrage. Der Server antwortet nun mit der Ziel-URL. Diese doppelte Kommunikation kostet Zeit. Kritisch wird es, wenn Weiterleitungsketten vorhanden sind und die angefragte, ursprüngliche URL mehrmals weitergeleitet wird. Im mobilen Bereich kann eine Weiterleitung schon bis zu 2 Sekunden Zeit kosten. Hier sind die Kommunikationsschritte stark von der Latenz des Netzwerks abhängig, weshalb es hier zu deutlich höheren Wartezeiten kommen kann. Weiterleitungen betreffen aber nicht nur HTML-Dokumente. Auch bei Bildern, CSS- und JavaScript-Dateien (und allen anderen Requests) sollten Weiterleitungen vermieden werden.

DNS-Lookup
Bei der Eingabe einer Domain in die Adresszeile des Browsers muss diese zunächst in eine IP-Adresse umgewandelt werden. Für jede Ressource, die angefragt wird, muss dieser DNS-Lookup durchgeführt werden. Wenn viele verschiedene Domains angefragt werden, kann das die Ladezeit der Webseite erhöhen.

Die Anzahl der DNS-Lookups sollte genau unter die Lupe genommen und Unnötige beseitigt werden. Vor allem im Above-the-Fold-Bereich sollten nach Möglichkeit so wenig wie möglich DNS-Lookups durchgeführt werden.

HTTP-Requests
Browser können max. 8 Requets pro Domain gleichzeitig ausführen. Müssen mehr Dateien übertragen werden, müssen diese warten. Daher macht es Sinn, Dateien zusammenzufassen. Hier muss man aber bedacht vorgehen. Wird das komplette CSS in eine Datei verschoben, dann ladet dieses CSS auf allen Seiten. Bei einigen Seiten kann es aber sein, dass nicht alle CSS-Angaben notwendig sind. In diesem Fall kann es sinnvoll sein, dass man CSS je Seitentyp oder Template erstellt.

Bez. HTTP-Requests muss aber auch gesagt werden, dass mit der Einführung von HTTP/2 das Thema nicht mehr so relevant ist.

Subdomains einsetzen
Um das eben genannte Request-Problem zu umgehen, wurde in der Vergangenheit auf Subdomains gesetzt. Denn: Die Beschränkung gilt nur pro Domain. Ladet man z.B. seine Bilder, CSS- und JS-Dateien über Subdomains können gleichzeitig mehr als 8 Requests durchgeführt werden. Bei einer Hauptdomain und 2 Subdomains können also 24 Requests gleichzeitig durchgeführt werden.

Mit HTTP/2 ist dies aber auch nicht mehr relevant.

Bad Requests vermeiden
Mit “Bad Requests” meint man 404-Fehler-Codes. Auch bei diesen Seiten muss der Server-Client-Kommunikationsprozess durchlaufen werden. Daher sollte man Ausschau nach intern kaputten Links, CSS- und JS-Dateien halten und diese korrigieren.

Content Delivery Network (CDN)
Mit einem CDN wird die eigene Website auf verschiedene Server auf verschiedenen Standorten verteilt. Greift ein Nutzer aus den USA auf die Website, wird im diese nicht aus Deutschland, sondern aus den USA ausgeliefert.

Achtung: Wechselwirkungen

Bei der Pagespeed-Optimierung sollte man auch die möglichen Wechselwirkungen von einzelnen Optimierungen beachten. Man sollte daher nicht jede Optimierung um jeden Preis durchführen. Beispiele von Wechselwirkungen:

  • Etwas oben bin ich kurz auf das Inlining von CSS eingegangen. Da CSS standardmäßig render-blocking ist, wird oft empfohlen, dass man das komplette CSS im HTML-Code Inline platziert. Dadurch spart man sich einen Request. Dadurch können sich Werte wie First Contentful Paint verbessern. Auf den ersten Blick wirkt das positiv. Man muss jedoch beachten – wie oben schon erwähnt – dass Inline-CSS nicht gecached werden kann. Ruft der Nutzer eine zweite Seite auf, muss das gesamte Inline-CSS wiederholt heruntergeladen werden.
  • Das eben genannte Problem könnte man umgehen, indem man nur CSS, welches für Above-the-Fold notwendig ist, als Inline-CSS definiert und den Rest per JS nachlädt. Ein Teil bleibt also weiterhin “cachbar”. Jedoch kann das zu FOUT, also “Flash of Unstyled Content” führen.

Man muss also Optimierungen immer auch von der 2. Seite beleuchten und abwägen, was tatsächlich aus Nutzer-Sicht Sinn macht.

Demir Jasarevic
Ich bin Analytics Developer und Marketing Tracking Analyst. Spezialisiert auf UA, GA4 und GTM. In meiner Freizeit sammle ich NBA-Trikots.

    Keine Kommentare möglich.

    ↑