Die Seitengeschwindigkeit ist ein unglaublich wichtiger Faktor für UX, Konversionsraten und SEO. In dieser Fallstudie wird ausführlich beschrieben, wie wir eine einfache Implementierung der HTML-Caching-Funktion von Cloudflare auf einer E-Commerce-Website genutzt haben, um die durchschnittliche Seitenladezeit um 28% zu verbessern.
Bist du in Eile? Springe direkt zum TL;DR Zusammenfassung!
Das Ergebnis: 28% bessere Seitenladezeiten mit dem HTML-Caching von Cloudflare
Beginnen wir mit den Ergebnissen dieser Fallstudie, bevor wir uns mit den Details der Umsetzung beschäftigen. Eine Möglichkeit, die Auswirkungen von Optimierungen der Seitengeschwindigkeit zu messen, ist ein Blick auf den Bericht “Site Speed Page Timings” in Google Analytics:
In der obigen Grafik kannst du deutlich die Leistungsverbesserung ab dem Tag sehen, an dem wir das HTML-Caching in Cloudflare aktiviert haben (20. März 2019). reifen24.de, einem deutschen Onlineshop für Reifen. Die durchschnittliche Die Reaktionszeit des Servers sank von etwa 1,5 Sekunden auf unter 1 Sekunde., und auch die durchschnittliche Seitenladezeit hat von der Optimierung profitiert.
Wie du auf dem folgenden Screenshot von Google Analytics sehen kannst, der die durchschnittliche Seitenladezeit seit dem 21. März (dem Tag nach der Einführung) mit dem vorherigen Zeitraum vergleicht, Die Seitengeschwindigkeit wurde um 27.56% verbessert (von 4,49 Sekunden durchschnittlicher Seitenladezeit auf 3,25 Sekunden):
In dem Zeitraum, den wir hier betrachten, wurden keine anderen Änderungen vorgenommen, die einen signifikanten Einfluss (positiv oder negativ) auf die Seitenlade- oder Server-Antwortzeiten gehabt haben könnten.
Lies weiter, um alles zu erfahren, was du über HTML-Caching für E-Commerce-Seiten mit Cloudflare wissen musst und wie die Verbesserungen, die wir in diesem Fall erzielen konnten, nur die Spitze des Eisbergs waren und noch viel Raum für weitere Optimierungen lassen.
Der Kontext: HTML-Caching vs. Standard-Caching bei Cloudflare
Um zu verstehen, wie das HTML-Caching von Cloudflare genutzt werden kann, um die Leistung von Websites (insbesondere von E-Commerce-Websites) zu verbessern, brauchen wir zunächst einige Informationen darüber, was Cloudflare macht und wie die verschiedenen Caching-Stufen funktionieren.
Vereinfacht gesagt, bietet Cloudflare ein Netzwerk von sehr leistungsstarken, schnellen und zuverlässigen Servern, die Teile deiner Website speichern und sie direkt an deine Besucher/innen ausliefern, sodass dein eigener Webserver nicht jedes Mal direkt mit jedem/r Besucher/in kommunizieren muss, wenn eine Ressource angefordert wird. Diese Einrichtung trägt dazu bei, die Ladezeiten deiner Website für Nutzer und Crawler zu verbessern, vor allem, wenn dein eigener Webserver keine sehr gute Leistung hat (oder zumindest nicht so gut ist wie das Servernetzwerk von Cloudflare).
Das Standard-Caching von Cloudflare (d.h. das Speichern von Teilen deiner Website auf ihrem Servernetzwerk) gilt für statische Dateien auf deiner Website, wie z. B. Bilder, PDFs, CSS- oder JavaScript-Dateien. Diese Dateien haben in der Regel jedes Mal, wenn sie angefordert werden, den gleichen Inhalt (ein bestimmtes Bild sieht zum Beispiel für alle Nutzer jedes Mal gleich aus, wenn sie darauf zugreifen). Deshalb kann Cloudflare sie auf ihren Servern speichern (d.h. zwischenspeichern) und sie deinen Besuchern direkt zur Verfügung stellen, ohne dass sie sie immer wieder von deinem eigenen Webserver abrufen müssen.
HTML-Seiten (normale Webseiten) sind anders, denn ihr Inhalt ändert sich oft im Laufe der Zeit und zwischen den Nutzern. Der Inhalt deiner Homepage kann sich mehrmals am Tag ändern und einige Elemente können sogar für jeden Nutzer anders aussehen. Deshalb ist Cloudflare speichert nicht standardmäßig eine Version der HTML-Seiten, die allen Nutzern zur Verfügung gestellt wird. Stattdessen werden die HTML-Dateien mit der Standard-Caching-Stufe von Cloudflare jedes Mal vom Ursprungsserver (deinem Webserver) geholt, wenn ein Nutzer die Seite anfordert. Die statischen Dateien (CSS, JS, Bilder usw.), auf die im HTML verwiesen wird, werden dagegen direkt von Cloudflare's Netzwerk aus schnellen und zuverlässigen Servern bereitgestellt.
Das HTML-Caching in Cloudflare ist eine zusätzliche Funktion, die unter bestimmten Umständen für bestimmte Seiten aktiviert werden kann und mit Vorsicht zu genießen ist.
Herausforderungen: Komplikationen beim HTML-Caching auf E-Commerce-Seiten
Die meisten E-Commerce-Websites haben dynamische Elemente in ihren HTML-Seiten, was bedeutet, dass der Inhalt ihrer Seiten nicht für alle Benutzer/innen gleich aussieht. Außerdem kann sich der Inhalt von E-Commerce-Websites im Laufe der Zeit häufig ändern, zum Beispiel wenn Produkte vergriffen sind oder sich Preise und Angebote ändern. Im Fall von Reifen24 standen wir vor drei großen Herausforderungen, die uns daran hinderten, das HTML-Caching von Cloudflare einfach für alle Seiten zu aktivieren:
Erste Herausforderung: Dynamische Einkaufswagenvorschau
Auf reifen24.de, wie auch auf vielen anderen E-Commerce-Seiten und Online-Shops, ändert sich die Warenkorb-Vorschau jedes Mal, wenn ein Produkt in den Warenkorb gelegt oder aus dem Warenkorb entfernt wird. Die Vorschau ist auf allen Seiten enthalten, daher haben alle Seiten dieses dynamische Inhaltselement (hier mit einem roten Kasten markiert):
Wenn das HTML-Caching aktiviert ist, speichert Cloudflare immer eine Version einer Seite in seinem Cache, die an einen echten Nutzer ausgeliefert wurde. Wenn wir das HTML-Caching einfach auf allen Seiten für alle Nutzer aktivieren würden, würde Cloudflare die Versionen der Seiten, die einen Wert in der Warenkorbvorschau enthalten, im Cache speichern. Das würde dazu führen, dass viele Nutzer eine Warenkorbvorschau sehen, die nicht dem Inhalt ihres eigenen Warenkorbs entspricht.
Wenn du zum Beispiel der erste Nutzer warst, der die Winterreifen Kategorieseite auf Reifen24 nachdem das HTML-Caching aktiviert war und du 4 Produkte im Wert von 468,72 EUR in deinem Warenkorb hattest, wie im Screenshot oben, dann würde Cloudflare diese Version der Seite einschließlich deiner Warenkorbvorschau zwischenspeichern und allen nachfolgenden Nutzern, die dieselbe Seite aufrufen, zur Verfügung stellen. Das muss auf jeden Fall vermieden werden.
Zweite Herausforderung: Dynamische Inhalte für eingeloggte Nutzer
Ein ähnliches Problem wie das oben beschriebene tritt auf, wenn sich ein Nutzer bei Reifen24 anmeldet. Der Name des Nutzers wird oben auf der Seite angezeigt (hier mit einem roten Kasten markiert):
Wenn ich, während ich eingeloggt bin, der erste Nutzer bin, der eine bestimmte Seite anfordert, nachdem das HTML-Caching aktiviert wurde, dann würde Cloudflare diese Version der Seite einschließlich meines Namens zwischenspeichern und sie allen Nutzern zeigen, die die Seite von diesem Moment an anfordern. Das ist etwas, was wir nicht wollen, dass die Nutzer auf unserer Website sehen.
Dritte Herausforderung: Die Preise auf reifen24.de werden zweimal pro Stunde aktualisiert
Die Preise für Reifen und andere Produkte auf Reifen24 ändern sich häufig, und die angezeigten Preise werden alle 30 Minuten aktualisiert. Nicht alle Preise ändern sich jedes Mal, wenn die Daten aktualisiert werden, aber es ist unmöglich vorherzusagen, welche Preise sich ändern und wie viele Preise sich bei jeder Aktualisierung ändern.
Das HTML-Caching würde dazu führen, dass eine Version jeder Produkt- und Kategorieseite zwischengespeichert wird und die Preise anzeigt, die zum Zeitpunkt des Cachens angezeigt werden. Die dritte große Herausforderung bei der Implementierung des HTML-Cachings von Cloudflare auf Reifen24 war es, sicherzustellen, dass immer die richtigen Preise angezeigt werden.
Lösungen: Cloudflare's “Bypass Cache on Cookie” und “Edge Cache TTL” Funktionen
Es gibt mehrere Möglichkeiten, die oben beschriebenen Probleme anzugehen, aber in diesem Fall brauchten wir eine einfache Lösung, die nicht zu viele Entwicklungsressourcen erfordert.
Hamlet Batista, in diesen tollen Artikel über HTML-Caching für E-Commerce-Websites, schlägt vor, dass eine Lösung für dynamische Inhaltselemente wie den Namen eines eingeloggten Nutzers darin besteht, diese Informationen per JavaScript zur Seite hinzuzufügen, anstatt sie in den ursprünglichen HTML-Code aufzunehmen. Auf diese Weise könnten HTML-Dateien ohne dynamische Elemente, die für alle Nutzer funktionieren, zwischengespeichert und dynamische Elemente für jeden Nutzer einzeln auf der Client-Seite hinzugefügt werden. Unser Problem mit diesem Ansatz ist, dass er, obwohl er nach einer tollen Lösung klingt, eine erhebliche Änderung der Programmierung bestimmter Elemente des Shops erfordern würde.
Eine Alternative, die Hamlet vorschlägt, ist, das HTML-Caching nur für nicht eingeloggte Nutzer zu aktivieren. Wenn wir diese Idee auf unseren Fall anwenden, mit dynamischen Inhaltselementen für eingeloggte Nutzer und für Nutzer, die Produkte in ihren Warenkorb gelegt haben, würde das bedeuten, dass wir einen Weg finden müssten, das HTML-Caching nur für Nutzer zu aktivieren, die nicht eingeloggt sind und die nichts in ihren Warenkorb gelegt haben.
Cloudflare bietet eine Lösung zum Zwischenspeichern von HTML-Seiten nur für bestimmte Benutzer, mit dem Namen “Cache bei Cookie umgehen” (verfügbar für Geschäfts- und Unternehmensplan Benutzer). Das einzige zusätzliche Element, das du auf deiner Website brauchst, um diese Funktion zu nutzen, ist ein Cookie, das immer dann gesetzt wird, wenn du einen Nutzer vom HTML-Caching ausschließen willst. In unserem Fall brauchten wir ein Cookie, das immer dann gesetzt wird, wenn ein Nutzer ein Produkt in den Warenkorb legt oder sich anmeldet, und das gelöscht wird, wenn der Warenkorb leer ist oder der Nutzer sich abmeldet.
Je nachdem, welches CMS oder Shopsystem du verwendest, gibt es verschiedene Möglichkeiten, Cookies zu setzen - vielleicht hast du sogar Glück und die Cookies, die du brauchst, sind bereits vorhanden. Wenn du nicht weißt, wie du die Cookies einrichtest, die du brauchst, um das HTML-Caching auf deiner Website zu implementieren, wird ein späterer Teil dieses Artikels (wo wir erklären, wie wir Cookies mit dem Google Tag Manager für diese spezielle Implementierung einrichten) könnte helfen.
Bevor wir uns ansehen, wie wir die benötigten Cookies mit GTM einrichten, werfen wir einen kurzen Blick auf die letzte Herausforderung (häufig wechselnde Preise) und wie unsere HTML-Caching-Implementierung bei Cloudflare aussieht.
Cloudflare's Edge Cache TTL ist eine Funktion, mit der wir einen Zeitrahmen festlegen können, nach dem der Cache geleert wird und Cloudflare eine neue Version der Seite vom Ursprungsserver abruft, wenn die Seite das nächste Mal von einem Nutzer angefordert wird. Wir haben uns entschieden, diese Funktion zu nutzen, um den Cache von Cloudflare genauso oft ablaufen zu lassen, wie die Preise auf der Website aktualisiert werden - alle 30 Minuten.
Die Verwendung der Funktionen “Bypass Cache on Cookie” (um eingeloggte Benutzer und Benutzer, die Produkte in ihrem Einkaufswagen haben, vom HTML-Caching auszuschließen) und “Edge Cache TTL” (um den Cache nach einem bestimmten Zeitrahmen ablaufen zu lassen) führt zu folgender Implementierung in Cloudflare:
Die Umsetzung: Seitenregeln für HTML-Caching in Cloudflare
In der “Seitenregeln” in Cloudflare haben wir die folgenden Regeln hinzugefügt, um das HTML-Caching für Benutzer zu aktivieren, die nicht eingeloggt sind und keine Produkte in ihrem Warenkorb haben:
Die erste Regel setzt die Caching-Stufe für alle URLs, die auf “.php” enden, auf “Standard”. Erinnere dich daran, dass die Caching-Stufe “Standard” bei Cloudflare bedeutet, dass nur statische Dateien wie Bilder oder Stylesheets zwischengespeichert werden und der HTML-Code bei jedem Seitenaufruf vom Ursprungsserver abgerufen wird. Wir haben diese Einstellung für alle URLs gewählt, die auf “.php” enden, denn auf dieser Website sind URLs, die auf “.php” enden, komplett dynamische Seiten, wie der Warenkorb oder der Bestellvorgang. Wir wollen auf keinen Fall HTML-Caching auf Seiten, die hauptsächlich aus Inhalten bestehen, die sich für jeden Nutzer ändern.
Die zweite Regel setzt dann die Cache-Ebene auf “Cache Everything” für alle Seiten im Verzeichnis “/info/”. Die Cache-Ebene “Cache Everything” bedeutet, dass das HTML-Caching für die Seiten, für die die Regel gilt, aktiviert ist.
Wir setzen den Wert für “Edge Cache TTL” für alle Seiten im Verzeichnis “/info/” auf “einen Tag”, da sich dieser Inhalt zwar täglich ändern kann, die Seiten aber keine Preise enthalten, so dass es nicht nötig ist, den Cache alle 30 Minuten zu leeren. Nachdem eine HTML-Seite aus diesem Verzeichnis auf dem Server von Cloudflare zwischengespeichert wurde, wird allen Nutzern diese Version der Seite nun 24 Stunden lang zur Verfügung gestellt. Nach Ablauf der 24 Stunden wird die gecachte Version der Seite gelöscht. Sobald sie gelöscht ist und die Seite erneut angefordert wird, holt Cloudflare eine neue Version der Seite vom Ursprungsserver und speichert diese Version für die nächsten 24 Stunden.
Schließlich ist der Wert “bypassCache” der Einstellung “Bypass Cache on Cookie” der Name des Cookies, den unser Shop setzt, wenn sich ein Nutzer anmeldet oder ein Produkt in den Warenkorb legt. Immer wenn dieses Cookie vorhanden ist, wird die Cache-Stufe auf die universelle Einstellung für die Website zurückgesetzt (“Standard” in diesem Fall - nicht über eine Seitenregel definiert, sondern im Abschnitt “Caching” der Cloudflare-Schnittstelle).
Bitte beachte, dass Cloudflare-Seitenregeln von oben nach unten angewendet werden und dass spätere Regeln nicht auf Seiten angewendet werden, auf die bereits eine frühere Regel angewendet wurde. Das bedeutet, dass die zweite Regel nicht für die Seiten gilt, für die die erste Regel gilt, und die dritte Regel nicht für die Seiten, für die die erste und zweite Regel gilt.
Die dritte Regel gilt in unserer Implementierung für alle verbleibenden URLs (alles außer den Seiten, die von den ersten beiden Regeln abgedeckt werden) und setzt die Caching-Stufe auf HTML-Caching, wenn das Cookie “bypassCache” nicht vorhanden ist. Der einzige Unterschied zur zweiten Regel besteht darin, dass die Edge Cache TTL hier 30 Minuten statt einem Tag beträgt.
Du erinnerst dich wahrscheinlich daran, dass eine der Herausforderungen, die wir mit dem HTML-Caching von Cloudflare auf Reifen24 hatten, darin bestand, dass die Preise auf der Website zweimal pro Stunde aktualisiert werden. Die Edge Cache TTL auf 30 Minuten zu setzen, war die einfachste Lösung, die wir hier finden konnten, auch wenn sie nicht perfekt ist:
Leider bietet Cloudflare nicht die Möglichkeit, den Cache regelmäßig zu einer festen Zeit zu leeren. Wenn du die Edge Cache TTL auf 30 Minuten einstellst, speichert Cloudflare jede Seite in dem Moment, in dem sie zum ersten Mal von einem Nutzer angefordert wird, und stellt diese zwischengespeicherte Version dann für die nächsten 30 Minuten allen Nutzern zur Verfügung. Nach Ablauf der 30 Minuten löscht Cloudflare die zwischengespeicherte Version und wartet, bis die Seite erneut von einem Nutzer angefordert wird, bevor es eine neue Version für weitere 30 Minuten zwischenspeichert.
Das bedeutet, dass die Nutzer/innen im schlimmsten Fall bei unserer aktuellen Implementierung noch bis zu 30 Minuten lang die falschen Preise sehen können, wenn das Caching einer bestimmten Seite kurz vor der Aktualisierung eines Preises auf der Seite erfolgt - ein Risiko, das wir bereit waren einzugehen, um die Auswirkungen des HTML-Cachings zu testen. Bisher gab es keine Beschwerden von Nutzern, dass sich die angezeigten Preise ändern, nachdem sie ein Produkt in den Warenkorb gelegt haben. Dennoch arbeiten wir an einer ausgefeilteren Lösung für dieses Problem, die die Cloudflare-API einbezieht und auf die wir später noch eingehen werden (wenn wir über weitere Optimierungspotenziale).
Die drei Seitenregeln, die du oben siehst, sind die exakte Implementierung in Cloudflare, die zu einer Erhöhung der Seitengeschwindigkeit von 28% für Reifen24 geführt hat. Ich hoffe, dass du mit Hilfe dieser Fallstudie in der Lage sein wirst, dieses Setup an jede Website anzupassen, an der du arbeitest. Das letzte Puzzleteil, das dir jetzt vielleicht noch fehlt, ist die Frage, wie du die Cookies für Nutzerinnen und Nutzer setzt, die du vom HTML-Caching ausschließen möchtest (z. B. eingeloggte Nutzerinnen und Nutzer oder Nutzerinnen und Nutzer, die Produkte in ihren Warenkorb gelegt haben). Dafür gibt es keine Einheitslösung, aber im nächsten Teil dieses Artikels zeigen wir dir, wie wir die Cookies in diesem speziellen Fall mit dem Google Tag Manager eingerichtet haben.
Optional: Setzen von Cookies mit Google Tag Manager
Wenn du nach Möglichkeiten suchst, Änderungen an einer Website vorzunehmen, ohne das Entwicklerteam zu belästigen, ist der Google Tag Manager oft ein hilfreiches Tool. Trotzdem solltest du bedenken, dass es meist eine bessere Lösung als den Google Tag Manager gibt. Im Fall von Reifen24 brauchten wir eine Lösung, die nicht zu viele Entwicklerressourcen beansprucht, also haben wir uns entschieden, das “bypassCache”-Cookie mit dem GTM zu setzen.
Wann immer ich ein Cookie mit dem Google Tag Manager setzen oder löschen muss, beziehe ich mich auf dieser brillante Leitfaden von Julius Fedorovicius. Indem ich die Skripte kopiert habe, die Julius in seinem Artikel zur Verfügung stellt, und sie ein klein wenig an meine Bedürfnisse angepasst habe, kam ich auf die folgende Tag-Konfiguration im Google Tag Manager, um das “bypassCache”-Cookie zu setzen, wenn eine Seite geladen wird, während der Nutzer eingeloggt ist oder Produkte im Warenkorb hat:
Um zu erkennen, ob ein Nutzer eingeloggt ist oder Produkte im Warenkorb hat, habe ich im Google Tag Manager zwei “DOM Element”-Variablen erstellt. Mit diesem Variablentyp können wir Werte aus HTML-Elementen extrahieren, indem wir CSS-Selektoren oder HTML-IDs verwenden. Julius hat auch eine Tolle Anleitung zu “DOM Element” Variablen in GTM, falls du mehr Informationen zu diesem Thema brauchst.
Mithilfe von “DOM Element”-Variablen können wir den Text des Anmeldelinks und den Wert der Warenkorbvorschau aus unserer Website extrahieren. Mithilfe dieser Variablen können wir dann Trigger erstellen, die auslösen, wenn eine Seite mit oder ohne Produkte im Warenkorb geladen wird oder wenn der Nutzer an- oder abgemeldet ist:
Die Auslöser “Produkt im Warenkorb” und “Eingeloggter Benutzer” werden für das Tag verwendet, das du oben gesehen hast und das den “bypassCache”-Cookie setzt, und die Auslöser “Kein Produkt im Warenkorb” und “Ausgeloggter Benutzer” werden für das folgende Tag verwendet, das den Cookie für ausgeloggte Benutzer mit leerem Warenkorb löscht, falls er vorhanden ist:
Wenn du noch nicht viel Erfahrung mit dem Google Tag Manager hast, wird dir das vielleicht ziemlich fortgeschritten vorkommen. Es macht nicht viel Sinn, den GTM-Teil genauer zu erklären, da die Lösung auf jeder Website anders aussehen würde, je nachdem, wie der Quellcode genau aussieht. Wenn du bei diesem Teil oder bei allem anderen, was in diesem Artikel erwähnt wurde, Unterstützung brauchst, hinterlasse einfach einen Kommentar und ich werde dir gerne helfen.
Einschränkungen, weiteres Optimierungspotenzial & nächste Schritte
Fassen wir zusammen, was wir mit der aktuellen Umsetzung erreicht haben und wo es noch Optimierungspotenzial gibt.
Das HTML-Caching auf Reifen24 ist derzeit immer dann aktiv, wenn ein Nutzer nicht eingeloggt ist und keine Produkte im Warenkorb hat. Wir haben keine sehr zuverlässigen Tracking-Daten darüber, wie viel Prozent der Seitenaufrufe unter diesen Bedingungen stattfinden (Schande über uns), aber aus der Analyse der Enhanced E-Commerce Tracking-Daten, die wir in Google Analytics haben, können wir schließen, dass in etwa 95% aller Sitzungen keine Produkte in den Warenkorb gelegt werden. Der Prozentsatz der nicht eingeloggten Nutzer ist sogar noch höher.
Das bedeutet, dass die meisten Besucherinnen und Besucher bereits von der HTML-Caching-Implementierung profitieren, aber wir möchten natürlich auch, dass die Nutzerinnen und Nutzer superschnelle Seitenladezeiten erleben, nachdem sie Produkte in ihren Warenkorb gelegt haben und eingeloggt sind. Eine Lösung wie die besprochene weiter oben in diesem Artikel, bei dem dynamische Elemente wie die Warenkorbvorschau oder personalisierte Bereiche auf ansonsten statischen Seiten über JavaScript auf der Client-Seite hinzugefügt werden, steht auf unserer Liste der geplanten Optimierungen.
Eine weitere große Einschränkung unserer aktuellen Implementierung ist, dass wir den Cloudflare-Cache für die meisten Seiten nach 30 Minuten ablaufen lassen müssen, da sich die Preise häufig ändern. Für Seiten, die nicht viel besucht werden, gibt es nicht oft eine gecachte Version (immer dann, wenn eine Seite angefordert wird, die in den letzten 30 Minuten noch nicht angefordert wurde). Und selbst Seiten mit vielen Besuchen müssen derzeit bis zu 24 Mal am Tag vom Ursprungsserver geholt werden (zweimal pro Stunde, laut unseren aktuellen Einstellungen für den Cache-Ablauf).
Wir arbeiten derzeit an einer automatischen Lösung, bei der wir nach jeder Aktualisierung prüfen, welche Preise sich geändert haben, und dann die Cloudflare API, um nur genau diese URLs aus dem Cache zu entfernen die Preise enthalten, die sich geändert haben. Auf diese Weise konnten wir die Edge Cache TTL-Einstellung entfernen oder auf einen deutlich längeren Zeitraum (z. B. eine Woche) ändern. Wir hoffen, dass diese Optimierung dazu beiträgt, dass Seiten, für die nicht oft eine gecachte Version verfügbar ist, noch schneller geladen werden. Sie dürfte sich auch deutlich auf die Ladezeiten für Crawler auswirken, da diese noch häufiger als die Nutzer/innen auf Seiten zugreifen, die nicht sehr regelmäßig besucht werden.
HTML-Caching ist auf Seiten, die hauptsächlich dynamische Inhalte enthalten, wie z.B. der Warenkorb oder der Checkout-Prozess, nicht wirklich sinnvoll. Für diese Seiten und auch für dynamische Inhaltselemente auf anderen Seiten, die nicht gecacht werden können, bietet Cloudflare eine zusätzliche Funktion namens Railgun. Kurz gesagt und ohne zu sehr ins technische Detail zu gehen, ist Railgun so etwas wie HTML-Caching für dynamische Inhalte. Es kann zusammen mit HTML-Caching, als Ergänzung zu HTML-Caching oder völlig unabhängig davon eingesetzt werden. Wenn du das Potenzial von HTML-Caching auf deiner Website ausgeschöpft hast oder zu dem Schluss gekommen bist, dass du es wegen zu vieler technischer Einschränkungen gar nicht einsetzen kannst, sollte die Implementierung von Railgun der nächste logische Schritt sein.
Wie du siehst, ist die 28% Verbesserung der durchschnittlichen Seitenladezeiten, die wir mit dieser Basisimplementierung erreicht haben (nur für bestimmte Nutzer und nur Caching HTML für 30 Minuten auf den meisten Seiten), erst der Anfang. Mit den nächsten Schritten, die wir geplant haben, sollten wir in der Lage sein, noch bessere Ergebnisse zu erzielen.
TL;DR
- Wir haben eine 28% Anstieg der durchschnittlichen Seitenladezeiten durch die Umsetzung Cloudflare's HTML-Caching auf reifen24.de, einem deutschen Onlineshop für Reifen.
- Wenn das HTML-Caching aktiviert ist, werden ganze HTML-Dokumente (statt nur statische Dateien) auf den Servern von Cloudflare gespeichert und den Website-Besuchern direkt zur Verfügung gestellt (statt bei jeder Anfrage vom Ursprungsserver geholt zu werden).
- HTML-Caching auf E-Commerce-Websites kann kompliziert, denn Online-Shops haben oft dynamische Inhaltselemente die für jeden Nutzer anders aussehen (z. B. Warenkorbvorschau) oder Elemente, die häufig wechseln im Laufe der Zeit (z. B. Preise).
- Cloudflare kann angewiesen werden, das HTML-Caching zu deaktivieren, wenn eine bestimmte Cookie vorhanden ist (z.B. ein Cookie, das gesetzt wird, wenn ein Produkt in den Warenkorb gelegt wird) und der Cache nach einer bestimmten Zeit automatisch geleert werden kann.
- Die Cookies, die für diese Einrichtung benötigt werden, können mit Google Tag Manager, wenn es keine bessere Lösung gibt.
- Obwohl diese grundlegende Implementierung des HTML-Cachings von Cloudflare bereits zu einer Verbesserung der durchschnittlichen Seitengeschwindigkeit um 28% führte, gibt es noch weiteres Optimierungspotenzial durch das Einfügen dynamischer Inhaltselemente auf der Client-seitig (anstelle des rohen HTML), indem sie die Cloudflare API um den Cache bei Bedarf zu leeren (anstatt ihn automatisch nach kurzen Zeiträumen zu leeren), und durch die Aktivierung von zusätzliche Cloudflare-Funktionen die dem HTML-Caching ähnlich sind, aber für dynamische Inhalte funktionieren.
Ich hoffe, dass dir die Lektüre dieser Fallstudie gefallen hat und dass sie dir bei der Implementierung von HTML-Caching auf der/den Website(s), an denen du arbeitest, hilft. Wenn etwas unklar bleibt oder du irgendwelche Fragen oder Kommentare hast, zögere nicht, einen Kommentar zu hinterlassen.
Und für den Fall, dass du noch etwas brauchst zusätzliche Motivation: Die Optimierung der Seitengeschwindigkeit führte in diesem Fall auch zu einer deutlichen Verbesserung der Konversionsraten und zu einem sechsstelligen Umsatzanstieg innerhalb eines Monats - unsere Arbeit hat sich also ausgezahlt.
English 
German