Da wir es ja neulich von Seiten-Ladezeiten hatten, nämlich einmal die Betrachtung unserer Wettbewerber und dann die Anleitung, wie man Google-Fonts in die eigene Seite einbindet, war ich natürlich hellhörig geworden, als ich kürzlich eine Ausschreibung für eine Ladezeitoptimierung für die Seite Cat-News.net sah. Das Thema fand ich superinteressant und habe uns natürlich sofort beworben. Erfreulicherweise wurden wir mit der Auftraggeberin schnell einig, und so ging es frisch ans Werk.

Aus dem Projekt-Nähkästchen der Fjordkommission

Wie sich bald herausstellte, sollte dies ein aufregender Fall werden. Deshalb haben wir uns entschlossen, ein bisschen darüber aus dem Nähkästchen zu plaudern, um Dir einen Einblick in unsere Arbeit zu geben. Also lass uns am besten gleich anfangen.

Erst einmal einen Eindruck verschaffen

Mit den üblichen Analysewerkzeugen von Google, GTmetrix und Pingdom.com testete ich die Seite zunächst in ihrem aktuellen Stand. Gerade bei Google war der Wert für die Ladezeit sehr schlecht, was auch schon zu einer Verschlechterung der Platzierung bei den Suchergebnissen führen kann. Das Ergebnis dort war 42 von 100 Punkten. Bei GTmetrix sah es mit 56% ein wenig besser aus, aber auch dort mit einem „E“ (Note 5) immer noch stark verbesserungswürdig. Pingdom hatte nicht so viel zu meckern und vergab eine Wertung von 82%, das war Note 2 (ein B).

Aber was war der Grund für die schlechten Werte? Die Seite lud an sich gefühlt schnell und flüssig. Als Seitenbesucher hatte man davon nichts gemerkt.

Ursachen für schlechte Ladezeit-Bewertungen

In dem Screenshot sieht man in der obersten Zeile der Tabelle die Note F und 0 Punkte für die Problematik mit den Bildern. Der Rest der Bewertung ist halb so wild. Zwar zeigen die Analysewerkzeuge einem außer der Benotung auch die tatsächlich verstrichene Zeit zum vollständigen Laden der Seite an, aber diese schwankt bei wiederholten Tests immer sehr stark, und deckt sich auch oft nicht mit der selbst beobachteten Dauer im eigenen Browser, ist also nicht sehr aussagekräftig.

Wichtigster Anhaltspunkt ist dagegen die Angabe der Menge geladener Daten. Im vorliegenden Fall waren das ca. 4,5MB, die der Browser laden musste, um die Seite vollständig anzuzeigen. Zu dieser Datenmenge gehören außer dem Quelltext der Seite selbst in der Regel noch Bilder, Programmcode (meist JavaScript) und Formatierungsangaben (Stylesheets, CSS).

Zum Erreichen einer Ladezeitoptimierung listen Google, GTmetrix und Pingdom detailliert auf, was besonders lang gedauert hat, und welche Einzelnote man dafür bekommt. Zusätzlich gibt es noch Informationen darüber, wie die Probleme zu beheben sind. Allerdings nicht in der Form, „klicke hier und stelle dort ein“, sondern eher allgemeiner Natur. Denn logischerweise kann man nicht allgemeingütig für jede Website im Internet konkrete Optimierungstipps geben.

Typische Fehler

Grundsätzlich kann man sagen, dass große Bilder meistens der Grund für schlechte Ladezeiten sind. Viele Website-Betreiber sind sich dessen nicht bewusst, wenn sie hochauflösende Fotos in ihrer Seite einbauen.

Ein Beispiel: Auf Deiner Startseite hast Du ein Hintergrundbild, das der Browser in der Größe 1.280 x 850 Pixel anzeigen soll. Du lädtst dafür ein wunderschönes Foto hoch, das Du direkt von Deiner Digitalkamera mit 12 Megapixel aufgenommen hast. Das Foto ist 8 Megabytes groß und hat eine Auflösung von 4.256 x 2.832 Bildpunkten.

Das ist weit über das Ziel hinausgeschossen. Man muss nun unnötig lange warten, um dieses Bild herunterzuladen, und anschließend dann noch auf die Maße 1280 x 850 zu verkleinern. Also nur etwa ein Zehntel der ursprünglichen Fläche. Eine irre Verschwendung. Hinzu kommt, dass die meisten Fotos ohne jegliche Komprimierung hochgeladen werden, was zusätzlich unnötige Ladezeit kostet. Und wenn man dann noch mehrere solcher Fotos auf einer Seite hat… Du ahnst es sicher.

Außer Bildern werden auch viele weitere Mechanismen zur Ladezeitoptimierung nicht berücksichtigt. Zum Beispiel die Minimierung der Anzahl der Anfragen, die ein Browser an den Webserver stellen muss, um alle Dateien, die in der Seite gebraucht werden, herunterzuladen. Durch geschicktes Zusammenfassen spart man eine Menge Zeit. Außerdem gibt es noch Potenzial in der Vermeidung von Aufrufen zu Drittparteien (sogenannte „externe Ressourcen“), weil man dort keinerlei Einfluss auf die Wartezeit hat, bis der entsprechende Inhalt da ist.

Aber das soll hier ja jetzt keine Anleitung werden, sondern ein Bericht aus dem „echten Leben“.

Das Corpus Delicti

Im vorliegenden Fall lag die schlechte Bewertung zum größten Teil an der Verwendung von Bildern, die einerseits nicht komprimiert waren und andererseits in einer größeren Größe geladen als angezeigt wurden. Konkret handelte es sich um eine große Anzahl von Vorschaubildchen für die Nachrichtenbeiträge, die man von der Startseite aus öffnen kann. Diese sind zum Teil winzig, nur 98×65 Pixel groß, wurden aber dennoch in der Größe von 540×350 Pixel heruntergeladen und dann erst im Browser zur Anzeige verkleinert.

Die Websitebetreiberin konnte aber gar nichts dafür, denn das war eine Unzulänglichkeit in ihrem WordPress-Theme, welches so programmiert ist. In dem Theme sind gar keine verschiedenen Bildgrößen für die Startseite vorgesehen. Man kann also z. B. nur auswählen, dass in einem Kasten sechs Nachrichtenbeiträge als Vorschau angezeigt werden sollen, und den Rest übernimmt das Theme. Dieses geht dann so vor, dass es jedes Titelbild der jeweiligen Beiträge, je nach Darstellungsart und Position in der jeweils passenden Größe anzeigt. Aber eben ohne auch ein Bild in der tatsächlichen Größe mit den richtigen Maßen zu verwenden.

So kam die Seite auf 65 Bilder, von denen nur eine Handvoll in der ursprünglichen Größe anzuzeigen war, und den Rest musste der Browser verkleinern.

Ran an die Ladezeitoptimierung

Zugegeben, bei der ersten Betrachtung der Ausgangslage, als ich den Auftrag annahm, hatte ich die Komplexität des Problems unterschätzt. Da war es nicht mit ein paar Einstellungen und den üblichen Maßnahmen zur Komprimierung und Minimierung getan. Zwar konnte ich mit den gängigen Maßnahmen wie Unterstützung des Browser-Cachings, Zusammenfassung von Skripten und Stylesheets sowie der lokalen Speicherung der Google-Fonts ein paar wichtige Prozentpunkte herausholen, aber die Note 6 für die vielen Bildchen zog den Durchschnitt weit herunter. Das erforderte größeren Aufwand.

Laden der richtigen Bildgrößen

Hierzu musste ich in den Programmcode eingreifen, um das Theme dazu zu bringen, je nach anzuzeigender Größe unterschiedliche Bilder zu laden.

Wo zuvor ganz einfach das Titelbild des Nachrichtenartikels abgerufen und dann verkleinert wurde, habe ich nun je Situation verschiedene Adressen für die verschiedenen Bilder abgerufen. Diese neuen Größenvarianten für die Bilder musste ich natürlich zuvor anlegen lassen. Glücklicherweise unterstützt WordPress genau solch ein Vorgehen mit hauseigenen Mitteln, die ich nur nutzen musste.

Man definiert also zunächst die jeweiligen Bildgrößen, die man zusätzlich braucht. In diesem Fall waren das drei neue Größen: 80×80, 98×65 und 121×81 Pixel. Man gibt diesen Größen jeweils einen Namen, über den sie angesprochen werden können. Mit einem Werkzeug von WordPress (ein Plugin namens „Regenerate Thumbnails“) kann man anschließend für jedes in der Bildersammlung der Website gespeicherte Bild diese drei Größenversionen anlegen lassen.

An den Stellen im Code, wo diese Bildchen verwendet werden, musste ich nun beim Laden der Bilderadresse diese ändern in die Adresse mit der an dieser Stelle passenden Größe. Im Beispiel unten war das statt „post_thumbnail“ (das Titelbild, ohne Größenangabe, also in voller Größe) das Bild mit der Größenangabe „custom-mash-thumb“. Das ist die Größe 80×80 für die Anzeige in der Seitenleiste rechts.

Es gab natürlich noch mehrere weitere Stellen im Code, wo ich derlei Änderungen machen musste. Somit wurde aus einem Job von anfangs geschätzten zwei Stunden ein ganzes Wochenende. Natürlich ohne Aufpreis für die Kundin, denn Zusage ist Zusage, und die Fjordkommission steht zu ihrem Wort. 😉

Ergebnis der Ladezeitoptimierung

Bevor die Bilder verkleinert waren, blieb das Ergebnis der bisherigen Optimierungsmaßnahmen enttäuschend. Zu schwer wog dieser Mangel mit den Bildern, dass diese nicht durch den Rest kompensiert werden konnten.

Aber nachdem nun alle Fotos in der korrekten Größe geladen wurden, war schlagartig eine Verbesserung auf Note „A“ (also eine 1) erreicht. Damit waren wir dann endlich zufrieden.

Man beachte außer der Note und der Wertung von 93% die drastisch reduzierte Datenmenge von vormals 4,5 MB auf nun nur noch 1,91 MB. Diese 2,6 MB Unterschied stammten allein von den zu großen Bildern. Die Zeitangabe von 10,6 Sekunden ist wie oben schon gesagt, wenig aussagekräftig. Bei Tests zwischendrin, mit teils noch sehr schlechten Werten, wurden auch schon mal Zeiten von 4 Sekunden angezeigt. Die Gründe dafür weiß eher GTmetrix.

Was nun noch an Potenzial zur Ladezeitoptimierung übrig ist, sind Abhängigkeiten von externen Ressourcen wie von Facebook und Google. Auch in der Kategorie „YSlow“, die sich nicht wesentlich verbessern ließ. Derlei Kriterien sind nur noch mit erheblichem Aufwand zu verbessern. Und sie beschleunigen das tatsächliche Laden für den Seitenbesucher nur unwesentlich.