Blog zu den Themen Webentwicklung, technisches Online Marketing und Suchmaschinenoptimierung

Wie bild.de, zalando.de oder otto.de ihren Pagespeed optimieren könnten

Obwohl mittlerweile jedem Webworker klar sein dürfte, dass die Optimierung einer Webseite auf eine höhere Ladegeschwindigkeit und niedrigere Ladezeit in mehrerer Hinsicht ein essentieller Erfolgsfaktor ist, scheitern dennoch sehr viele an der Umsetzung. Dieser Artikel soll also vor allem praktische Optimierungstechniken aufzeigen, die sich auch beim eigenen Projekt anwenden lassen. Um dabei nicht in theoretischen Floskeln zu versinken, werden die verschiedenen Maßnahmen am Beispiel vier großer deutscher Webseiten veranschaulicht.

Warum eine Pagespeed-Optimierung auch in Zeiten von VDSL und LTE noch sinnvoll ist

In Gesprächen mit Website-Betreibern hört man häufig die Aussage, man müsse die eigene Ladezeit optimieren, da dies seit einigen Jahren ein Google-Rankingfaktor sei. Obwohl diese Aussage faktisch nicht komplett falsch ist, wird an dieser Stelle häufig zu einfach gedacht.

Ein anderes Bild ergibt sich, wenn man die Ladegeschwindigkeit unter Gesichtspunkten der User Experience (UX) betrachtet. Diese ergibt sich aus diversen Webseite-Bausteinen wie Design, Nutzerführung, Zugänglichkeit, Interaktion oder Inhalt. Allerdings haben diese Punkte gemein, dass ihr Erfolg im Sinne einer positiven UX von der Erwartungkonformität des Besuchers abhängt.

Anders sieht es beim Thema Pagespeed aus. Niemand, unabhängig von Alter, Geschlecht oder Nationalität, wartet gerne. Durch eine Verbesserung der Ladezeit kann man sich also sicher sein, jedem Besucher der Webseite eine verbesserte Nutzererfahrung zu bieten. Umfangreiche Split-Tests oder Eyetracking-Studien, die bei anderen UX-Optimierungen notwendig wären, kann man sich sparen.

Pagespeed-Analyse und die Rolle von Google PageSpeed Insights

Häufig wird die von Googles PageSpeed Insights errechnete Punktzahl zwischen 1 und 100 gleichgesetzt mit dem Optimierunggrad einer Website. Natürlich gibt der vom Tool ausgespuckte Wert einen guten Überblick, sollte aber nie mehr als ein erster Indikator sein. Schließlich unterliegt die Punktzahl wie jeder andere maschinell errechnete Wert den Fesseln seines eigenen Algorithmus. Es kann sogar vorkommen, dass von PageSpeed Insights vorgeschlagene Empfehlungen im Kontext des gesamten Webprojekts betrachtet eher negative Auswirkungen hätten.

100 Punkte sehen zwar gut aus, sind aber nicht immer erstrebenswert!

100 Punkte sehen zwar gut aus, sind aber nicht immer erstrebenswert!

Die Auswertung der vom Tool empfohlenen Maßnahmen kann dementsprechend nur ein Teil einer Pagespeed-Analyse darstellen. Mindestens genauso wichtig ist es, sich mit den Entwicklerwerkzeugen seines Browsers hinreichend vertraut zu machen. Hier ergeben sich nämlich bereits mit wenigen Klicks umfangreiche Möglichkeiten, sich einen detailierten Überblick des Optimierungsgrades einer Webseite zu verschaffen. Im Falle des Chrome-Browsers sollte man sich intensiv mit dem “Network”-Reiter beschäftigen. Wer später noch tiefer einsteigen möchte, findet unter dem Punkt “Timeline” weitere spannende Einblicke.

Mit den Chrome oder Firefox Developer Tools lässt sich eine Website vollständig auseinandernehmen - auch im Bezug auf den Pagespeed.

Mit den Chrome oder Firefox Developer Tools lässt sich eine Website vollständig auseinandernehmen – auch im Bezug auf den Pagespeed.

Dennoch soll die Rolle des PageSpeed Insights Tools an dieser Stelle natürlich nicht heruntergespielt werden, da es vielen Webworkern einen simplen Einstieg in das Thema bietet. Auch bei den Optimierungsmaßnahmen, die im weiteren Artikelverlauf vorgestellt werden, wird man ohne Probleme einen Bezug zum jeweiligen Tipp von Googles Tool herstellen können.

Die drei Säulen der Pagespeed-Optimierung

Fast sämtliche Maßnahmen der Pagespeed-Optimierung lassen sich in drei Kategorien einordnen:

Reduzierung von http-Requests

Das Reduzieren von http-Requests ist in der Regel die wichtigste Optimierungsmaßnahme und gleichzeitig ein Punkt, bei dem die meisten Webseiten noch großes Potential aufweisen. Unter einem http-Requests versteht man die Anfrage des Clients (Browser), sowie die entsprechende Antwort vom Server. Neben dem initialen HTML-Dokument werden bei jedem Seitenaufruf meist dutzende weitere Ressourcen vom Server angefordert, die jeweils einen eigenen Request erzeugen. Wir reden hier in der Regel von Bild-, CSS- und Javascript-Dateien, aber auch eingebettete Schriftarten oder AJAX-Aufrufe erzeugen natürlich einen http-Request.

Vor allem zwei Gegebenheiten sind dafür verantwortlich, dass jeder einzelne http-Requests die Ladezeit erhöht. Zum einen befolgen selbst moderne Browser noch die Regel, nicht zu viele Requests vom selben Server gleichzeitig zu laden. Die aktuellen Versionen von Google Chrome und Mozilla Firefox erlauben beispielsweise höchstens sechs parallele Verbindungen. Dieses Verhalten ist zum einen sinnvoll, da Server sonst, in etwa vergleichbar mit einer DDoS-Attacke, schnell in die Knie gehen könnten. Zum anderen bedeutet dies aber auch, dass Webseiten die mehr als beispielsweise sechs Ressourcen benötigen, die Dateien in mehreren Durchgängen herunterladen müssen.

Ein weiterer Nachteil des Hypertext Transfer Protocol (HTTP) in der Version 1.0 oder 1.1 ist, dass jeder http-Requests in der Regel Informationen übertragt, die an der jeweiligen Stelle gar nicht verwendet werden. Hier unterscheidet man zwischen des Request Headers (Anfrage vom Client an den Server) und Response Headers (Antwort des Servers). Vor allem bei ersteren werden häufig unnötige Daten übertragen. Ein schönes Beispiel sind statische Bild- oder CSS-Dateien, die in den Requests Headers sämtliche der Domain zugewiesenen Cookies erhalten, obwohl diese natürlich an keiner Stelle benötigt werden.

Auch wenn sich beide Punkte vielleicht trivial anhören, so sollte man die Reduzierung von http-Requests als Maßnahme der Pagespeed-Optimierung auf keinen Fall unterschätzen. Weit über 100 Requests bei einem einzelnen Seitenaufruf sind nämlich weniger die Ausnahme als viel mehr die Regel.

Verkleinerung der zu übertragenden Dateimenge

Natürlich lässt sich nicht jeder http-Request einfach streichen, schließlich müssen Inhalte und Funktionalitäten ja irgendwo her kommen. Jedoch gibt es einige Möglichkeiten, die Größe einer Datei zu reduzieren. Im weiteren Verlauf des Artikels werden hierzu entsprechende Maßnahmen vorgestellt. Besonders erstrebenswert sind natürlich Techniken, die eine automatische Reduktion erzielen, ohne das man selbst an der Datei herumschrauben muss.

Ressourcen in die richtige Reihenfolge bringen

Dieser Punkt macht in der Praxis meist den Unterschied zwischen schnellen und super schnellen Webseiten aus, birgt dafür aber auch die größte technische Komplexität. Grob gesagt geht es darum, die vom Server zu ladenden Ressourcen in die richtige Reihenfolge zu bringen, um dadurch wichtige Inhalte unmittelbar sichtbar zu machen. So entsteht der subjektive Eindruck einer wesentlich kürzeren Ladezeit. Allerdings sind dafür meist tiefgreifende Eingriffe in die Technik einer Webseite erforderlich, weshalb entsprechende Maßnahmen in diesem Artikel nur angerissen werden können.

Fallbeispiel #1: bild.de

Die ersten zwei Maßnahmen zur Optimierung der Ladegeschwindigkeit lassen sich gut am Beispiel der Website der auflagenstärksten deutschen Zeitung festmachen.

Statische Ressourcen reduzieren

Unter der Reduzierung von statischen Ressourcen versteht man beim Thema Pagespeed-Optimierung die Bereinigung unnötiger Zeichen in HTML-, CSS- und Javascript-Dateien, die für die korrekte Ausführung nicht notwendig sind. Dies können doppelte Leerzeichen, Zeilenumbrüche, Tabulatoren, aber auch umfangreiche Kommentare sein. Solange man seinen Code sauber formatiert, ist es dem Browser natürlich egal, ob Zeilen korrekt eingerückt oder Funktionen hinreichend kommentiert sind; er benötigt diese Informationen nicht.

Am Beispiel von bild.de ließen sich so immerhin gut 30 KB an zu übertragender Dateimenge einsparen. Heruntergebrochen auf die Dateien, welche nicht reduziert sind, ergäbe dies eine prozentuale Ersparnis von knapp 10 Prozent.

Weder schön noch lesbar, dafür aber schnell: Reduzierter Code

Weder schön noch lesbar, dafür aber schnell: Reduzierter Code

Die Reduzierung von statischen Ressourcen ist meistens schnell erledigt. So stehen diverse Online-Tools wie jscompress.com (Javascript), cssminifier.com (CSS) oder htmlcompressor.com (HTML) zur Verfügung. Für Webentwickler ist es hingegen erstrebenswert, einen Reduzierungs-Prozess direkt in die eigene Entwicklungsumgebung (IDE) zu integrieren. Dies funktioniert beispielsweise hervorragend mit Task Runnern wie Grunt oder gulp.js. So ist sichergestellt, dass man weiterhin über eine (hoffentlich) gut dokumentierte Entwicklungsversion einer Datei verfügt, auf dem Produktivsystem aber automatisch die reduzierte Variante landet.

Javascript- und CSS-Dateien kombinieren

Ging es beim vorherigen Punkt noch um die Reduzierung der Dateigröße, so möchten wir nun die Anzahl an http-Requests verringern. Dies lässt sich unter anderem erreichen, in dem man Javascript- und CSS-Dateien jeweils zusammenlegt. Gerade beim Einsatz von Content Management Systemen wie WordPress werden nicht selten mehr als ein Dutzend verschiedener CSS- und Javascript-Dateien geladen. Meist lässt sich dies nicht vermeiden, schließlich müssen die Plugin-Entwickler ihre Funktionalitäts- und Design-Anweisungen ja irgendwo mitgeben. Einen negativen Einfluss auf die Ladezeit hat es dennoch.

Gerade bei bild.de ist dieser Effekt enorm. So werden alleine über 70(!) einzelne Javascript- und immerhin zehn CSS-Dateien vom Server angefordert. Natürlich sind in diesem Fall sehr viele Script-Einbettungen den externen Werbe-Anbietern geschuldet. Im Zuge der Optimierungsmaßnahme “Reduzierung von http-Requests” bestünde aber an dieser Stelle noch riesiges Optimierungspotential.

bild.de lädt bei einem einzelnen Seitenaufruf über 70 Javascript-Dateien!

bild.de lädt bei einem einzelnen Seitenaufruf über 70 Javascript-Dateien!

Vor allem das Kombinieren von CSS-Dateien ist meistens nicht sonderlich schwer. Hier ist lediglich zu beachten, dass die Inhalte der Dateien in der exakt selben Reihenfolge wie vorher eingefügt werden. Ansonsten könnten sich Selektoren irtürmlich gegenseitig überschreiben. Wer bereits mit SASS oder LESS arbeitet, hat dank @import an dieser Stelle sowieso kein Problem.

Schwieriger wird es häufig bei Javascript-Dateien, da diese untereinander Abhängigkeiten aufweisen können. Beispielsweise wird ein kritischer Fehler erzeugt, wenn ein Script die jQuery-Bibilothek benötigt, diese aber noch gar nicht zur Verfügung steht. Ähnlich wie bei den CSS-Dateien muss man also auch hier die korrekte Reihenfolge beachten sowie sicherstellen, dass der Javascript-Quellcode absolut korrekt formatiert wurde. Ein fehlendes Semikolon am Zeilenende kann hier bereits viel Ärger bedeuten.

Wie bereits beim letzten Punkt sollte der moderne Webentwickler auch die Aufgabe des Kombinierens direkt von seiner IDE via Task Runner erledigen lassen. Falls ein Deployment-Prozess existiert, könnte dieser Schritt aber auch hervorragend hier durchgeführt werden.

Fallbeispiel #2: zalando.de

Auch am Beispiel des großen deutschen Online-Shops zalando.de lassen sich drei Optimierungstechniken exemplarisch erklären.

Browser-Caching nutzen

Zumal man keine Single Landing Page betreibt, ist es die Regel, dass Besucher nicht nur ein, sondern hoffentlich möglichst viele Seiten aufrufen. Aber auch Stammbesucher könnten mehrmals wöchentlich die eigene Webseite besuchen. In beiden Fällen ist es sinnvoll, dem Browser mitzuteilen, wie lange er statische Ressourcen (CSS-, Javascript- oder Bild-Dateien) im eigenen Cache behalten darf. So müssen sie nicht bei jedem Seitenaufruf neu vom Server angefordert, sondern können direkt von der lokalen Festplatte des Nutzers geladen werden. Dadurch spart man gleich doppelt, denn man reduziert die zu übertragende Dateimenge und die Anzahl an http-Requests.

Im Falle von zalando.de wird selbst für sehr allgemeine, seitenübergreifende Elemente kein Ablaufdatum festgelegt. Dies betrifft beispielsweise statische Bilder wie das Logo, den eigenen Icon-Font aber auch die wichtigste CSS-Datei. So ist der Browser mit seiner Entscheidung auf sich allein gestellt und entscheidet sich im Zweifel dafür, bei jedem Seitenaufruf einer Unterseite sämtliche Ressourcen neu vom Server anzufordern.

Statische Ressourcen wie das Logo oder CSS-Dateien werden bei Zalando nicht gecached

Statische Ressourcen wie das Logo oder CSS-Dateien werden bei Zalando nicht gecached

Google PageSpeed Insights empfiehlt für statische Ressourcen mindestens eine Haltbarkeit von einer Woche. Man kann jedoch einen wesentlich höheren Zeitraum definieren. Wenn man auf Nummer sicher gehen will, dass Benutzer keine alten Dateien ausgespielt bekommen, ergänzt man den Dateinamen bei jedem Update um einen Zeitstempel (z.B. von “style-1-1-2015.css” auf “style-15-2-2015.css”).

Betreibt man einen Apache-Webserver lässt sich das Browser-Caching sehr einfach über die .htaccess-Datei definieren. Die Deklaration erfolgt dabei über den Mime Type.

 

Statische Ressourcen komprimieren

Unter der Komprimierung statischer Ressourcen versteht man die serverseitige Aktivierung einer Kompressionstechnik wie gzip oder deflate. Ähnlich wie man es von einem ZIP-Archiv kennt, werden Dateien dabei vom Server komprimiert und dann an den Client (Browser) geschickt. Dieser ist dafür zuständig, die Dateien vor der Verwendung wieder zu dekomprimieren. Die dadurch eingesparte Dateimenge ist vor allem bei Ressourcen mit häufig wiederkehrenden Textmustern wie CSS-Dateien enorm.

zalando.de liefert uns dafür ein schönes Beispiel. Zwar werden fast alle Dateien komprimiert ausgeliefert; die zwei, welche nicht komprimiert werden, zeigen jedoch eindrucksvoll, welches Potential diese Technik bietet. So kommt alleine eine Javascript-Datei auf eine Dateigröße von 58 KB. Komprimiert wäre sie hingegen nur gut 10 KB groß. Eine Einsparung von 48 KB oder 83 Prozent. Im Falle einer immer noch weit verbreiteten EDGE-Verbindung könnte nur durch die Komprimierung dieser Datei die Ladezeit um zwei bis drei Sekunden gesenkt werden.

Ähnlich wie beim letzten Punkt lässt sich auch hier eine Komprimierung über die .htaccess-Datei des Servers aktivieren.

Bereits komprimierte Dateien wie Bilder oder bestimmte Schriftformate sollten von der serverseitigen Komprimierung ausgeschlossen werden.

Fallbeispiel #3: bundestag.de

Auch die offizielle Webseite des deutschen Bundestages liefert uns zwei gute Fallbeispiele.

Antwortzeit des Servers reduzieren

Google PageSpeed Insights bemängelt im Falle von bundestag.de eine lange Antwortzeit des Servers. Diese Fehlermeldung wird ausgegeben, sobald der Server länger als 200 ms benötigt, das initiale HTML-Dokument zur Verfügung zu stellen. Bei bundestag.de sind es meist über 400 ms. Damit betrifft dieser Hinweis die Ausführungszeit der serverseitigen Scripte; also nicht HTML oder Javascript, sondern PHP, Java, Ruby on Rails oder natürlich auch sämtliche Datenbankabfragen.

Hier einen pauschalen Optimierungstipp zu geben, ist relativ schwierig. Schließlich ist zur Ermittlung von Flaschenhälsen eine genaue Code-Analyse notwendig. Bei komplexen Content Management Systemen oder Online-Shops sollte man aber auf jeden Fall – sofern noch nicht vorhanden – über eine serverseitige Caching-Lösung nachdenken. Diese schreibt im Idealfall die fertig generierten HTML-Dateien in regelmäßigen Zeitabständen auf die Festplatte des Servers. Ruft ein Besucher dann die Webseite auf, ist eine Aktivierung der serverseitigen Scripte gar nicht mehr notwendig; stattdessen wird einfach das Abbild aus dem Cache an den Browser geschickt. Durch Einsatz dieser Technik sollte es in der Regel kein Problem sein, unter die 200 ms zu kommen.

Große Online-Shop-Systeme wie Magento liefern Caching-Module direkt frei Haus mit. Eine korrekte Konfiguration ist dennoch kein Kinderspiel und erfordert etwas Geduld. Im Falle des Content Management Systems WordPress lässt sich die Funktionalität über Plugins nachrüsten. Der deutsche Entwickler Sergej Müller bietet hierfür mit Cachify eine hervorragend simple Lösung an.

Zielseiten-Weiterleitungen vermeiden

Die mobile Variante von bundestag.de bietet ein weiteres Beispiel für eine Optimierung der Ladezeit. Ruft man die Domain bundestag.de mit einem Smartphone oder Tablet auf, so wird man gefragt, ob man zur mobilen Variante wechseln möchte. Bejaht man dies, wird man zu erst auf die Domain m.bundestag.de und anschließend auf bundestag.de/mobil weitergeleitet. Im Falle der ersten Weiterleitung könnte man nun über Responsive Webdesign vs. Mobile Site und Usability-Fallstricke im Allgemeinen diskutieren. Die zweite Weiterleitungen ist aber auf jeden Fall unnötig; hier könnte man direkt von bundestag.de auf bundestag.de/mobil springen.

Das sagt PageSpeed Insights zu den Weiterleitungen

Das sagt PageSpeed Insights zu den Weiterleitungen

Weiterleitungen sollten generell auf ein Minimum beschränkt werden. Denn jede Weiterleitung erzeugt einen eigenen http-Requests, dessen Antwort abgewartet werden muss, bevor das eigentliche HTML-Dokument überhaupt angefordert werden kann. Zudem ist es empfehlenswert, immer direkt mit dem http-location-header zu arbeiten. Eine Weiterleitung auf HTML- oder Javascript-Basis sorgt für weitere Verzögerung, da die kompletten Inhalte quasi doppelt geladen werden müssen.

Fallbeispiel #4: otto.de

Auch am Beispiel des deutschen Online-Shops otto.de lassen sich hervorragend zwei Optimierungstechniken erklären.

Bilder optimieren

Bilder stellen nach wie vor ein prozentual hohen Anteil an der gesamten Dateigröße einer Webseite. Laut httparchive.org waren 2014 durchschnittlich über 50 Bilder auf einer einzigen Webseite eingebunden. Die zu übertragenden Daten durch Bilder legten von 2013 auf 2014 sogar um 21 Prozent zu. Es gibt also gute Gründe – und zum Glück auch viel Potential – um Bilder für das Web hinsichtlich einer schnelleren Ladezeit zu optimieren.

Alleine auf der Startseite von otto.de ließen sich laut Google PageSpeed Insights 156 KB durch eine Optimierung der Bilder einsparen. In Summe werden ca. 900 KB Bildmaterial angefordert, wodurch die prozentuale Ersparnis bei über 17 Prozent liegen würde. Laut similarweb.com hat otto.de 16.900.000 Besucher pro Monat. Würden alleine davon nur 50 Prozent die Startseite besuchen, könnten monatlich über 2,6 Terabyte an übertragenden Daten eingespart werden.

Bilder komprimieren

Bei der Komprimierung von Bildmaterial muss man zwischen zwei verschiedenen Verfahren unterscheiden. Die verlustfreie Komprimierung (lossless) zeichnet sich dadurch aus, dass das Bild in seiner Qualität komplett unverändert bleibt. Ein Reduzierung der Dateigröße ist dennoch durch geschickte Kompression sowie das Entfernen unnötige Meta-Informationen möglich. Hingegen geht die verlustbehaftete Kompression (lossy) noch einen Schritt weiter. So werden beispielsweise Farbwerte ausfindig gemacht, die sich nur sehr marginal unterscheiden und für das Auge kaum sichtbar angeglichen werden können. Dadurch enthält die Bilddatei weniger Informationen und kann besser komprimiert werden.

Ein Bild-Komprimierung ist im kleinen Rahmen problemlos mit Online-Tools wie tinypng.com (für PNGs) oder tinyjpg.com (für JPGs) möglich. Nach dem Hochladen seiner Originaldatei erhält man innerhalb weniger Sekunden eine optimierte Version. Gerade bei PNGs sind Einsparungen bei der Dateigröße höher als 50 Prozent keine Seltenheit. Professionelle Webentwickler können hier wieder einen Schritt weiter gehen und den Komprimierungsprozess in ihren Task Runner integrieren. Für Grunt steht beispielsweise das Imagemin-Plugin zur Verfügung.

Mit tinypng.com und tinyjpg.com sind teilweise erhebliche Einsparungen möglich!

Mit tinypng.com und tinyjpg.com sind teilweise erhebliche Einsparungen möglich!

Idealerweise sollte direkt im ersten Schritt überprüft werden, ob das verwendete Bildformat wirklich das beste ist. Gerade bei großen Fotos lässt sich mit JPGs eine wesentlich kleinere Datei erzielen als mit PNGs. Dies ist aber keinefalls in Stein gemeißelt, weshalb eine kurze Überprüfung nie schaden kann.

Bilder in der richtigen Auflösung ausliefern

Ein Problem, welches otto.de ebenfalls betrifft, ist die Auslieferung von Bildern in zu hohen Auflösungen. Beispielsweise werden große Slider-Bilder im Kopfbereich in der Breite von 1920 Pixeln angefordert, obwohl sie auf den meisten Desktop-Rechnern nur mit einer Breite von 960 Pixeln eingebunden werden. Hier werden schnell mehr als hundert Kilobyte umsonst übertragen.

Das Bild auf otto.de wird mit 1920 Pixeln vom Server angefordert, aber nur in einer Größe von 880 Pixeln angezeigt.

Das Bild auf otto.de wird mit 1920 Pixeln vom Server angefordert, aber nur in einer Größe von 880 Pixeln angezeigt.

Natürlich ist die korrekte Auslieferung von Bildern durch Responsive Webdesign, sehr fluide Layouts und hochauflösende Bildschirme (Stichwort “Retina”) nicht leichter geworden. Doch hier springt seit kurzem das <picture>-Element in die Presche, für das bereits sehr gute Javascript-Polyfills existieren. Dies im Zusammenspiel mit einem Image Server erlaubt auch großen Online-Shops und Webseiten das nahezu pixelperfekte Ausliefern von Bilddaten.

Base64-Zeichenketten verwenden

Gerade bei sehr kleinen und nur einmalig verwendeten Grafiken unter einem Kilobyte macht es meistens Sinn, diese nicht als extra Bilddatei vom Server zu laden. Im Zuge der obersten Pagespeed-Prämisse, http-Requests zu reduzieren, bietet sich eine Einbettung als Data-URL beziehungsweise Base64-Zeichenkette an. Dabei wird die reine Bilddatei quasi base64-kodiert und anschließend als Einzeiler direkt im <img>-Element oder als CSS-Hintergrund eingebunden. So wird zwar das initiale HTML-Dokument oder die CSS-Datei größer, der eingesparte http-Request wiegt dies aber in den allermeisten Fällen wieder auf.

Um Base64-Bilder zu generieren gibt es dutzende Online-Tools wie base64-image.de. Der Profi wird wahrscheinlich eher direkt zu Photoshop-Plugins wie PNG Hat greifen, welches einen direkten Export von Ausschnitten oder einzelnen Ebenen auf Knopfdruck ermöglicht.

CSS-Sprites einsetzen

Auch wenn die guten alten CSS-Sprites in den letzten Jahren durch das Aufkommen von Icon-Fonts oder Retina-Versionen etwas an Bedeutung verloren haben, so sind sie nach wie vor ein solides Werkzeug der Pagespeed-Optimierung. Grob gesagt werden bei dieser Technik mehrere einzelne Grafiken in einer einzigen großen Bildatei platziert. Über ein CSS-Hintergrundbild und die Eigenschaft background-position lassen sich die einzelnen Grafiken dann innerhalb der Bilddatei wieder getrennt ansteuern beziehungsweise im Frontend ausgeben. So sind für ein eigenes Icon-Set von beispielsweise 40 Icons nicht mehr 40 http-Requests notwendig, sondern nur noch ein einziger.

Mit LazyLoading Bilder nachladen

Geschicktes und sauber funktionierendes LazyLoading erfordert bei großen Projekten zwar allerlei technische Raffinesse, kann die Ladegeschwindigkeiten dafür aber auf ein neues Level heben. Dieser Begriff beschreibt die Technik, Bild-Dateien erst vom Server anzufordern, sobald der Benutzer im Begriff ist, sie wirklich zu sehen. In der Regel wird darunter verstanden, dass Bilder, die beim Scrollen in den sichtbaren Bereich (Viewport) gelangen, erst dann geladen werden.

Mit etwas Aufwand lässt sich diese Technik aber noch weiter perfektionieren. Warum sollte beispielsweise ein großer Kopf-Slider bereits beim Seitenaufruf alle zehn Bilder laden und nicht erst das jeweils vorherige oder nächste, sobald der Besucher die Maus über die jeweilige Pfeil-Navigation bewegt hat?

Für kleinere Projekte gibt es hingegen bereits fertige jQuery-Plugins wie unveil.js, die einen unkomplizierten Einstieg in das Thema ermöglichen.

Kritische Ressourcen prioritisieren

Das Prioritisieren von kritischen Ressourcen beziehungsweise das nicht blockierte Laden von above-the-fold-Inhalten stellt sicherlich die Königsdisziplin der Pagespeed-Optimierung dar. Gleichzeitig ist es auch der PageSpeed Insights – Hinweis, der für die meisten Webseiten-Betreiber schier unlösbar scheint. Grob gesagt beschreibt dieser Punkt, dass Javascript- und CSS-Code, der für den sofort sichtbaren Bereich einer Website benötigt wird, auch unmittelbar zur Verfügung stehen sollte. Code, der hingegen nicht kritisch ist, muss in der Lade-Reihenfolge weiter hinten platziert werden oder im Idealfall sogar asynchron, also erst nach dem Laden aller anderen Ressourcen, vom Server angefordert werden.

Was sich in der Theorie erstmal nicht allzu schwierig anhört, stellt selbst erfahrene Webentwickler in der Praxis vor einige Probleme. Zuerst ist auszumachen, was man auf der eigenen Webseite eigentlich unter dem sofort sichtbaren Bereich versteht. Geht man beispielsweise von einem Notebook oder einem 27 Zoll iMac aus? Wie sieht es auf Smartphones oder Tablets aus? Und haben verschiedene Seitentypen nicht auch unterschiedliche sofort sichtbare Bereiche? Eine pauschale Antwort lässt sich hier auf keinen Fall finden. Manchmal darf und muss die Antwort auch sein, an dieser Stelle auf eine weitere Optimierung zu verzichten.

Wer hingegen weniger Probleme bei der Herausarbeitung der sofort sichtbaren Bereiche hat, stößt schnell auf technische Hürden. Eine komplette Zusammenlegung aller CSS- und Javascript-Dateien, wie weiter oben im Artikel empfohlen, funktioniert nun nämlich nicht mehr. Vielmehr müssen die Dateien jeweils in kritisch und nicht kritische Bereich aufgeteilt werden. Gerade bei Javascript-Dateien ist dies leichter gesagt als getan. Funktionalitäten, die das Rendering des sofort sichtbaren Bereiches beeinflussen, müssen hierfür nicht selten in natives Javascript zurückverwandelt werden. Schließlich kann schlecht auf das fertige Laden der großen jQuery-Bibliothek gewartet werden.

Im Falle von otto.de lässt sich dieses Problem gut am ersten Inhaltsbereich “Empfehlungen für Sie” veranschaulichen. Hier werden Inhalte erst nachträglich per AJAX eingefügt. Auch die Funktionalität des Sliders wird über Javascript sichergestellt. Dies bedeutet, dass der Bereich dem Webseiten-Besucher nicht sofort angezeigt werden kann, sobald zuständiges HTML und CSS verfügbar ist. Vielmehr muss darauf gewartet werden, dass die komplette externe Javascript-Datei geladen und ausgeführt wurde. Also spricht man von einer Javascript-Ressource, die das Rendering blockiert.

Zusammenfassend ist zu sagen, dass das Prioritisieren von kritischen Ressourcen zwar das letzte bisschen Ladegeschwindigkeit herauskitzeln kann, Webseiten-Betreiber aber häufig vor enorme technische Herausforderungen stellt. Unter Berücksichtigung aller anderen im Artikel erläuterten Optimierungsmaßnahmen dürfte man sich aber bereits eine sehr solide Basis mit vergleichsweise überdurchschnittlich hoher Ladegeschwindigkeit geschaffen haben.


Dieser Artikel wurde am 5. Mai 2015 verfasst. Sämtliche Screenshots und Fallbeispiele wurden zu diesem Datum erfasst.

Dieser Artikel wurde am 05.05.2015 veröffentlicht

Wer schreibt hier?

Torben Leuschner - Webentwickler

Hi, ich bin Torben und baue leidenschaftlich gerne Webseiten. Also habe ich mein Hobby zum Beruf gemacht und bin seit 2008 als Webentwickler Selbständig tätig. Obwohl ich schwerpunktmäßig für Kunden arbeite habe ich auch sehr viel Freude an der Realisierung eigener Projekte. Daraus resultierend hat sich eine große Affinität zu den Themen Online Marketing und Suchmaschinenoptimierung entwickelt. Gelegentlich schreibe ich auf Twitter, viel aktiver bin ich allerdings auf Facebook. Gerne können wir uns dort vernetzen!

Wie stehst du dazu?

  1. […] Pagespeed optimieren: Hier müssen auch die “Großen” nachbessern. Eine niedrige Ladezeit ist essentiell für eine gute Nutzbarkeit einer Seite und damit ein wichtiges indirektes Ranking-Kriterium. Webentwickler Torben Leuschner beschreibt anhand von drei prominenten Fallbeispielen (Zalando, Bild, Otto), wo und wie der Pagespeed optimiert werden kann. [Torben Leuschner] […]

  2. […] Pagespeed-Optimierung am Beispiel vier großer Webseiten – Obwohl jedem Webworker klar sein dürfte, dass die Optimierung einer Webseite auf eine höhere Ladegeschwindigkeit ein Erfolgsfaktor ist, scheitern sehr viele an der Umsetzung. Weiter… […]