Ob Server oder Browser: Ohne Cache kein Speed
Philipp Zeder
Kategorie:in
Entwicklung & Performance
Veröffentlicht am 11. Aug. 2017
Aktualisiert am 10. Sept. 2024
Das Thema Cache ist ein Muss, wenn Sie Ihre Website auf Geschwindigkeit trimmen möchten. Aber was macht ein Cache eigentlich? Welche Arten von Caches gibt es? Und welche Cache-Arten sollten Sie überhaupt nutzen? Wir zeigen es Ihnen.
Was ist ein Cache?
Das Wort Cache stammt auf dem französischen und bedeutet «Versteck». Die IT-Welt, die ja sonst grösstenteils auf englischsprachigen Prinzipien fusst, nutzt die Bezeichnung für einen Puffer bzw. Zwischenspeicher. Können Sie sich noch an die Anti-Shock-Funktionen Ihres Discmans erinnern? Im Grunde genommen war dies nichts anderes als ein Cache.
Caches sind allgegenwärtig und kommen auf sämtlichen Schichten des OSI-Modells zum Einsatz. Kurzum: Überall wo Daten ausgetauscht und berechnet werden, kommt es zu Wartezeiten. Mithilfe von Caches lassen sich diese Wartezeiten verringern. Caching bedeutet also Daten an einem speziellen Ort vorzuhalten, weil sie von dort schneller abgerufen werden können als vom Ursprungsort.
Zwei Arten von Caches
Im Web-Kontext kann man zwei Arten von Caching unterscheiden:
- Am Ort, wo eine Website generiert wird, also auf Serverseite: Der serverseitige Cache.
- Auf dem Gerät des Besuchers, auf dem die Website angezeigt wird: Der clientseitige Cache.
Serverseitiger Cache: Grösste Einsparmöglichkeiten
Die Hauptarbeit beim Generieren und Ausliefern einer Website wird auf dem Server erledigt. Dementsprechend sind dort die Optimierungsmöglichkeiten durch den Einsatz von Caches besonders gross.
Serverseitig kommen an mehreren Orten Caches zum Einsatz. Sie als Betreiber einer Website haben deshalb mehrere Optionen, durch geschicktes Caching die Auslieferung Ihrer Website zu beschleunigen.
Seiten-Cache
Mit einem Seiten-Cache lässt sich der grösse Geschwindigkeitsgewinn herausholen. Er liefert eine fixfertige HTML-Seite aus, der Inhalt wird also nicht mehr dynamisch generiert. PHP und MySQL sind bei der Datenlieferung aus dem Seiten-Cache nicht mehr involviert. Das spart massig Zeit, denn Webserver sind auf die Auslieferung von Text- und Bilddateien optimiert. Der Datendurchsatz ist riesig.
Seiten-Caches lassen sich auf verschiedene Arten lösen. Der generierte HTML-Code lässt sich als Datei auf der Harddisk oder im RAM, als Eintrag in der Datenbank sowie in spezialisierten Cache-Modulen wie LiteSpeed Cache, Memcached oder APCu ablegen. Caching-Plugins für Systeme wie WordPress funktionieren in der Regel nach dem Harddisk-Prinzip, da diese Methode bei den meisten Hosting-Anbietern funktioniert. Wo Dienste wie Memcached oder APCu verfügbar sind, lohnt sich deren Einsatz. Sie legen die Daten im Arbeitsspeicher des Servers ab, was für noch schnellere Zugriffszeiten sorgt.
Tipp: Nutzen Sie auf unseren Servern LiteSpeed Cache. Die Caching-Methode verspricht dank der Ablage der Daten im RAM und der direkten Integration in den Webserver noch kürzere Zugriffszeiten als andere Seiten-Caches. Auf einem Speedserver steht Ihnen zusätzlich Memcached zur Verfügung.
Seiten-Caches lassen sich einfach für Websites konfigurieren, deren Inhalte sich nicht ständig ändern. Im Zusammenspiel mit passenden Plugins wie LiteSpeed Cache für WordPress oder LiteMage für Magento eignet sich ein Seiten-Cache aber genauso für Websites mit vielen dynamischen Inhalten wie Online-Shops, für die Caching in der Regel komplexer ist.
Ja, unbedingt. Der Einsatz eines Seiten-Caches ist für alle Arten von Websites empfohlen. Die Zeitersparnis gegenüber dynamisch generierten Inhalten ist schlichtweg zu gross, um sie zu vernachlässigen.
Opcode-Cache
Eine Stufe unter dem Seiten-Cache befindet sich der sogenannte Opcode-Cache. Ein Opcode-Cache speichert den bereits interpretierten PHP-Code in maschinenlesbarer Form. Normalerweise vergisst der PHP-Interpreter den gesamten Code nach einem Aufruf der PHP-Datei und muss bei einem erneuten Aufruf alle Anweisungen neu berechnen. Dank dem Opcode-Cache muss der PHP-Interpreter bei weiteren Aufrufen der PHP-Datei nicht mehr ans Werk und der Code wird direkt ausgeführt. In unseren Tests mit WordPress wurden Anfragen an die Website dank Opcode-Caching doppelt so schnell beantwortet.
Ja, unbedingt. Auf unseren Servern ist der PHP-Opcode-Cache OPcache deshalb automatisch aktiv.
Object-Cache
Der Object-Cache spart Zeit bei der Berechnung von PHP-Objekten. WordPress bietet zum Beispiel einen eingebauten Object-Cache, der jeweils für eine Anfrage gültig ist. Wird also ein Objekt auf einer Seite mehrmals aufgerufen, wird der erste Aufruf im Object-Cache abgelegt. Weitere Vorkommnisse des Objekts auf der Seite werden direkt aus dem Cache geliefert. Object-Caching lässt sich auch auf einen Caching-Modul wie Memcached oder APCu auslagern. Im Fall von WordPress gibt es Plugins, die die Kommunikation mit dem Modul erledigen.
Ja, Object-Caching ist sinnvoll und macht auch die Bedienung eines CMS-Backends schneller. Systeme wie WordPress haben bereits von Haus aus einen Object-Cache eingebaut.
Datenbank-Cache
Typische datenbankbasierende Content-Management-Systeme (CMS) legen Text-Inhalte und Konfigurationen in der Datenbank ab. Das heisst, das CMS greift oft auf die entsprechende Datenbank zu. Auch Datenbanken werden mit geschicktem Caching performanter. Die nötigen Parameter sind auf üblichen Webhosting-Angeboten bereits optimiert und lassen sich nicht durch eigene Befehle verändern.
Datenbank-Caching wird von der Datenbank bereits selbst gesteuert, die optimalen Einstellungen in der Regel vom Hosting-Anbieter vorgegeben. Eigene Anpassungen erfordern tieferes Wissen und sind meist nur auf Hosting-Angeboten mit root-Zugriff möglich.
CDNs
Wenn auch nicht auf dem eigenen Server, lassen sich CDNs (Content-Delivery-Networks) ebenfalls als serverseitige Caches bezeichnen. CDN-Anbieter wie KeyCDN betreiben Server, die auf der ganzen Welt verteilt sind. So bringen diese Anbieter statische Inhalte geografisch näher an die Besucher Ihrer Website, die entsprechenden Datenpakete müssen also einen kürzeren Weg zurücklegen. Das spart Zeit.
Der Einsatz eines CDNs lohnt sich vor allem für Websites, deren Besucher aus aller Welt stammen.
Clientseitiger Cache: Eingesparte Datenpakete
Der clientseitige Cache im Web-Kontext ist nichts anderes als der Cache in Ihrem Browser. CSS-, JavaScript- oder Bilddateien ändern sich nicht oft. Diesen Umstand nutzt der Browser und legt die Dateien in seinem Cache ab. Wird eine Website nochmals aufgerufen, kann der Browser diese Dateien direkt anzeigen oder verarbeiten. Der weite Weg der Datenpakete vom Server zum Browser entfällt damit.
Der clientseitige Cache lässt sich zwar als Website-Betreiber nicht komplett kontrollieren, aber zumindest mit serverseitigen Befehlen beeinflussen. So können Sie bestimmen, wie lange gewisse Inhalte Ihrer Website im Browser-Cache des Betrachters zwischengelagert werden sollen. Hinweise darauf, wo und wie Sie das Browser-Caching für Ihre Website noch verbessern können, liefern Tools wie der Website-Speedtest von Pingdom, GTmetrix oder PageSpeed Insights von Google.
Die Anweisungen zum Browser-Caching werden über die sogenannten HTTP-Headers übermittelt und können zum Beispiel in der .htaccess-Datei einer Website definiert werden.
Grundsätzlich stehen 4 Typen von HTTP-Headers zur Verfügung, die das Steuern des Caches im Browser möglich machen: Expires
, Cache-Control max-age
, Last-Modified
und ETag
. Expires
und Cache-Control max-age
steuern den Zeitraum, während dem ein Browser die angeforderte Datei zwischenspeichert, ohne beim Server nach einer neuen Version der Datei anzufragen. Die beiden Befehle werden deshalb als «starke» Caching-Header bezeichnet. Last-Modified
und ETag
ermöglichen es dem Browser zu prüfen, ob die zwischengespeicherte Version einer Datei noch gültig ist und aus dem Cache geladen werden kann. Die beiden Befehle werden als «schwache» Caching-Header bezeichnet, da der Browser beim Server anfragen muss, ob die gespeicherte Version noch gültig ist.
Welche Cache-Headers soll ich verwenden?
Google empfiehlt je einen starken und schwachen Caching-Header zu nutzen. Das Duo Expires
und ETag
hat sich bewährt, da die beiden Header unter den Browsern die grösste Unterstützung geniessen.
Die Anweisungen für den Expires
-Header können zum Beispiel folgendermassen in der .htaccess-Datei Ihrer Website definiert werden:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/x-icon "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType text/html "access 24 hours"
ExpiresDefault "access 1 month"
</IfModule>
Mit diesen Beispielanweisungen werden Dateien vom Browser standardmässig bis zu einem Monat gecached. Für einzelne Dateitypen wie JPG-Bilder sogar bis zu einem Jahr. Die ideale Konfiguration ist, wie so oft, für jedes Projekt unterschiedlich. Wenn sich Inhalte auf Ihrer Website nicht oft ändern, können Sie die Expires-Anweisung auf hohe Zeiträume setzen. Liefern Sie häufig neue Versionen von Dateitypen aus, empfiehlt sich das Setzen von tieferen Zeiträumen. ETags werden in den meisten Fällen übrigens automatisch vom entsprechenden Webserver generiert.
Tipp: Auf unseren Servern werden sowohl Expires-Anweisungen als auch ETags für statische Dateien vom Webserver automatisch mitgeliefert. Sie können die Anweisungen und ETags bei Bedarf durch eigenen Code oder über Plugins für Ihr Content-Management-System überschreiben.
Schlussendlich bleibt auch für den clientseitigen Cache die Frage:
Ja, unbedingt. Der Einsatz des clientseitigen Caches reduziert die Datenmenge, die beim wiederholten Besuch Ihrer Website übertragen wird. Das führt zu kürzeren Wartezeiten.
Kennen Sie weitere Caching-Geheimtipps? Oder haben Sie Fragen zum Beitrag? Wir freuen uns über Ihren Kommentar.
Beteilige dich an der Diskussion
8 Kommentare
Hallo Peter, merci für den Hinweis. text/x-javascript
ist in der Tat veraltet und muss laut RFC 4329 application/javascript
heissen. Ich habe den Artikel soeben angepasst.
Passt nur bedingt zum Thema, aber ihr gebt gzip auf euren Servern. Warum kein broetli?
Grüße Simon
Hallo Simon, Brotli wirst Du demnächst bei uns nutzen können. Mehr dazu erfährst Du in Kürze hier im Blog :)
Irgendwie gibt es in letzter Zeit viele Blog Einträge zu Cache…. glaube das Thema ist langsam abgedeckt.
Bei grossen Websites ist der Varnish Cache die Allzweckwaffe
Litespeed Cache finde ich grundsätzlich eine tolle Sache. Mir ist nur nicht klar, ob dadurch die serverseitig erhobenen Statistiken beeinflusst werden.
Hi Ana, die Zugriffs-Logs werden auch beim Aufruf via LiteSpeed Cache ganz normal geschrieben, da der Cache im Webserver eingebaut ist. Die serverseitigen Statistiken werden also nicht beeinflusst.
Hallo Philipp
kann es sein das euer .htaccess Beispiel
bei -> ExpiresByType text/x-javascript «access 1 month»
eigentlich -> ExpiresByType application/javascript «access 1 month»
heissen sollte ?
Oder ist dies Browserabhängig ?
Bei Chrom jedenfalls funktionier text/x-javascript nicht.
Gruss Peter