Gestern (Stand 26. Februar 2014) ist unsere neue, aktualisiert Website inkl. Blog-Redesign an den Start gegangen. Neben den offensichtlichen Design-Anpassungen wurde auch sehr viel an der Technik geschraubt und gefeilt. Das Hauptmerkmal: die Seite (vom Blog einmal abgesehen). Diese ist ein sog. Onepager und besteht nicht mehr wie vorher aus vielen verschiedenen Seiten und Unterseiten, sondern nur noch aus einer einzigen.

Da sich alle Inhalte durch das Onepage-Layout komplett auf einer physischen Seite befinden und in der Regel alle Daten direkt beim Aufruf der Website geladen werden, ist das Risiko groß, dass die Ladezeit der Seite in einen kritischen Bereich hochschnellt. Vor allem dann wenn man – wie wir – vorhat viele Referenzen mit jeweils ein paar Bildern pro Referenz, Slider, Teambilder und zu guter letzt eine in voller Breite angezeigte Google Map anzeigen möchte. Mal von anderen Elementen, wie einer angepassten Font, Icons und verschiedensten Javascript-Spielerein abgesehen.

Heutzutage mag kein Besucher lange Ladezeiten. Allerdings mag er eine reduzierte Darstellung, um eben jenen Ladevorgang kurz zu halten, noch weniger. Vor allem bei dem jetzigen Stand der Technik. Dafür war für uns recht schnell klar: es werden keine Funktionen oder sonstige Spielereien gestrichen. Das ist in unserem Fall sparen an der falschen Stelle. Gerade wir sollten doch zeigen, dass wir Profis sind und wissen, was wir tun. Daher: voller Funktionsumfang bei hoher Geschwindigkeit. Das optimale Erlebnis also.

Dieser Entschluss stellte uns vor einige Denkaufgaben. Letztendlich lauteten die Lösungen Javascript, JSON, Cachify und mod_pagespeed.

Wieso wir JSON & Javascript nutzen

Wir nutzen seitdem wir 2011 den Blog gestartet haben das CMS WordPress. Nicht nur für den Blog, sondern auch für die gesamte Website.

Dieses System sollte natürlich weiterhin bestehen, damit wir euch zum einen weiterhin verstärkt mit spannenden Blogeinträgen beliefern können und zum anderen um unsere Texte, Referenzen etc. schnell und einfach auf der Website einpflegen zu können.

Bei unserem Vorhaben, viele Referenzen mit jeweils vielen Bildern in optimaler (retina-optimierter!) Qualität anzubieten, spielte uns das WordPress da natürlich nicht wirklich in die Karten, da es Daten in eine Datenbank speichert und diese im Frontend wieder ausspuckt. Integral. Das würde bedeuten, dass all unsere Referenzen inklusive deren Bilder beim Laden der Website komplett heruntergeladen werden mussten, selbst wenn man als Besucher garnicht vorhatte, sich welche anzusehen. Wer sich unsere Referenzen (übrigens hier zu sehen) allerdings angesehen hat wird merken: dieser Zustand ist ein absolutes No-Go.

Da sich die Referenzen im Übrigen auch noch ganz oben auf der Seite befinden, bedeutet dies, dass die gesamte Seite erst weiter geladen wird, sobald alle Bilder fertig heruntergeladen wurden.

Die Aufgabe also: wie schaffen wir es, dass zu allererst nur schonmal die kleinen Vorschaubilder der Referenzen geladen und die großen Detail-Ansichten und die Beschreibungstexte erst auf Anfrage des Benutzers vom Server heruntergeladen werden?

Die Lösung: JSON. Mit diesem Datenformat (kurz für JavaScript Object Notation) können wir die Texte, Bilder-URLs etc. in einer vergleichsweisen kleinen Text-Datei (JSON Datei) abspeichern und über Javascript auf Anfrage herunterladen.

Dazu mussten wir dem WordPress beibringen, die Daten nicht nur in der Datenbank, sondern auch zusätzlich in eine angepasste JSON Datei zu schreiben. Über Javascript (mit dem jQuery Framework) wird dann jedes mal, wenn man auf eine Referenz klickt, auf diese JSON Datei zugegriffen und die passenden Daten aus dieser verarbeitet. Und das ganze komplett im Hintergrund. Mit den verarbeiteten Daten werden dann die Titel, Beschreibungstexte und Cycle-Slider gefüllt und dann die Referenz geöffnet, damit der Besucher sich sie ansehen kann.

Wer sich die JSON-Datei ansehen möchte, klickt hier.

Durch diese Methode ersparen wir uns sehr viele Requests und Megabytes an Daten, die beim Aufruf der Seite direkt heruntergeladen hätten werden müssen.

Wozu wir Javascript noch nutzen

Jeder kennst sie: Google Maps. Direkt von Google einbettbare Karten für die eigene Website. In unserem Fall nicht als Iframe von Google angeliefert, sondern über die JS-API. Aus dem einfachen Grund: sie ist anpassbarer und man kann selber Einfluss darauf nehmen, ab wann die Daten der Google Map geladen werden sollen.

Wir haben uns dazu entschieden, im Fußbereich der Website (auch im Blog) immer eine Google Map über die gesamte Breite des Bildschirmes anzuzeigen. Da diese sich aber im Fußbereich befindet, sieht der Besucher sie ja zu allererst nicht. Also dachten wir uns: „Wieso sollten die gesamten Kartendaten auch direkt geladen werden?“

Gedacht, getan. Über Javascript wird der aktuelle Scrollpunkt, also der Abstand vom Kopf der Website zu dem momentan gescrollten oberen Punkt des Browserfensters, errechnet und ausgelesen. Überschreitet dieser Scrollpunkt einen gewissen Wert, sagen wir 300, fängt Javascript an, die Google Map Dateien zu laden.

Du ahnst es vielleicht schon – der Wert 300 steht hier für 300 Pixel. Sobald vom Kopf der Website 300 Pixel runtergescrollt werden, wird eine Funktion aufgerufen, die die Google Maps JS-API lädt, die wiederum das gesamte Kartenmaterial lädt. Und das Ganze ohne, dass der Besucher etwas davon merkt.

So wird verhindert, dass die Datenmengen der Google Map direkt beim Aufruf der Website geladen werden und somit den Aufbau der Seite verzögert.

Wir haben einen kleinen Vergleich angestellt:

Links das Ergebnis mit der „standard“ Art und Weise. Die Google Map wird beim Besuch der Seite direkt geladen. Rechts das Ergebnis mit der „Scroll-Lade“ Variante. Man sieht ganz klar: mehr als doppelt so viele Requests (Anfragen), die der Computer an den Server stellen muss. Da diese Requests auch noch völlig ungecached sind, also bei jedem Aufruf der Seite immer wieder aufs Neue gemacht werden, ist das noch suboptimaler. Das schlägt sich auch direkt in dem Score nieder: nur 74 von 100 möglichen Punkten. Rechts dagegen 98 von 100 möglichen Punkten und „nur“ 56 Requests. (Natürlich sind diese Requests ebenfalls ungecached, werden aber erst später, wenn die Seite schon geladen ist, ausgeführt. Davon bemerkt der Benutzer selber dann garnichts.)

(Für diesen Test haben wir übrigens den Pingdom Speed Test genutzt)

Auch hier konnten wir also einiges an Ladezeit wett machen.

Wozu wir Cachify benutzen

Das WordPress Plugin Cachify dürfte vor allem unter WordPress-Entwicklern kein großes Geheimnis sein. Wir haben auch schon über Cachify berichtet. Wer wissen will, wozu Cachify da ist, liest am besten diesen Artikel kurz durch ;-)

Wozu wir mod_pagespeed nutzen

mod_pagespeed? Das ist ein Server Modul, auf welches wir verstärkt setzen, um unsere Websites automatisch für optimale Geschwindigkeit zu optimieren. Mod_pagespeed wurde von Google entwickelt und gehört zur dessen „Make the web faster“ Kampagne.

Dieses Modul kümmert sich um die Minifizierung und Kombinierung der Javascript und CSS Dateien und minifiziert ebenfalls automatisch den HTML Code. Des Weiteren kümmert es sich darum, dass Bilder automatisch optimal in der kleinstmöglichen Dateigröße (ohne sichtbaren Qualitätsverlust) ausgeliefert wird.

Zu guter Letzt übernimmt dieses Modul auch das Senden der Browsercache Header-Anweisungen, damit Dateien optimal gecacht werden können.

Aber auch viele, viele weitere Optimierungen nimmt dieses hervorragende Modul vor.

Fazit

Durch den Einsatz dieser aktuellsten Techniken konnten wir die gesamte Ladezeit der Website und auch des Blogs auf ein Minimum reduzieren, ohne jedoch ältere Browser (IE8 aufwärts) zu beeinträchtigen. Das ist nicht nur für Besucher erfreulich sondern auch für Suchmaschinen wie Google und Konsorten.

Zu guter letzt: habt Ihr ebenfalls noch Tipps, wie man das gesamte Spiel auf die Spitze treiben kann? Ist Euch etwas aufgefallen oder würdet Ihr etwas anders machen? Hinterlasst einfach einen Kommentar. Wir freuen uns drauf.