Mobile Ladezeiten-Optimierung: Bessere Rankings durch schnelle Ladezeiten

Beitrag aus Ausgabe 65 / April 2017
SEO
Thorsten Abrahamczik

Thorsten Abrahamczik arbeitet als Senior-Online-Marketing-Manager bei der internetwarriors GmbH. Er ist auf die Bereiche Suchmaschinen-Optimierung und Webanalyse spezialisiert und für deren fachliche Führung verantwortlich.

Google rief bereits 2015 das mobile Zeitalter aus, als erstmals mehr Suchanfragen über mobile Endgeräte gestellt wurden als über Desktops und Tablets. Eine gezielte Optimierung der Ladezeit hilft dabei, das SEO-Ranking zu verbessern und zusätzliche Besucher auf die Website zu lotsen.

Im September 2016 veröffentlichte DoubleClick eine Studie, nach der die durchschnittliche Ladezeit einer mobilen Webseite über das 3G-Funknetz 19 Sekunden betrug. Als Grundlage der Untersuchung dienten mehr als 10 000 mobile Webseiten, bei denen die Seitenaufrufe gemessen worden waren (https://goo.gl/a3g4J5 [Seite nicht mehr verfügbar]). Darüber hinaus hielt die Untersuchung fest, dass 53 % der Seitenaufrufe abgebrochen wurden, wenn die Ladezeit einer Webseite länger als 3 Sekunden betrug.

DoubleClick beobachtete weiterhin, dass Webseiten, die innerhalb von 5 Sekunden laden, doppelt so viel Ad Revenue generierten, als Webseiten, die 19 Sekunden laden. Die Ladezeit hat also nicht nur Einfluss auf die Besucherzahl einer Webseite, sondern auch auf die Interaktionen von Usern mit der Webseite und schlussendlich auch auf die darüber generierten Conversions.

Diese und viele weitere Studien bestätigen, was Google bereits vor zwei Jahren ankündigte: User leben und arbeiten mobil. Eine weitere generell gültige Erkenntnis ist, dass User sich daran gewöhnt haben, schnell und einfach im Internet zu navigieren. Alles muss so zügig stattfinden, dass es egal ist, ob der User eine App auf dem eigenen Computer, Tablet oder Smartphone bedient. Eine Unterscheidung in Bezug auf die Ladezeit von Internetkonsum und normalem Computererlebnis (ohne Internetbezug) darf es nicht mehr geben. Webseiten müssen schnell laden und Inhalte leicht zu finden sein. Dauert das Surferlebnis zu lange, bricht der User ab.

Das Thema Ladezeit ist aus diesem Grund für Webseitenbetreiber aktueller denn je.

Auswirkungen von längeren Ladezeiten anhand zweier prominenter Beispiele

Wie sehr sich eine minimale Veränderung der Ladezeit in der Anzahl der Conversions auswirken kann, zeigten Amazon und Google im Jahr 2012. Laut der von FastCompany veröffentlichten Ergebnisse (https://goo.gl/0oNd3q) müsste Amazon Einbußen in Höhe von 1,6 Milliarden Dollar pro Jahr hinnehmen, würde die Ladezeit der Webseite nur um eine Sekunde steigen. Die Auswirkungen wären 2017 vermutlich deutlich stärker.

Derselbe Bericht führte Googles Berechnung an, dass die Erhöhung der Seitenladezeit der Suchergebnisseite um 0,4 Sekunden zu 8 Millionen weniger Suchanfragen pro Tag führt. Diese fehlenden Suchanfragen wären für Google sicherlich einfacher zu verkraften, würde das Unternehmen nicht mit AdWords-Anzeigen Geld verdienen. Vor diesem Hintergrund ist es nachvollziehbar, dass Google daran interessiert ist, möglichst viele Suchanfragen zu erhalten, und dass es einen sehr starken Fokus auf schnell ladende Webseiten legt. Die Funktionalität „Google Instant“, wie in Abbildung 1 sichtbar, ist nur ein Beispiel kontinuierlicher Verbesserungen der Suchmaschine.

Was bedeutet der Begriff „schnelle Ladezeit“ eigentlich?

Die Ladezeit einer Webseite wird in der Regel mit zwei Verfahren überprüft:

  1. Es wird die tatsächliche Ladezeit der Seite gemessen. Das heißt, es wird untersucht, wie lange es dauert, bis alle Inhalte vom Browser geladen und angezeigt werden.
  2. Es wird die subjektive Ladezeit überprüft. Hierbei wird primär untersucht, wie lange es dauert, bis der User erste Inhalte der Webseite sieht. „Erste Inhalte“ bezieht sich vor diesem Hintergrund auf sämtliche Inhalte „above the Fold“, also Inhalte, die ohne Scrollen sichtbar sind.

Diese zwei Werte können sich sehr stark unterscheiden und die Empfindungen des Users deutlich beeinflussen. Braucht eine Webseite lange zum Laden, kann es sich durchaus lohnen, die subjektive Ladezeit der Webseite zu optimieren. Auf diese Weise sieht der User schnellstmöglich Inhalte und bemerkt kaum, dass die Seite noch nicht vollständig geladen wurde.

Google selbst geht davon aus, dass der User ein langsames Smartphone und eine verhältnismäßig langsame Internetverbindung (3G) besitzt (https://goo.gl/hWeS8p). In diesem Fall muss die Webseite trotzdem schnell laden und angezeigt werden, insbesondere der „above the Fold“-Teil. Der Vorteil einer mobilen Ladezeit-Optimierung besteht darin, dass in aller Regel auch die Desktop-Version der Webseite von den umgesetzten Maßnahmen profitiert. Das gilt insbesondere dann, wenn die Webseite im responsiven Design umgesetzt ist.

Responsive Design: Bei Responsive Design wird eine Webseite so programmiert, dass sie bei jedem Seitenaufruf Medienabfragen durchführt, um die Größe des Browserfensters zu ermitteln. Abhängig von dieser Größe wird das Layout anders dargestellt. Responsive Design ist eine gängige Methode, um Webseiten für Mobilgeräte zu optimieren.

Typische Auslöser für eine hohe Ladezeit

Generell gibt es sehr viele Auslöser für eine hohe Ladezeit. Die drei Hauptgründe sind jedoch:

  1. Anzahl der Serveranfragen: Um die Webseite in Gänze anzeigen zu können, muss der Browser sehr viele Dateien bei unterschiedlichen Webservern anfragen. Je mehr Anfragen gestellt werden, desto länger brauchen die Server, um alle Inhalte zu liefern. Drei einfache Beispiele für unterschiedliche Webserver bei einem einzelnen Ladevorgang sind:
    • der eigene Server, auf dem die Domain mitsamt allen Daten liegt,
    • der Google-Analytics-Server, über den Google Analytics ausgeführt wird,
    • der Google-Server für die Schriftenverwaltung von Google Fonts, um spezielle Schriftarten auf der Webseite anzeigen zu können.
  2. Reihenfolge der geladenen Elemente: Häufig werden unwichtige Inhalte der Webseite zuerst geladen, weil sie im <head>-Bereich des Quellcodes hinterlegt sind. Dies sind z. B. JavaScript-Dateien, die für eine Webseitenfunktionalität im Footer der Webseite relevant sind, z. B. ein Newsletter-Anmeldeformular. Erst danach werden für den User relevante Informationen vom Server übermittelt, vom Browser verarbeitet und angezeigt. Wichtige Inhalte sind dagegen Texte, Bilder etc., die dem User eine unmittelbare Interaktion mit der Webseite ermöglichen.
  3. Dateigrößen: Sehr häufig sind Dateien viel zu groß in der Webseite hinterlegt. Dies kann bei HTML, CSS und JavaScript-Dateien anfangen und bei Bildern enden. Überprüft man Webseiten mit externen Tools, ist häufig zu lesen, dass die Größe der Bilder um mehrere Megabyte reduziert werden kann, was zu deutlichen Ladezeitverbesserungen führt. Überarbeiten Webseitenbetreiber ihre Bilder, lassen sich für den User in der Regel keine Qualitätsunterschiede erkennen, obwohl die Dateigröße signifikant verringert wurde.

Wie misst Google die Ladezeit von Webseiten?

In diesem Artikel werden zwei Möglichkeiten der Ladezeitmessung behandelt, die beide in direktem Zusammenhang mit Google stehen. Beide Tools werden von Google empfohlen und geben umfassende Informationen zur Optimierung.

Google PageSpeed Insights

Das wohl bekannteste Tool zur Überprüfung der Ladezeit ist der Google-PageSpeed-Test (siehe Abbildung 2). Nach der Eingabe der URL überprüft das Programm zweimalig die Webseite. Während der ersten Überprüfung wird die Webseite unter mobilen Aspekten betrachtet, während sie in der zweiten Überprüfung unter Desktop-Aspekten untersucht wird. Im Anschluss werden für beide Untersuchungen die Ergebnisse auf einer Skala von 0 bis 100 ausgegeben. Je höher der Wert liegt, umso performanter und leistungsstärker ist die Webseite. Ein Wert von 85 weist auf eine sehr performante Webseite hin.

Weil die Ladezeit stark von der Internetverbindung des Users abhängt, untersucht das Tool nur die technischen Aspekte einer Webseite. Diese sind unabhängig von der Internetverbindung zu ermitteln und können daher ein sehr genaues Ergebnis liefern.

Zusätzlich zu den genutzten Technologien untersucht das Tool zwei weitere Aspekte:

  1. Erforderliche Zeit zum Laden des ohne Scrollen sichtbaren Inhalts: Dies gibt die Zeit von der Anfrage der Webseite durch den Browser bis zur Anzeige aller Inhalte an, die ohne Scrollen zu sehen sind.
  2. Erforderliche Zeit zum vollständigen Laden der Seite: Hierbei wird die Zeit von der ersten Anfrage bis zur vollständigen Anzeige der Webseite gemessen.

Obwohl in beiden Fällen die vergangene Zeit gemessen wird, erhält der Anwender kein Ergebnis in Sekunden. Gerade der erste Aspekt „Erforderliche Zeit zum Laden des ohne Scrollen sichtbaren Inhalts“ hat jedoch einen starken Einfluss auf die gefühlte Ladezeit.

Nachdem das Ergebnis ermittelt und angezeigt wurde, erhalten die User zusätzlich Informationen darüber, in welchen Bereichen die Performance und Ladezeit der Webseite weiter verbessert werden können. Hierbei gibt es die drei Kategorien Rot, Gelb und Grün. Bei der roten Kategorie sind messbare Verbesserungen zu erwarten, bei der gelben Kategorie können Empfehlungen umgesetzt werden, wenn sie nicht zu aufwändig sind. Bei der grünen Kategorie wurden keine Probleme aufgedeckt.

Dennoch sind die Ergebnisse mit einer guten Portion gesunden Menschenverstands zu beurteilen. Teilweise treten Szenarien auf, in denen unbedingt die Dateigröße von 23 Bildern verbessert werden soll. Durch die Optimierung dieser Bilder erwartet der PageSpeed-Test jedoch in Summe nur eine Einsparung von 40 Kilobyte. Ob diese Optimierung sinnvoll und nicht zu aufwändig ist, muss jeder Webseitenbetreiber für sich entscheiden.

WebPagetest.org

Bei dem zweiten Tool WebPagetest.org handelt es sich um eine Open-Source-Software, die ursprünglich von AOL entwickelt wurde, inzwischen aber primär durch Google weiterentwickelt wird. Durch den weltweiten Einsatz bei führenden Hosting- und CDN-Betreibern kann das Tool schnelle und realitätsnahe Tests durchführen. Der Anwender kann vor dem Test auswählen, für welche Region er die Tests durchführen möchte, da die Ladezeit, abhängig von der geografischen Entfernung des Servers zum Heimatland, Unterschiede aufweisen kann. Allein für Deutschland gibt es drei Testserver, die Webseitenanfragen aus dem deutschsprachigen Raum abdecken können.

Kurz erklärt: CDN

Content Delivery Networks sind Netzwerke weltweit verteilter Webserver. Liegt eine Webseite in einem CDN, kann die Webseite schneller an den User ausgespielt werden, weil der geografisch nächstliegende Webserver dem User die Webseite liefert. Gerade international agierende Unternehmen nutzen dieses Angebot.

Nach der Eingabe der Webseiten-URL und der Auswahl des Testservers beginnt die Überprüfung der Webseite. Hierbei wird die Webseite in drei Durchgängen vom Tool angefragt und untersucht. Auf diese Weise kann das Tool überprüfen, inwiefern bestimmte Technologien wie Browser-Caching einen wirklichen Nutzen auf die Ladezeit haben. Im Anschluss erhält der User die Testergebnisse der drei Durchläufe, wie in Abbildung 3 dargestellt, in einem Wasserfall-Diagramm angezeigt. Mit diesem Diagramm kann der User genau sehen, welche Dateien zu welchem Zeitpunkt des Ladevorgangs angefragt wurden, wie lange es dauerte, die einzelnen Dateien zu laden, und wann sie angezeigt wurden. Ebenfalls zeigt das Diagramm, wann die Webseite vollständig geladen wurde. Eine Unterscheidung nach mobil und Desktop gibt es jedoch nicht.

Darüber hinaus liefert das Tool in verschiedenen zusätzlichen Auswertungen viele weitere Informationen. So kann z. B. leicht kontrolliert werden, wie viele Hosts (Webserver) angefragt werden mussten, um sämtliche relevanten Daten zu laden. Ebenfalls gibt es eine genaue Aufschlüsselung des prozentualen Anteils der einzelnen Dateigrößen und -arten. Abschließend findet eine ähnliche Auswertung wie bei dem Google-PageSpeed-Test statt, in der die genutzten Technologien auf einer Skala von 0 bis 100 beurteilt werden.

Insgesamt ist WebPagetest.org ein komplexeres und dadurch auch etwas komplizierteres Tool. Allerdings liefert es deutlich genauere Auswertungen als der PageSpeed-Test und ermöglicht eine detailliertere Analyse der Ladezeit.

Praktische Tipps zur Optimierung der Ladezeit

Um die Ladezeit der Webseite zu verbessern, gibt es im Wesentlichen drei Bereiche, in denen Überarbeitungen vorgenommen werden können:

  1. das Content-Management-System,
  2. die einzelnen Dateien der Webseite,
  3. die Webserver-Konfiguration.

Im Folgenden werden alle drei Bereiche besprochen und konkrete Hinweise zu Verbesserungen gegeben. Die Hinweise sind dabei jedoch oberflächlich gehalten, da eine praktische Umsetzung deutlich tiefer ins Detail geht.

Die Optimierung des Content-Management-Systems

Die Optimierung des Content-Management-Systems (CMS) ist sicherlich die einfachste Aufgabe für den Marketer. Durch die leichte Bedienung des Backends können Einstellungen schnell angepasst und Optimierungen entsprechend vorgenommen werden. Gleichzeitig ist dies auch die größte Gefahr bei der Optimierung eines CMS. Veränderungen können allzu schnell vorgenommen werden, sodass Betreiber die Webseite auch „schnell“ deaktivieren (offline nehmen) können. In diesem Fall bekommt der User häufig eine Fehlerseite mit dem Text „Fehler 500 (Internal Server Error)“ angezeigt, die im Wesentlichen aus einer weißen Seite mit der Fehlermeldung besteht. Sämtliche Funktionen der Webseite, wie z. B. das Kontaktformular, funktionieren in diesem Augenblick nicht mehr, selbst wenn ein anderer User die Seite noch nicht neu geladen hat und sie in ihrer Ursprungsform noch vor sich sieht.

Kurz erklärt: Fehler 500

Hierbei handelt es sich um einen standardisierten HTTP-Statuscode, der bei jedem Seitenaufruf übermittelt wird. Bekannte Beispiele sind „200“ für eine erfolgreiche Auslieferung der Webseite, „301“ für permanente Weiterleitungen, „404“ für Fehlerseiten und „500“ für Fehler in der Webserver-Konfiguration.

Für Programmierer bedeutet die Pflege des CMS in der Regel wenig Aufwand. Komplizierter wird es erst, wenn größere Anpassungen vorgenommen werden sollen. Aus diesem Grund sollte die technische Pflege eines CMS immer in der Hand eines Programmierers liegen. Nur auf diese Weise ist sichergestellt, dass es bei Anpassungen im Backend nicht zu Fehlern und Ausfällen der Webseite kommt.

Um ein Content-Management-System im Hinblick auf die Ladezeit zu optimieren, sollten folgende Aspekte immer umgesetzt werden:

  1. Das CMS sollte so wenige Plugins oder Erweiterungen wie möglich nutzen. Plugins stellen nicht nur ein häufiges Sicherheitsproblem dar, sondern jedes Plugin muss zusätzliche Dateien laden und ausführen. Dies führt zu zusätzlichen Serveranfragen und größeren Datenmengen, die an das Endgerät übertragen werden müssen. Beides führt zu einer erheblichen und messbaren Verschlechterung der Ladezeit.
  2. Das CMS sollte immer auf dem aktuellsten Stand sein. Wird eine neue Version des CMS veröffentlicht, sollte diese schnellstmöglich installiert werden. Hierbei gilt es vorab immer zu überprüfen, ob der Webserver das neue System unterstützt oder ob zunächst Anpassungen, wie z. B. eine Aktualisierung der PHP-Version, vorgenommen werden müssen. Ebenfalls muss untersucht werden, ob alle Plugins mit der neuen Version des CMS funktionieren. Obwohl der Prozess anfangs leicht aussieht, sollte er ausschließlich von einem Techniker durchgeführt werden.
  3. Schon bei der Programmierung der Webseite muss darauf geachtet werden, dass Code nicht doppelt programmiert wird. Programmieren zwei oder mehr Entwickler an einer Webseite, kommt es durch fehlende Überprüfung in aller Regel dazu, dass der Code mehrfach programmiert wird. Hierbei handelt es sich keinesfalls um Absicht. Gerade wenn eine Webseite von einem Programmierer übernommen wird und auf Kundenwunsch schnelle Anpassungen vorgenommen werden sollen, hat der Programmierer in der Regel nicht die Zeit, sich in alle Code-Zeilen einzuarbeiten. Aus diesem Grund schreibt er häufig ein neues Stück Code, das durch bestimmte Befehle alle anderen Befehle einer Funktion überschreibt. Abhängig von der Auslastung des Programmierers nimmt er sich im Anschluss nicht die Zeit, den gesamten Code noch einmal zu überprüfen und den geschriebenen Code zu vereinheitlichen. Dies führt zu zwei Problemen:
    1. Es öffnet schnell ungewollte Sicherheitslücken im CMS, durch die das System gehackt werden kann.
    2. Es erhöht die Dateigröße und damit die zu übertragenden Datenmengen.

Ein echter Klassiker für doppelten Code in zu schnell programmierten Webseiten tritt auf, wenn verschiedene Plugins genutzt werden, um die Funktionalitäten der Webseite zu erweitern. Die Plugins benötigen aber teilweise dieselben Dateien, um zu funktionieren, z. B. jQuery (JavaScript-Bibliothek). Werden in diesem Fall durch den Programmierer keine Anpassungen vorgenommen, lädt jedes Plugin sein eigenes jQuery, welches mit dem jQuery eines anderen Plugins identisch ist. In diesem Fall wird also völlig unnötig dieselbe Datei mehrfach geladen.

Die Optimierung einzelner Dateien

Die Überarbeitung einzelner Dateien wurde bereits mehrfach in diesem Artikel erwähnt. Allerdings gibt es viele weitere Stellschrauben, an denen gedreht werden kann, um die Ladezeit von Dateien zu verringern.

Der wohl wichtigste Aspekt ist die Optimierung des „Critical Rendering Path“. Dieser beschreibt den Umgang mit Inhalten, die absolut notwendig sind, um erste Inhalte einer Webseite darzustellen. Nicht alle Dateien müssen geladen und ausgeführt werden, um erste Inhalte anzuzeigen. Der „Critical Rendering Path“ beschreibt also eine sehr gute Lösung zur Verbesserung der subjektiven Ladezeit. Alle weiteren Inhalte sollten, soweit möglich, erst im Anschluss geladen und verarbeitet werden. Wie das geht, erklärt Google sehr ausführlich in seinem Entwicklerbereich (https://goo.gl/x7Annh).

Häufig wird bei der Erstellung einer Webseite allerdings nicht darauf geachtet, nur bestimmte Dateien zu laden. Hierdurch wird der „Critical Rendering Path“ sehr umfangreich und die Ausführung dauert entsprechend länger. Gerade bei einem CMS wie Wordpress, bei dem Webseitenbetreiber schnell Plugins integrieren können, ist dies ein Problem.

Ein Beispiel für die Optimierung des „Critical Rendering Path“ ist, wenn Entwickler eine CSS-Datei in mehrere Einzeldateien aufsplitten. Zukünftig gibt es dann z. B. nur noch eine Datei für die CSS-Befehle auf Smartphones, eine Datei für die CSS-Befehle auf Tablets, eine Datei für CSS-Befehle auf Desktop und eine vierte Datei für alle Layout-Befehle im Druck. Über sogenannte Medienabfragen, die zu Beginn des Ladevorgangs ausgeführt werden, lädt der Browser dann nur die Datei, die für ihn in diesem Augenblick notwendig ist. Die weiteren Dateien, z. B. für den Druck, werden nur genutzt, wenn der User sie wirklich braucht. Hierdurch wird zum einen die Dateigröße weiter verringert (es muss, salopp gesagt, ja nur noch ¼ des gesamten Codes geladen werden) und zum anderen muss der Browser weniger Code verarbeiten, um Inhalte darzustellen.

Darüber hinaus sollten möglichst wenige Serveranfragen gestellt werden. Dies funktioniert auch bei dem gerade erläuterten Beispiel. Obwohl eine einzelne Datei in mehrere Dateien aufgesplittet wird, bleibt es zunächst bei einer einzelnen Serveranfrage, weil die Medienabfrage, z. B. für ein Smartphone, das Laden aller anderen Dateien blockiert.

Programmierer sollten auch darüber nachdenken, bestimmte CSS-Anweisungen oder JavaScript-Funktionen nicht in separate Dateien auszulagern. Dies gilt insbesondere bei kleinen JavaScript-Funktionen, die in separaten Dateien und auf Webservern von Drittanbietern gespeichert sind.

Ein Beispiel hierfür ist JavaScript, das sich um die Darstellung eines Cookie-Hinweises auf einer Webseite kümmert. Die Funktionalität dieses Cookie-Hinweises wird auf absehbare Zeit immer gleichbleiben. In der Regel ist das JavaScript hierfür auch nicht sehr umfangreich. Trotzdem binden manche Entwickler es so ein, dass eine separate Datei von dem Webserver des Anbieters geladen wird. In diesem Fall muss nicht nur eine zusätzliche Datei geladen werden, sondern es kommt erschwerend hinzu, dass der Webserver eines Drittanbieters angesprochen werden muss.

Der Browser muss also erst einmal herausfinden, wie er diesen Server im Internet findet, diesen dann um die Datei bitten und im Anschluss die Datei verarbeiten. Selbst bei einer zügigen Internetverbindung des Users und einer schnellen Antwort des Drittanbieter-Servers kann die zusätzliche Suche des Servers schnell 0,3 Sekunden in Anspruch nehmen. Zur Erinnerung: Google ging 2012 davon aus, dass eine erhöhte Ladezeit um 0,4 Sekunden 8 Millionen Suchanfragen weniger pro Tag verursacht.

Manchmal kann ein CSS oder JavaScript allerdings nicht optimiert werden. Gleichzeitig muss es unbedingt geladen werden und behindert so den „Critical Rendering Path“. In diesem Fall können Programmierer versuchen, die Inhalte asynchron zu laden. Normalerweise lädt ein Browser eine CSS- oder JavaScript-Datei, führt sie aus und geht dann erst zur nächsten Datei weiter. Das heißt, je mehr CSS- oder JavaScript-Dateien verwendet werden, umso länger dauert der Ladevorgang, weil jede Datei den Ladevorgang so lange pausiert, bis die Datei verarbeitet wurde.

JavaScript-Dateien lassen sich aber auch asynchron laden. In diesem Fall wird der Ladevorgang nicht unterbrochen und das Skript wird zu einem späteren Zeitpunkt geladen und ausgeführt. Hierzu wird die Angabe „async“ einfach in den Skript-Aufruf mit eingefügt. Diese Umsetzung liest sich leicht, ist es aber leider nicht immer. Manchmal dürfen bestimmte Skripte nicht asynchron geladen werden, da sie ansonsten die Funktionalität der Webseite negativ beinträchtigen, z. B. weil bestimmte Inhalte nicht angezeigt werden. Der Programmierer muss in diesem Fall genau und in Handarbeit überprüfen, was optimiert werden kann und was nicht.

Neben der bereits besprochenen Optimierung der Dateigröße von Bildern lassen sich auch HTML-, CSS- und JavaScript-Dateien entsprechend optimieren. Beispielweise können leicht alle Leerzeichen oder Kommentare entfernt werden. Gerade bei CSS- und JavaScript-Dateien ist dies ein übliches Vorgehen und reduziert die Dateigröße um mehrere Kilobyte. Entsprechend optimierte Dateien tragen daher immer ein „.min.“ im Namen.

Es gibt viele weitere wichtige Möglichkeiten, die Ladezeit einer Webseite zu verbessern, die den Rahmen dieses Artikels allerdings sprengen würden. Dennoch sollen ein paar bekanntere Beispiele genannt werden:

  • Position von Dateien im Quellcode
  • Nutzung eines Präprozessors wie SASS oder LESS für CSS
  • Lazyload

Abschließend soll noch einmal auf die Optimierung von Bildern eingegangen werden, da diese am einfachsten von Marketern durchgeführt werden kann.

Bei Bildern sollte nicht ausschließlich auf die Dateigröße geachtet werden. Zunächst einmal muss die Frage nach dem richtigen Bildformat beantwortet werden. Generell gibt es kein richtiges Bildformat, da dieses vom jeweiligen Einsatzzweck abhängt. Die zwei populärsten Bildformate im Internet sind „.png“ und „.jpeg“.

PNG-Dateien werden für transparente Bilder oder Bilder mit wenigen Farben verwendet. Aber auch Bilder mit harten Kanten, wie z. B. bei Buchstaben, könnten von dem Format gut dargestellt werden. In diesen Bereichen spielt das PNG-Format seine vollen Stärken aus und ermöglicht sehr kleine Dateigrößen.

Das JPEG-Format wird dagegen für fotorealistische Bilder genutzt. Enthält ein Bild viele Farben, kann es mit dem JPEG-Format stark komprimiert werden, ohne dass der User große Qualitätsunterschiede sieht.

Es gibt aus diesem Grund nicht das eine Bildformat, das alle Bereiche der Ladezeit-Optimierung abdeckt. Stattdessen müssen sich die Webseitenbetreiber und Redakteure Gedanken darüber machen, in welchem Format sie ein Bild abspeichern. In aller Regel werden aber lediglich das Logo der Webseite und transparente Bilder als PNG-Dateien verwendet. Alle anderen Bilder werden häufig aus Praktikabilitätsgründen pauschal als JPEG-Bilder verwendet.

Im nächsten Schritt sollten die Bilder so zugeschnitten werden, dass sie nur noch die maximal notwendige Größe besitzen. Wird ein Bild mit 500px x 300px auf der Webseite angezeigt, sollte es auch nicht größer sein. Leider gibt es immer wieder Webseiten, bei denen an dieser Stelle Bilder mit einer Auflösung von 5 000px x 3 000px verwendet werden. Diese Dateien werden dann in voller Auflösung heruntergeladen und vom Browser auf 500px x 300px verkleinert. Neben der Dateigröße kann dies durch den fehlenden Zuschnitt auch zu qualitativen Problemen in der Darstellung führen, bei denen das Bild nicht mehr ansprechend aussieht.

Gerade beim Zuschnitt eines Bildes ist allerdings auf das responsive Design zu achten. Häufig wird ein Bild in einer bestimmten Größe angezeigt. Verändert sich dann das Layout, weil die Webseite z. B. auf einem Tablet oder Smartphone angezeigt wird, kann es passieren, dass das Bild im Anschluss größer dargestellt wird. Dieser Fall muss unbedingt berücksichtigt werden. Hierfür sollten die Marketer Rücksprache mit ihren Entwicklern halten, um abzuklären, welche tatsächliche Bildgröße das Bild haben muss.

Die Optimierung des Webservers

Der eigene Webserver ist ein elementarer Bestandteil bei der Reduzierung der Ladezeit, weil er für die Auslieferung der meisten Inhalte einer Webseite verantwortlich zeichnet.

Aus diesem Grund ist das erste Kriterium „die Antwortzeit des Servers“, auch als TTFB (Time To First Byte) bekannt. Je schneller der Webserver dem Browser antwortet, desto schneller können Inhalte ausgeliefert werden. Auf diese Zeit hat der Webseitenbetreiber allerdings nur in Teilen Einfluss, da sie unter anderem vom Serverstandort abhängig ist.

In Deutschland findet der meiste Datenaustausch über den Internetknoten DE-CIX in Frankfurt am Main statt. Deshalb ermöglicht ein in Frankfurt platzierter Server eine spürbar bessere Antwortzeit als ein Server im Norden oder Süden von Deutschland. Auch die ländliche Region kann Einfluss auf die TTFB haben. In der Regel treten hier innerhalb Deutschlands bereits Unterschiede von mehreren Hundert Millisekunden auf. Der Google-PageSpeed-Test gibt bereits eine Warnung, wenn der Server eine Antwortzeit von über 200 Millisekunden hat. Gelegentlich kann der Wechsel des Hosters oder ein Upgrade eines Servers bereits spürbare Verbesserungen bringen.

Zur weiteren Reduzierung der Serverantwortzeit sollten auch die eingesetzten Server-Technologien möglichst aktuell sein. Am Beispiel von PHP wurde am 19.01.2017 bereits der Support für PHP 5.6 (exkl. LTS-Version) eingestellt, wodurch nur noch PHP 7 unterstützt wird. PHP 7 bietet deutliche Leistungssteigerungen im Vergleich zu PHP 5.6, funktioniert in Teilen aber auch anders. Ein einfaches Upgrade von 5.6 auf 7 kann daher die Webseite zerstören.

Entwickler sollten in jedem Fall vorab die Funktionalität der Webseite in einer Testumgebung mit installiertem PHP 7 überprüfen. Sobald die PHP-Version dann in der Liveumgebung umgestellt ist, wird die Webseite einen deutlichen Geschwindigkeitszuwachs erleben, unter anderem auch in Bezug auf die TTFB, die dadurch weiter sinkt. Darüber hinaus ist PHP 7 teilweise sogar schneller als das bekannte „HHVM (HipHop Virtual Machine)“, welches von Facebook als PHP-Ersatz entwickelt wurde und sicherstellen soll, dass die Inhalte auf Facebook immer zügig laden (https://goo.gl/vnQr82).

Ein weiteres wichtiges Thema ist die Verwendung von HTTP/2. Das Hypertext Transfer Protocol, kurz HTTP, kümmert sich unter anderem um die Übermittlung der Inhalte vom Webserver zum Browser. Version 1 wurde 1996 publiziert und 1999 mit Version 1.1 überholt. Seitdem wurde das Protokoll nicht mehr überarbeitet und an die neuen Entwicklungen der Mediennutzung wie Smartphones etc. angepasst. Aus diesem Grund entwickelte Google für den hauseigenen Browser Chrome das Protokoll „SPDY“, welches diverse Verbesserungen bei der mobilen Datenübertragung einführte. Um jedoch einen neuen Standard zu etablieren, erarbeitete das W3C neue Vorgaben für HTTP, die zu großen Teilen auf „SPDY“ basierten. Diese Vorgaben ermöglichen es unter anderem, mehr Inhalte parallel auszuliefern, indem Anfragen zusammengefasst und Daten komprimiert werden. Eine weitere Neuerung ist die Möglichkeit des Webservers, Daten auszuliefern, die der Browser noch gar nicht angefragt hat, von denen der Server aber schon weiß, dass der Browser sie noch anfragen wird.

Kurz erklärt: W3C

Das W3C, auch als World Wide Web Consortium bekannt, kümmert sich als Gremium um die Standardisierung von genutzten Techniken im Internet. Hierzu zählt unter anderem auch das Übertragungsprotokoll HTTP/2.

Um HTTP/2 verwenden zu können, sollte die Webseite verschlüsselt sein und HTTPS nutzen, weil Browser wie Chrome und Firefox das Protokoll nur in diesem Fall unterstützen. Gerade bei mobilen Endgeräten, die in Googles Szenario langsam sind und eine schlechte Internetverbindung nutzen, kann dies die Ladezeit weiter verkürzen. Nutzt eine Webseite bereits HTTP/2, sollte die IT darüber nachdenken, auch das Protokoll HSTS zu nutzen, welches Browser dazu zwingt, Inhalte nur noch mittels HTTPS anzufragen. Standardmäßig ist dies nicht der Fall, wodurch Anfragen auf verschlüsselten Webseiten zunächst von HTTP auf HTTPS weitergeleitet werden müssen – was wiederum die Ladezeit erhöht.

Generell gilt es, die Anzahl an Weiterleitungen so gering wie möglich zu halten. Hierfür können Webseitenbetreiber selbst Sorge tragen, indem sie die Links innerhalb ihrer Webseite so einrichten, dass der Webserver keine unnötigen Weiterleitungen durchführen muss. Die Umleitung von HTTP auf HTTPS ist dabei nur ein Beispiel. Zwei andere sind die Umleitung von „ohne www“ auf „mit www“ oder die Umleitung einer URL mit einem abschließenden „/“ auf die URL ohne abschließendes „/“.

Im Falle der Nutzung des Apache Webservers sollten Webseitenbetreiber auch die htaccess-Datei nutzen. In dieser können weitergehende Konfigurationen des Webservers vorgenommen werden. Beispiele hierfür sind:

  • Aktivierung des HSTS-Protokolls
  • Einrichtung von Weiterleitungen
  • Aktivierung des Browser-Cachings
  • Aktivierung eines Server-Cachings
  • Setzen von Mime-Types
  • Aktivierung einer Datenkomprimierung
  • Steuerung des E-Tags

Aus diesem Grund ist die htaccess-Datei ein äußerst starkes Tool, um Maßnahmen der Ladezeit-Optimierung vorzunehmen. Die Datei liegt unter dem Dateinamen „.htaccess“ auf dem Server und kann über den FTP- oder SSH-Zugang bearbeitet werden. Andere Webserver wie nginx bieten ähnliche Konfigurationsmöglichkeiten.

Abschließend kann zur weiteren Optimierung ein CDN (Content Delivery Network) genutzt werden, über das die Inhalte zur Verfügung gestellt werden. Bei einem CDN werden viele Server über die ganze Welt verteilt von einem Anbieter installiert und genutzt. Der Vorteil von CDNs liegt somit in der weltweiten Verteilung der Server, wodurch Webseiteninhalte ausschließlich von dem Server geliefert werden, der geografisch am nächsten am User liegt. Ein weiterer Vorteil ist, dass unterschiedliche Inhalte, z. B. JavaScript-Dateien und Bilder, von unterschiedlichen Servern geliefert werden können, wodurch der Browser mehr Inhalte parallel anfragen und bearbeiten kann. Diese Lösung ist jedoch eher für Großunternehmen und internationale Händler zu empfehlen.

Fazit

Die Optimierung der Ladezeit ist eine sehr kleinteilige Aufgabe und sollte nur von geschulten Mitarbeitern durchgeführt werden. Dennoch ist sie im mobilen Zeitalter notwendiger denn je, weil sie direkte Auswirkungen auf das User-Verhalten und die Conversions der eigenen Webseite hat. Ebenfalls ist sie inzwischen ein Rankingfaktor.

Spannend? Dieser Artikel ist im suchradar #65 erschienen

Lesen Sie weitere spannende Artikel aus der Ausgabe „Mobile First: Aufrüsten für den neuen Google-Index“! Entweder online oder als PDF-Magazin.

Kostenlos als PDF-Version Alle Artikel aus der Ausgabe ansehen