Die wichtigsten Handgriffe für eine schnelle Website

Dass eine schnelle Webseite heutzutage enorm wichtig ist, dürfte mittlerweile jedem Webmaster klar sein. Doch auf meinen Streifzügen durchs Netz begegnen mir Tag für Tag dutzende Seiten, die noch immer enormes Optimierungspotential aufweisen. In diesem Artikel möchte ich diverse Techniken vorstellen, um die Ladegeschwindigkeit einer Website zu erhöhen und deren Ladezeit zu senken.

Warum ist eine Pagespeed-Optimierung sinnvoll?

Schaut man sich die Werbung diverser Telekommunikations- und Internetanbieter an, sollte man meinen, die Optimierung einer Webseite auf eine schnellere Ladezeit könnte man 2015 getrost vernachlässigen. Breitbandausbau hier, LTE dort. Dass die Realität ganz anders aussieht, zeigt ein Blick in die Statistiken: Im dritten Quartal 2014 lag die durchschnittliche Internet-Übertragungsgeschwindigkeit der Deutschen bei lediglich 8,7 Mbit/s. Die mobile Geschwindigkeit lag sogar nur bei 1.233 Kbit/s. Auf der anderen Seite wird das Web immer größer: Um ganze 15 Prozent auf 1.953 Kilobyte wuchs die durchschnittliche Webseite 2014 im Vergleich zum Vorjahr .

Zudem sollte man sich als Betreiber einer Webseite immer vor Augen halten, dass die Ladegeschwindigkeit einer der wichtigsten User-Experience-Faktoren überhaupt ist. Zur Veranschaulichung verwende ich gerne folgendes Beispiel: Besucht ein Chinese eine Webseite, so ist seine Erwartungshaltung hinsichtlich Design, Usability und Inhalt eine vollkommen andere, als bei einem europäischen Besucher. Lediglich eine Anforderung stellen beide: Die Seite muss schnell laden.

Nicht vergessen darf man, dass es für Webseiten-Betreiber um viel Geld gehen kann. Eine vielzitierte Studie von Amazon aus dem Jahr 2007 besagt, dass eine Erhöhung der Ladezeit um eine Zehntelsekunde die Konversionsrate um einen Prozent senkt.

Wie schnell ist schnell?

Wenn sich nun jemand fragt, wie schnell eine Webseite denn sein müsse, um das Prädikat „gut“ oder „sehr gut“ zu erhalten, kann man nur entgegnen: Darauf gibt es keine pauschale Antwort. Kommt ein Online-Shop mit dutzenden Produkten auf eine Gesamtladezeit von drei Sekunden, so wäre dies ein akzeptabler Wert. Bei einem simplen Blog würde ich hingegen noch Optimierungspotential sehen.

Ähnlich wie bei der Suchmaschinenoptimierung macht es durchaus Sinn, seine Mitbewerber hinsichtlich deren Pagespeed zu analysieren. So kann man sich schnell einen Überblick verschaffen, in welchem Kosmos man sich bewegt. Generell sollte allerdings immer das Ziel sein, die Webseite im Rahmen der eigenen Möglichkeiten auf ein Maximum an Performance zu bringen. Muss man eine Optimierung an den Webentwickler seines Vertrauens auslagern, wird es natürlich schnell zu einer simplen Preis/Leistungs-Frage.

Häufig wird die Ladegeschwindigkeit einer Webseite auch gleichgesetzt mit dem reinen Wert der Google PageSpeed Insights von 0 bis 100. Der dort erreichte Punktestand sowie die diversen Optimierungsvorschläge ist zwar ein guter Indikator, kann eine händische Pagespeed-Analyse aber nie ersetzen. Auch wenn es in der Praxis selten vorkommt, kann eine Webseite mit einem PageSpeed-Insights-Wert von 100 durchaus noch Optimierungspotential aufweisen, wohingegen eine Website mit 85 Punkten aus diversen Gründen bereits das Maximum erreicht hat.

Weniger ist mehr: http-Requests reduzieren

Unter einem http-Requests versteht man die Anforderung und Auslieferung einer einzigen Datei vom Server an den Client/Browser. Nun gibt es mehrere Aspekte, die eine Reduzierung von http-Requests zu einer der wichtigsten und langfristigsten Aufgaben bei der Pagespeed-Optimierung machen.

Um zu verstehen, warum jeder einzelne http-Request die Ladezeit einer Webseite verlangsamt, muss man sich anschauen, wie das http-Protokoll funktioniert. Wenn der Browser die Aufgabe bekommt, eine bestimmte Datei herunterzuladen, ist er gezwungen, jedes Mal aufs Neue eine Verbindung zum Server herzustellen. Enthält eine Seite beispielsweise 5 CSS- und 15 Javascript-Dateien, so können diese nicht in einem Abwasch heruntergeladen werden; vielmehr sind 20 einzelne Verbindungen zum Server notwendig.

Erschwerend kommt hinzu, dass bei jedem http-Request so genannte Request Headers (Anfrage-Informationen) und Response Header (Antwort-Informationen) mitgesendet werden müssen. Erstere beinhalten unter anderem für die Domain definierte Cookies, den Referer oder User Agent. Letztere liefern neben dem eigentlichen Inhalt Details zum Browser-Caching, dem Mime-Type oder Zeichensatz zurück. Der Fachmann spricht hier von einem „Protocol overhead“, welcher beim abgesicherten https-Protokoll übrigens noch wesentlich größer ausfällt.

Eine andere Tatsache, die für die Reduzierung von http-Requests spricht, ist, dass selbst moderne Browser wie Google Chrome oder Mozilla Firefox lediglich ein bestimmtes Kontingent an Verbindungen pro Host gleichzeitig öffnen können. Im Falle der beiden genannten handelt es sich um sechs parallele Verbindungen. Diese Begrenzung, welche im Laufe der Jahre bereits mehrfach angehoben wurde, besteht, um Server bei einem Seitenaufruf nicht zu stark zu belasten.

Wie reduziere ich http-Requests?

Die wichtigste Aufgabe bei der Pagespeed-Optimierung ist auch gleichzeitig die schwierigste, da sie nicht pauschal beantwortet werden kann. Im Zuge der Analyse ist es entscheidend, sich einen genauen Überblick über seine http-Requests zu verschaffen. Dies geht am besten mit den Chrome Entwicklertools (Menü -> Weitere Tools -> Entwicklertools -> Netzwerk-Reiter) oder Firefox Entwickler-Werzeugen (Menü -> Entwickler-Werkzeuge -> Netzwerkanalyse). Nach einem Reload werden in beiden Tools sämtliche erzeugten Requests angezeigt. Diese können nach Typ, Startzeitpunkt oder Ausführungszeit weiter gefiltert und sortiert werden.

Im Zuge der Optimierung müsste man sich jeden einzelnen http-Requests im Detail anschauen und prüfen, ob seine Ausführung a.) generell und b.) mit dieser Priorität erforderlich ist. Dazu muss man verstehen, dass es verschiedene Arten gibt, mit http-Requests umzugehen:

• Synchron laden: Im Standardfall wird eine Datei synchron vom Server angefordert. Dies bedeutet, dass sie unmittelbar nach Aufruf in die Liste der zu ladenden Dateien eingereiht und abgearbeitet wird. Dies ist vor allem für die wichtigsten Ressourcen und above-the-fold-Inhalte empfehlenswert.

• Asynchron laden: Natürlich kann man Ressourcen auch asynchron anfordern, wenn ein bestimmtes Event ausgelöst wird. Dies könnte unter anderem der Klick auf einen Button, das Scrollen an eine bestimmte Position oder auch nur das erfolgreiche Laden aller wichtigen Ressourcen (async-Attribut) sein. Dies ist vor allem für externe Ressourcen und below-the-fold-Inhalte empfehlenswert.

• Von anderem Host (CDN) laden: Da sich die oben erwähnte Request-Sperre nur auf einen Host bezieht, kann es durchaus Sinn machen, statische Ressourcen von einem anderen Host zu laden. Hierfür kommen vor allem CDN-Anbieter wie zum Beispiel Amazon CloudFront oder CloudFlare in Frage, da diese Dateien von Servern passend zum Nutzerstandort ausspielen.

• Überhaupt nicht laden: Noch besser als ein optimierter Request ist natürlich gar kein Request. Damit ist allerdings nicht gemeint, dass die eingesparten Dateien komplett verschwinden. Durch diverse Techniken lassen sich Inhalte verschieben oder mit anderen Requests kombinieren; worauf wir im weiteren Verlauf des Artikels natürlich noch eingehen werden.

ZIP und weg: Durch serverseitige Komprimierung etliche KB einsparen

Was ein ZIP-Archiv ist, weiß wohl jeder Webworker: Man nehme eine oder mehrere Dateien und lässt diese wie von Zauberhand in der Dateigröße schrumpfen. Im Hintergrund werkelt ein Algorithmus, der mehrfach vorkommende Zeichenketten intelligent verarbeitet und in Clustern abspeichert.

Dass sich diese Technik in Form von des gzip- oder deflate-Moduls auf fast jedem Server simpel aktivieren lässt, wissen hingegen schon deutlich weniger. Man kann sich dieses Vorgehen in etwa so vorstellen, dass der Browser den Server via Request Header mitteilt, welche Komprimierungstechnik er unterstützt. Gibt es einen Überschneidungspunkt, packt der Server die Datei in ein komprimiertes Archiv und sendet sie samt Information, um welche Technik es sich handelt, an den Browser. Der Browser wiederum entpackt die empfangene Datei lokal und zeigt seinem Nutzer den eigentlichen Inhalt.

Vor allem bei textlastigen Dateien mit häufigen Wiederholungen (HTML, Javascript, CSS) sind mit einer serverseitigen Komprimierung erhebliche Einsparungen möglich. Am Beispiel von smashingmagazine.com betrachtet kommt die reine HTML-Datei auf eine Dateigröße von 64 KB. Durch gzip-Komprimierung werden jedoch nur 16 KB übertragen. Ähnlich sieht es bei der CSS-Datei aus; statt 22 KB sind nur knapp 7 KB nötig.

Hostet man seine Webseite auf einem Apache-Server, so lässt sich die Komprimierung via deflate- oder gzip-Modul ganz einfach pro Datei-Typ in der .htaccess-Datei aktivieren. Das sieht dann so aus:

<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain text/html AddOutputFilterByType DEFLATE text/css text/javascript [...] </IfModule> <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>

Achtung: Bilder sollten von der serverseitigen Komprimierung ausgeschlossen werden!

Denk an mich: Dateien im Browser-Cache behalten

Der Browser-Cache ist eine praktische Sache. Statische Ressourcen wie Bilder oder CSS- und Javascript-Dateien, die sowieso bei jedem neuen Seitenaufruf unverändert bleiben, müssen nicht erneut heruntergeladen werden. Stattdessen verwendet der Browser die Datei aus seinem lokalen Cache, spart dadurch einen kompletten http-Request und somit natürlich jede Menge Ladezeit.

In der Regel weiß der Browser jedoch nicht, ob und falls ja wie lange er eine Datei im Cache ablegen darf. Es könnte ja auch gut sein, dass sich eine Bild-Datei bei jedem Seitenaufruf dynamisch aktualisiert und die Webseite durch ein Caching unbrauchbar werden würde. Deshalb kann man ihm, wieder über die .htaccess-Datei des Servers, global mitteilen, welchen Dateityp er wie lange im Cache behalten soll.

<IfModule mod_expires.c> ExpiresActive On ExpiresByType text/html "access plus 1 second" ExpiresByType text/css "access plus 2 weeks" ExpiresByType text/javascript "access plus 2 weeks" ExpiresByType image/jpg "access plus 3 weeks" ExpiresByType image/png "access plus 3 weeks" [...] </IfModule>

Mit diesem Code-Beispiel teilen wir dem Browser mit, dass er reine HTML-Dateien nicht bzw. lediglich eine Sekunde, CSS- und Javascript-Dateien zwei Wochen und Bilder sogar drei Wochen im Cache behalten darf. Diese Auflistung sollte man natürlich um jeden auf der Webseite verwendeten Mime-Type ergänzen.

Wer PHP verwendet und filigraner selektieren möchte, kann den entsprechenden http-header auch direkt innerhalb einer Datei setzen. Dies geht mit dem folgenden Code.

<?php $expires_timestamp = mktime(0, 0, 0, 12, 31, 2015); $lastmodified_timestamp = mktime(0, 0, 0, 1, 1, 2015); header("Expires: ".date("D, j M Y H:i:s", $expires_timestamp)." GMT"); header("Last-Modified: ".date("D, j M Y H:i:s", $lastmodified_timestamp)." GMT"); header("Pragma: cache"); header("Cache-Control: store, cache"); ?>

Für statische Ressourcen empfiehlt Google PageSpeed Insights übrigens mindestens eine Haltbarkeitsdauer von einer Woche.

Von der besten Seite zeigen: Bilder komprimieren, passend skalieren und Dateiformat hinterfragen

Auch Bild-Dateien bergen meistens enormes Optimierungspotential. Vor allem beim Einsatz eines Content Management Systems werden von Redakteuren häufig Bilder hochgeladen, die weder für das Web komprimiert wurden noch in passender Auflösung vorliegen. Nicht selten begegnen mir Webseiten, die nach einer Optimierung mehrere hundert Kilobyte kleiner sein könnten.

Bei der Bild-Komprimierung unterscheidet man zwischen verlustfreier (lossless) und verlustbehafteter (lossy) Variante. Erstere erhält exakt die selbe Bildqualität wie beim Original; wohingegen letztere einen Schritt weiter geht und beispielsweise Farbwerte, die sich nur minimal unterscheiden, zusammenführt. Für die meisten Augen ist diese Einsparung kaum sichtbar, die Dateigröße des Bildes kann jedoch erheblich schrumpfen.

Für die Komprimierung von Bild-Dateien gibt es gleich mehrere Tools:

• tinypng.com (Online)
• tinyjpg.com (Online)
• PngYu (Mac)
• ImageOptimize (Mac)
• Caesium (Windows)
• jStrip (Windows)
• und viele mehr

Neben der reinen Komprimierung der Dateien ist es natürlich auch sinnvoll, Bilder lediglich in der Auflösung zur Verfügung zu stellen, in der sie auch auf der Webseite eingebunden werden. Wird ein Bild auf einer Webseite in der Größe 600 x 400 Pixel eingebettet, so muss die Datei auf dem Server nicht 1000 x 660 Pixel groß sein.

War diese Thematik in der Vergangenheit noch relativ leicht zu berücksichtigen, sieht man sich heute mit wesentlich komplexeren Anforderungen konfrontiert. Schließlich wollen Bilder responsive und womöglich auch noch Retina-optimiert ausgegeben werden. Wer hier ein optimales Ergebnis erzielen möchte, sollte sich näher mit dem <picture>-Element beschäftigen.

Zudem sollte man idealerweise immer für jedes Bild überprüfen, welches Dateiformat die beste Komprimierung ermöglicht. Nicht nur die Frage ob JPG oder PNG ist dabei relevant. Mit den Formaten SVG oder WebP gibt es interessante neue Kandidaten, die teilweise wesentlich kleinere Dateigrößen erzielen und sich bereits heute gut einsetzen lassen, wenn man zugleich an ein Fallback denkt.

Auf Grund der goldenen Regel der Pagespeed-Optimierung, http-Requests zu reduzieren, gibt es noch drei weitere Techniken, die an dieser Stelle nicht unerwähnt bleiben sollten. Gerade bei sehr kleinen Bild-Dateien unter einem Kilobyte sollte man prüfen, ob eine direkte Einbettung via Data-URL bzw. Base64-Zeichenkette Sinn macht. Dabei wird im CSS oder src-Attribut keine URL zu einer externen Datei eingetragen, sondern direkt der Bild-Inhalt in Form einer Zeichenkette hinterlegt. Ein Base64 Image lässt sich unter anderem sehr schnell über eines der diversen Online-Tools wie base64-image.de erstellen.

Zudem steht mit CSS-Sprites nach wie vor eine solide Technik zur Verfügung, mehrere Bilder in einer Datei zu bündeln. Dabei platziert man zum Beispiel alle auf der Webseite verwendeten Icons auf einer Fläche nebeneinander. Die Bild-Datei wird per CSS background-image-Eigenschaften einmalig geladen. Einzelne Icons können anschließend via CSS background-position angesprochen werden.

Auch das asnychrone Laden von Bildern, sobald der Nutzer an deren Position gescrollt hat, ist seit einigen Jahren unter dem Begriff „Lazy Loading“ eine beliebte Technik. Entsprechende Plugins gibt es mittlerweile für alle gängigen Content Management Systeme und als reine Javascript-Erweiterungen wie unveil.js oder lazyload.js.

Lass die Luft raus: HTML-, CSS- und Javascript- Dateien reduzieren

Natürlich sollte Quellcode immer ordentlich eingerückt, sauber formatiert und hinreichend kommentiert werden. In der Entwicklungsumgebung. Auf dem Server im produktiven Einsatz haben Leerzeichen, Zeilenumbrüche, Tabulator-Einzüge und Kommentare nichts zu suchen. Solange Code sauber geschrieben ist, ist es dem Browser egal, ob eine Javascript-Funktion kommentiert ist oder nicht. Anders als der Webentwickler-Kollege im Büro nebenan braucht er diese Information nicht, um die Funktion zu verstehen. Im Gegenteil: Durch unnötige Zeichen im Quellcode können HTML-, CSS- und Javascript- Dateien sehr schnell in der Größe um 15 bis 30 Prozent wachsen.

Auch bei der Reduzierung statischer Ressourcen führen viele Wege nach Rom. Hier muss man sich für die Methode entscheiden, die sich am besten in den eigenen Workflow integrieren lässt. Am einfachsten, aber auf Dauer auch am zeitraubendsten, ist wahrscheinlich die Reduzierung via eines der etlichen Online-Tools. Jscompress.com oder cssminifier.com sind nur zwei unter hunderten Kandidaten.

Wesentlich komfortabler ist es, den Prozess der Minimierung automatisiert beim Speichern der Datei anzustoßen. Dies funktioniert beispielsweise über den beliebten Task Runner Grunt oder direkt via FileWatcher in der eigenen Entwicklungsumgebung (IDE). Wer diesen Weg gehen möchte, sollte sich näher mit UglifyJS oder dem YUI Compressor beschäftigen. Freunde des Precompilers SASS können die CSS-Ausgabe auch direkt mit dem Parameter compressed reduzieren lassen.

Auf den Punkt gebracht: Umleitungen vermeiden

Auf das Thema Reduzierung von http-Requests wurde im Artikel nun bereits mehrfach eingegangen. Dabei wird jedoch häufig vergessen, dass auch Um- und Weiterleitungen separate Requests darstellen, die es zu vermeiden gilt. Denn auch hier wird eine separate Ressource angefordert und ein Overhead an Response und Request Headern übertragen, auf die der Browser reagieren muss.

Ein häufiges Beispiel für unnötige Weiterleitungen sind Content Management Systeme, die beim Aufruf der Hauptdomain bzw. Startseite auf eine andere URL (index.php?…) umleiten. Dieses Verhalten ist nicht nur im Bezug zur Suchmaschinenoptimierung suboptimal, sondern erhöht die Ladezeit der Webseite bei jedem Aufruf.

Auch bei einer Umstellung vom http- auf das https-Protokoll kommt es häufig zu Problemen. Auf den ersten Blick funktioniert zwar alles korrekt, wenn man z.B. in der .htaccess-Datei eine Weiterleitung aller http-Aufrufe auf https konfiguriert. Wenn die internen Links jedoch weiterhin mit “http” beginnen, wird jeder Seitenaufruf verlangsamt.

Generell sollte man sich bemühen, Um- und Weiterleitungen nur einzusetzen, wenn es zwingend erforderlich ist. Die internen oder idealerweise auch von extern kommenden Links sollten jedoch immer auf das endgültige Ziel verweisen.

One file to rule them all: CSS- und Javascript-Dateien zusammenlegen

Auch bei diesem Punkt geht es wieder darum, http-Requests zu reduzieren und somit die Ladezeit einer Webseite zu verringern. Gerade bei natürlich gewachsenen Webseiten ist es die Regel, dass bei einem Seitenaufruf nicht jeweils eine, sondern eher ein Dutzend CSS- und Javascript-Dateien geladen werden. Aus den eingangs im Artikel genannten Gründen fällt diese Vielzahl an http-Requests bei der Ladezeit einer Webseite natürlich sehr negativ ins Gewicht.

Dabei muss nicht jedes kleine Widget seine eigene Datei mitbringen. Vor allem CSS-Dateien lassen sich einfach und in der Regel fehlerfrei kombinieren. So kann aus 15 einzelnen problemlos eine große Datei werden. Ein weiterer positiver Nebeneffekt der Kombinierung ist, dass Kompressionstechniken wie gzip oder deflate auf Grund des größeren – sich aber stark wiederholenden – Textkörpers noch besser arbeiten können. Wer bereits mit SASS oder LESS arbeitet, hat keinerlei Probleme, seine CSS-Dateien via @import sauber zu strukturieren und dennoch nur eine große Datei auszuliefern.

Schwieriger wird es bei Javascript-Dateien, da diese komplexere Abhängigkeiten aneinander stellen. Hier ist es in der Regel erforderlich, jede Datei manuell zu untersuchen und deren Inhalt korrekt zu verschieben. Eine Aufgabe, die mit viel Fleiß und Testen verbunden ist. Nichtsdestotrotz sind die gewonnen Einsparungen an http-Requests genauso wertvoll wie bei den CSS-Dateien.

Die Königsdisziplin: Das Rendern von above-the-fold-Inhalten nicht blockieren

In diversen Foren oder Facebook-Gruppen begegnet mir sehr häufig die Frage, was es mit der Google-Empfehlung „JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten „above the fold“ (ohne Scrollen sichtbar) beseitigen“ auf sich hat. Die Behebung dieses „Fehlers“ kann vor allem der subjektiven Ladezeit einer Webseite einen ordentlichen Boost verpassen; stellt viele Webmaster aber auch vor eine nicht lösbare Aufgabe. Denn um das Rendern von above-the-fold-Inhalten, also dem ohne Scrollen sichtbaren Bereich, nicht zu blockieren, muss man sich sehr intensiv mit der Code-Struktur einer Webseite auseinandersetzen.

Um zu verstehen, was es mit diesem Thema auf sich hat, muss man sich klar machen, wie ein Browser eine Webseite verarbeitet und darstellt. Dabei ist es wichtig zu wissen, dass er den Quelltext stur von oben nach unten ließt. Häufig kommt es zum Beispiel vor, dass sich im sofort sichtbaren Bereich einer Website ein Bild-Slider befindet, der ohne Javascript nicht korrekt funktioniert. Nun ist es die Regel, dass das Javascript, welches für die Aktivierung dieses Sliders zuständig ist, erst ganz zum Ende, also ganz unten im HTML-Quelltext, geladen wird. Der Browser kann den sofort sichtbaren Bereich der Seite also erst anzeigen, nachdem so gut wie alle Dateien geladen wurden. In dem Fall spricht man von einem Blockieren des Renderings.

Ähnlich verhält es sich mit vielen CSS-Dateien, sogar wenn diese bereits im <head>-Element verlinkt wurden. Wie eingangs erwähnt, kann ein Browser nur ein begrenztes Kontingent an http-Requests gleichzeitig verarbeiten. Werden nun beispielsweise zehn einzelne CSS-Dateien eingebunden und alle wirken sich irgendwie auf die Darstellung des above-the-fold-Inhaltes aus, kann der Browser den sofort sichtbaren Bereich nicht mit dem ersten Lade-Zyklus darstellen. Wieder spricht man von einem Blockieren des Renderings.

Wie gesagt muss man sich mit der CSS- und Javascript-Struktur seiner Webseite also genau auskennen, um dieses Problem zu beheben. Eine Möglichkeit ist, Code der erst später benötigt wird, weiter unten im Quelltext zu platzieren oder gar asynchron zu laden. Code der hingegen frühzeitig benötigt wird, sollte möglichst weit oben in der DOM-Hierarchie auftauchen; wenn nötig sogar direkt inline im <head>-Element via <script> oder <style>.

Wer seine Webseite allerdings mit einem Content Management System wie WordPress betreibt und viele externe Plugins im Einsatz hat, sollte sich nicht allzu viele Hoffnungen machen. Eine Optimierung an dieser Stelle klappt meist nur, wenn man hundertprozentige Kontrolle über die verwendeten Assets hat.

Gib Gummi: Antwortzeit des Servers reduzieren

Alle bisher vorgestellten Optimierungstechniken waren vorrangig clientseitig, fanden also im Browser des Nutzers statt. Manchmal kommt es aber auch vor, dass der Server zum Flaschenhals in Sachen Ladezeit wird. Hier sei nochmal WordPress in Kombination mit vielen externen Plugins genannt. Aber auch sehr rechenintensive Systeme, wie das Online-Shop-Framework Magento, brauchen teilweise extrem lange, bis sie das vom Browser angeforderte HTML-Dokument generiert und an den Server geschickt haben.

Falls es hier ein Problem gibt, kennzeichnet Google PageSpeed Insights dies durch den Hinweis „Antwortzeit des Servers reduzieren“. Konkret wird hier eine Fehlermeldung geworfen, falls der Server länger als 200ms – also eine fünftel Sekunde – zum Generieren und Ausliefern der initialen HTML-Datei benötigt.

Ist man von dieser Meldung betroffen, sollte man als erstes überprüfen, ob die angegebene Ladezeit für das verwendete Content Management oder Shop System normal ist. Ein Magento beispielsweise wird in der Standardkonfiguration nie unter die 200ms kommen. Falls es sich aber doch um einen deutlich erhöhten Wert handelt, sollte ausgeschlossen werden, dass irgendwo im (PHP-)Code ein Flaschenhals existiert. Schlecht programmierte Plugins oder Extensions von Drittanbietern sind unter anderem ein häufiger Grund für Performance-Engpässe.

Kann ein Fehler im Code ausgeschlossen werden, sollte man als nächstes prüfen, ob ein serverseitiges Caching für das verwendete System verfügbar ist. Dieses sorgt dafür, dass in regelmäßigen Abständen feste HTML-Kopien der einzelnen Seiten erzeugt und statt der dynamischen Ausgabe an den Browser geschickt werden. Somit müssen die komplexen Scripte nicht bei jedem Seitenaufruf, sondern beispielsweise nur einmal alle 24 Stunden ausgeführt werden.

Magento bietet ein eigenes Caching-System an, welches über die Einstellungen im Backend bequem konfiguriert werden kann. Setzt man auf WordPress kann man sich eine Caching-Technologie über ein Plugin wie Cachify oder WP Rocket nachrüsten.

---

Dieser Artikel gehört zu: UPLOAD Magazin 20

Sieben typische Usability-Probleme vermeiden. Ladegeschwindigkeit erhöhen. Texte verbessern. Website und Social Media perfekt miteinander verknüpfen. Alles das und mehr erfahren Sie in dieser Ausgabe mit dem Titelthema „Website optimieren“. Dazu haben wir uns diesmal drei Experten als Gastautoren eingeladen: Jens Jacobsen, Torben Leuschner und Annette Schwindt.

• Weitere Artikel aus dieser Ausgabe kostenlos auf der Website lesen ...
• Bleib auf dem Laufenden über neue Inhalte mit dem „Update am Montag“ …

Schon gewusst? Mit einem Zugang zu UPLOAD Magazin Plus oder zur Content Academy lädst du Ausgaben als PDF und E-Book herunter und hast viele weitere Vorteile!