Der Geduldsfaden von Lesern ist kurz und dünn, wenn es um Ladezeiten von Webseiten geht. Performance ist also essentiell, vor allem für Publisher. Das Team von Leankoala stammt aus dem redaktionellen Umfeld. Grob überschlagen haben wir fast 50 große Webseiten-Relaunches in den letzten Jahren mitgemacht und dutzende Webseiten in der Qualitätssicherung betreut. Dabei wurde der Aspekt Performance stetig relevanter und immer neue Ideen zur Verkürzung der Ladezeiten von redaktionellen Webseiten kamen auf den Markt. Einige der Ideen waren gut, einige sind auch wieder verschwunden.  Vor allem für statische Inhalte, die allen Besuchern gleich angezeigt werden (wie zum Beispiel redaktionelle Inhalte), hat sich Caching zur Verbesserung der Webseitengeschwindigkeit als eine besonders effektive und beliebte Methode etabliert.

Beim bekannten Zwischenlagern von Inhalten haben sich einige Vorgehen durchgesetzt, die bei vielen News-Portalen und Evergreen-Seiten gefunden werden. Unser Web Monitoring unterstützt eure Caching-Strategie mit diversen Tools und wir haben euch eine kurze Übersicht der wichtigsten Caching-Methoden und Werkzeuge für Publisher zusammen gestellt.

Reverse Proxy / Varnish

Redaktionelle Webseiten haben im Normalfall nur einen kleinen Teil an Individualität pro Nutzer. Meist ist es sogar so, dass alle Nutzer den gleichen Inhalt ausgespielt bekommen – Werbung einmal ausgeklammert.  In einem solchen Szenario ist der Einsatz eines Reverse Proxies wie des Varnish die beste Lösung. So ein Caching-Layer funktioniert im Prinzip wie ein Browser-Cache, nur dass er sich auf der Seite der ausliefernden Partei befindet. Gesteuert wird er, identisch zu Chrome, Firefox und Co. ebenfalls über Caching-Header. Sollte man die Lebenszeit eines Artikels auf fünf Minuten gesetzt haben, so wird der Proxy für fünf Minuten eine Seite aus dem Cache ausliefern. Dies kann rasend schnell innerhalb von 20 Milisekunden passieren. Nutzer kommunizieren erst mit neuen Layern, sollte der Reverse Proxy keine Antwort parat haben. Dann wird die Anfrage an den eigentlichen Webserver weitergeleitet. Bei news-getriebenen Webseiten sind Hit-Rates von über 90 Prozent keine Seltenheit.

Da es sich beim Varnish um eine kostenlose Open Source-Lösung handelt lohnt der Einsatz häufig bereits für einfache Seiten, die mit WordPress oder Drupal gebaut worden sind.

Content Delivery Network – CDN

Die Steigerung eines Reverse Proxies ist ein CDN. Ein solches Content Delivery Network hilft dabei Inhalte weltweit schnell auszuliefern. Im Grunde ist ein solches Netzwerk aber “nur” eine verteilte Varnish-Infrastruktur. Man stelle sich vor, in jedem Land dieser Welt einen Caching-Server zu mieten, um somit immer aktuelle Daten schnell zum Endkunden zu bringen, schon ist man beim CDN angelant. Anders als beim Varnish sind solche Infrastrukturen immer von externen Anbietern betrieben, so dass man sich technologisch keine Sorgen machen muss, da alles für einen erledigt wird. Der Einsatz eines CDNs kann den Einsatz eines Reverse Proxies obsolet machen.

JavaScript

Sollte es die Möglichkeit geben sich bei einem Portal anzumelden, so kann dies schnell einen Strich durch die Caching-Rechnung machen. Häufig sind es nur kleine Änderungen an der Webseite, die es unmöglich machen eine Seite als Ganzes zwischen zu lagern. Der Klassiker ist hier der Nutzername, der permanent nach Anmeldung im Header angezeigt wird. Hier gibt es zwei einfache Wege, wie man diese Individualität umgehen kann. Zum Einen kann man alle wichtigen individuellen Daten, wie zum Beispiel den Namen des Nutzers, in Cookies schreiben bei der Anmeldung. Per JavaScript können diese ausgelesen werden und per DOM-Manipulation an die richtige Stelle gesetzt werden. Der JavaScript-Code ist hierbei für alle Nutzer gleich und kann somit aus dem Cache ausgeliefert werden.

Eine weitere Möglichkeit ist AJAX (Asynchronous JavaScript and XML). Per JavaScript können alle individuellen Informationen auf der Seite nachgeladen werden, um sie dann an den richtigen Stellen einzusetzen. Hier muss jedoch aufgepasst werden, dass die Dauer der JavaScript-Requests nicht ähnlich langsam sind wie die Seite ohne Cache und man so für den Nutzer keinen Mehrwert produziert.

Edge Side Includes – ESI

Bei ESI handelt es sich um einen Standard, der von akamai entwickelt wurde. Er ist nicht offiziell von dem w3c übernommen worden, ist aber der Quasi-Standard, wenn es darum geht serverseitig Webseiteninhalte zusammenzustecken um dann eine ganze Seite auszuliefern.

Aber warum kann es sinnvoll sein, seine Webseite aus mehreren Elementen zusammenzustecken? Ganz einfach: Caching. Betrachtet man zum Beispiel eine einfache Rezeptdatenbank. Auf der linken Seite haben wir das Rezept, oben den Header und Rechts die neusten Gerichte im Portal. Wählt man eine ganzheitliche Caching-Strategie so, darf die Seite nicht länger aktuell sein als deren “schwächstes” Mitglied. In diesem Fall wäre es die Sidebar mit den neusten Einträgen. Gehen wir mal davon aus, dass alle fünf Minuten ein neues Rezept hinzukommt, so darf die Zeit, in der die Seite warmgehalten wird, nicht größer sein. Dies ist natürlich schade, da sicherlich der eigentliche Inhalt nicht alle fünf Minuten seine Gültigkeit verliert. Beim Hauptmenü sieht es noch einmal ganz anders aus.

ESI ermöglicht es, die ganze Seite zu zerteilen und individuell zwischen zu lagern. Die Sidebar bekommt die fünf Minuten, der Artikel ist zwei Stunden gültig und das Hauptmenü gegebenenfalls zwei Tage. Beim Aufruf der Seite durch einen Varnish wird jedes Mal die Seite neu zusammengesetzt. Elemente, die noch gültig sind, kommen aus dem Speicher, Elemente, die neu berechnet werden müssen, werden erneut angefragt. Hier darf nicht vergessen werden, dass die Sidebar in unserem Beispiel zwar alle fünf Minuten aktualisiert werden muss, sie dafür aber auf fast allen URLs im Portal identisch vorkommt. Dies bedeutet, dass diese trotzdem mit sehr großer Sicherheit aus dem Cache ausgeliefert wird.

Gültigkeitsdauer variieren

Ein einfacher, aber effizienter Trick die Performance durch Caching zu steigern ist das Variieren der Gültigkeitsdauern einzelner Seiten. Ein Textartikel hat häufig die gleichen max-age header, egal wie alt er ist. Statistisch ist es aber wahrscheinlich, dass er in den ersten 24 Stunden angepasst wird und danach nie wieder. Warum also nicht unterschiedliche Zeiten einstellen? Nach 24 Stunden darf die Seite 12 Stunden vorgehalten werden, nach einer Woche bereits einen Tag. Solche Einstellungen in Kombination mit einem Varnish und ESI können absolute Wunder wirken.

Setzt man sich mit dem Thema des Cachings einmal auseinander, merkt man, dass es sich hier nicht um Hexenwerk handelt, sondern um immer wiederkehrende Muster, für die es bereits Standardlösungen gibt. Diese Lösungen funktionieren zum Teil sogar out-of-the-box fund erzeugen somit kaum Aufwand.

Natürlich bedeuten zusätzliche Caching-Taktiken immer auch mehr Komplexität. Aus diesem Grund überwachen viele unserer Kunden ihre Caching-Header permanent mit Leankoala oder checken kontinuierlich das Vorhandensein aller durch ESI eingebundenen Elemente auf ihrer Webseite.