{"id":3332,"date":"2019-05-31T11:33:09","date_gmt":"2019-05-31T11:33:09","guid":{"rendered":"https:\/\/www.searchviu.com\/?p=3332"},"modified":"2023-03-16T15:43:06","modified_gmt":"2023-03-16T15:43:06","slug":"html-caching-cloudflare-ecommerce","status":"publish","type":"post","link":"https:\/\/www.searchviu.com\/de\/html-caching-cloudflare-e-commerce\/","title":{"rendered":"Fallstudie: 28% Verbesserung der Seitengeschwindigkeit mit Cloudflare HTML-Caching"},"content":{"rendered":"

Die Seitengeschwindigkeit ist ein unglaublich wichtiger Faktor f\u00fcr UX, Konversionsraten und SEO. In dieser Fallstudie wird ausf\u00fchrlich 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.<\/strong><\/p>\n

Bist du in Eile? Springe direkt zum TL;DR Zusammenfassung<\/a>!<\/em><\/p>\n

Das Ergebnis: 28% bessere Seitenladezeiten mit dem HTML-Caching von Cloudflare<\/h2>\n

Beginnen wir mit den Ergebnissen dieser Fallstudie, bevor wir uns mit den Details der Umsetzung besch\u00e4ftigen. Eine M\u00f6glichkeit, die Auswirkungen von Optimierungen der Seitengeschwindigkeit zu messen, ist ein Blick auf den Bericht \u201cSite Speed Page Timings\u201d in Google Analytics:<\/p>\n

\"Bericht<\/a><\/p>\n

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\u00e4rz 2019). reifen24.de<\/a>, einem deutschen Onlineshop f\u00fcr Reifen. Die durchschnittliche Die Reaktionszeit des Servers sank von etwa 1,5 Sekunden auf unter 1 Sekunde.<\/strong>, und auch die durchschnittliche Seitenladezeit hat von der Optimierung profitiert.<\/p>\n

Wie du auf dem folgenden Screenshot von Google Analytics sehen kannst, der die durchschnittliche Seitenladezeit seit dem 21. M\u00e4rz (dem Tag nach der Einf\u00fchrung) mit dem vorherigen Zeitraum vergleicht, Die Seitengeschwindigkeit wurde um 27.56% verbessert<\/strong> (von 4,49 Sekunden durchschnittlicher Seitenladezeit auf 3,25 Sekunden):<\/p>\n

\"Verbesserung<\/a><\/p>\n

In dem Zeitraum, den wir hier betrachten, wurden keine anderen \u00c4nderungen vorgenommen, die einen signifikanten Einfluss (positiv oder negativ) auf die Seitenlade- oder Server-Antwortzeiten gehabt haben k\u00f6nnten.<\/p>\n

Lies weiter, um alles zu erfahren, was du \u00fcber HTML-Caching f\u00fcr 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\u00fcr weitere Optimierungen lassen.<\/em><\/p>\n

Der Kontext: HTML-Caching vs. Standard-Caching bei Cloudflare<\/h2>\n

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\u00e4chst einige Informationen dar\u00fcber, was Cloudflare macht und wie die verschiedenen Caching-Stufen funktionieren.<\/p>\n

Vereinfacht gesagt, bietet Cloudflare ein Netzwerk von sehr leistungsstarken, schnellen und zuverl\u00e4ssigen 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\u00e4gt dazu bei, die Ladezeiten deiner Website f\u00fcr 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).<\/p>\n

Das Standard-Caching von Cloudflare (d.h. das Speichern von Teilen deiner Website auf ihrem Servernetzwerk) gilt f\u00fcr statische Dateien<\/a> 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\u00fcr 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\u00fcgung stellen, ohne dass sie sie immer wieder von deinem eigenen Webserver abrufen m\u00fcssen.<\/p>\n

HTML-Seiten (normale Webseiten) sind anders, denn ihr Inhalt \u00e4ndert sich oft im Laufe der Zeit und zwischen den Nutzern. Der Inhalt deiner Homepage kann sich mehrmals am Tag \u00e4ndern und einige Elemente k\u00f6nnen sogar f\u00fcr jeden Nutzer anders aussehen. Deshalb ist Cloudflare speichert nicht standardm\u00e4\u00dfig eine Version der HTML-Seiten, die allen Nutzern zur Verf\u00fcgung gestellt wird<\/em>. 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\u00e4ssigen Servern bereitgestellt.<\/p>\n

Das HTML-Caching in Cloudflare ist eine zus\u00e4tzliche Funktion, die unter bestimmten Umst\u00e4nden f\u00fcr bestimmte Seiten aktiviert werden kann und mit Vorsicht zu genie\u00dfen ist.<\/p>\n

Herausforderungen: Komplikationen beim HTML-Caching auf E-Commerce-Seiten<\/h2>\n

Die meisten E-Commerce-Websites haben dynamische Elemente in ihren HTML-Seiten, was bedeutet, dass der Inhalt ihrer Seiten nicht f\u00fcr alle Benutzer\/innen gleich aussieht. Au\u00dferdem kann sich der Inhalt von E-Commerce-Websites im Laufe der Zeit h\u00e4ufig \u00e4ndern, zum Beispiel wenn Produkte vergriffen sind oder sich Preise und Angebote \u00e4ndern. Im Fall von Reifen24 standen wir vor drei gro\u00dfen Herausforderungen, die uns daran hinderten, das HTML-Caching von Cloudflare einfach f\u00fcr alle Seiten zu aktivieren:<\/p>\n

Erste Herausforderung: Dynamische Einkaufswagenvorschau<\/strong><\/p>\n

Auf reifen24.de, wie auch auf vielen anderen E-Commerce-Seiten und Online-Shops, \u00e4ndert 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):<\/p>\n

\"Dynamische<\/a><\/p>\n

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\u00fcr alle Nutzer aktivieren w\u00fcrden, w\u00fcrde Cloudflare die Versionen der Seiten, die einen Wert in der Warenkorbvorschau enthalten, im Cache speichern. Das w\u00fcrde dazu f\u00fchren, dass viele Nutzer eine Warenkorbvorschau sehen, die nicht dem Inhalt ihres eigenen Warenkorbs entspricht.<\/p>\n

Wenn du zum Beispiel der erste Nutzer warst, der die Winterreifen Kategorieseite auf Reifen24<\/a> 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\u00fcrde Cloudflare diese Version der Seite einschlie\u00dflich deiner Warenkorbvorschau zwischenspeichern und allen nachfolgenden Nutzern, die dieselbe Seite aufrufen, zur Verf\u00fcgung stellen. Das muss auf jeden Fall vermieden werden.<\/p>\n

Zweite Herausforderung: Dynamische Inhalte f\u00fcr eingeloggte Nutzer<\/strong><\/p>\n

Ein \u00e4hnliches 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):<\/p>\n

\"Benutzername<\/a><\/p>\n

Wenn ich, w\u00e4hrend ich eingeloggt bin, der erste Nutzer bin, der eine bestimmte Seite anfordert, nachdem das HTML-Caching aktiviert wurde, dann w\u00fcrde Cloudflare diese Version der Seite einschlie\u00dflich 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.<\/p>\n

Dritte Herausforderung: Die Preise auf reifen24.de werden zweimal pro Stunde aktualisiert<\/strong><\/p>\n

Die Preise f\u00fcr Reifen und andere Produkte auf Reifen24 \u00e4ndern sich h\u00e4ufig, und die angezeigten Preise werden alle 30 Minuten aktualisiert. Nicht alle Preise \u00e4ndern sich jedes Mal, wenn die Daten aktualisiert werden, aber es ist unm\u00f6glich vorherzusagen, welche Preise sich \u00e4ndern und wie viele Preise sich bei jeder Aktualisierung \u00e4ndern.<\/p>\n

Das HTML-Caching w\u00fcrde dazu f\u00fchren, dass eine Version jeder Produkt- und Kategorieseite zwischengespeichert wird und die Preise anzeigt, die zum Zeitpunkt des Cachens angezeigt werden. Die dritte gro\u00dfe Herausforderung bei der Implementierung des HTML-Cachings von Cloudflare auf Reifen24 war es, sicherzustellen, dass immer die richtigen Preise angezeigt werden.<\/p>\n

L\u00f6sungen: Cloudflare's \u201cBypass Cache on Cookie\u201d und \u201cEdge Cache TTL\u201d Funktionen<\/h2>\n

Es gibt mehrere M\u00f6glichkeiten, die oben beschriebenen Probleme anzugehen, aber in diesem Fall brauchten wir eine einfache L\u00f6sung, die nicht zu viele Entwicklungsressourcen erfordert.<\/p>\n

Hamlet Batista<\/a>, in diesen tollen Artikel \u00fcber HTML-Caching f\u00fcr E-Commerce-Websites<\/a>, schl\u00e4gt vor, dass eine L\u00f6sung f\u00fcr dynamische Inhaltselemente wie den Namen eines eingeloggten Nutzers darin besteht, diese Informationen per JavaScript zur Seite hinzuzuf\u00fcgen, anstatt sie in den urspr\u00fcnglichen HTML-Code aufzunehmen. Auf diese Weise k\u00f6nnten HTML-Dateien ohne dynamische Elemente, die f\u00fcr alle Nutzer funktionieren, zwischengespeichert und dynamische Elemente f\u00fcr jeden Nutzer einzeln auf der Client-Seite hinzugef\u00fcgt werden. Unser Problem mit diesem Ansatz ist, dass er, obwohl er nach einer tollen L\u00f6sung klingt, eine erhebliche \u00c4nderung der Programmierung bestimmter Elemente des Shops erfordern w\u00fcrde.<\/p>\n

Eine Alternative, die Hamlet vorschl\u00e4gt, ist, das HTML-Caching nur f\u00fcr nicht eingeloggte Nutzer zu aktivieren. Wenn wir diese Idee auf unseren Fall anwenden, mit dynamischen Inhaltselementen f\u00fcr eingeloggte Nutzer und f\u00fcr Nutzer, die Produkte in ihren Warenkorb gelegt haben, w\u00fcrde das bedeuten, dass wir einen Weg finden m\u00fcssten, das HTML-Caching nur f\u00fcr Nutzer zu aktivieren, die nicht eingeloggt sind und die nichts in ihren Warenkorb gelegt haben.<\/p>\n

Cloudflare bietet eine L\u00f6sung zum Zwischenspeichern von HTML-Seiten nur f\u00fcr bestimmte Benutzer<\/a>, mit dem Namen \u201cCache bei Cookie umgehen\u201d (verf\u00fcgbar f\u00fcr Gesch\u00e4fts- und Unternehmensplan<\/a> Benutzer). Das einzige zus\u00e4tzliche 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\u00dfen 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\u00f6scht wird, wenn der Warenkorb leer ist oder der Nutzer sich abmeldet.<\/p>\n

Je nachdem, welches CMS oder Shopsystem du verwendest, gibt es verschiedene M\u00f6glichkeiten, Cookies zu setzen - vielleicht hast du sogar Gl\u00fcck und die Cookies, die du brauchst, sind bereits vorhanden. Wenn du nicht wei\u00dft, wie du die Cookies einrichtest, die du brauchst, um das HTML-Caching auf deiner Website zu implementieren, wird ein sp\u00e4terer Teil dieses Artikels<\/a> (wo wir erkl\u00e4ren, wie wir Cookies mit dem Google Tag Manager f\u00fcr diese spezielle Implementierung einrichten) k\u00f6nnte helfen.<\/p>\n

Bevor wir uns ansehen, wie wir die ben\u00f6tigten Cookies mit GTM einrichten, werfen wir einen kurzen Blick auf die letzte Herausforderung (h\u00e4ufig wechselnde Preise) und wie unsere HTML-Caching-Implementierung bei Cloudflare aussieht.<\/em><\/p>\n

Cloudflare's Edge Cache TTL<\/a> ist eine Funktion, mit der wir einen Zeitrahmen festlegen k\u00f6nnen, nach dem der Cache geleert wird und Cloudflare eine neue Version der Seite vom Ursprungsserver abruft, wenn die Seite das n\u00e4chste 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.<\/p>\n

Die Verwendung der Funktionen \u201cBypass Cache on Cookie\u201d (um eingeloggte Benutzer und Benutzer, die Produkte in ihrem Einkaufswagen haben, vom HTML-Caching auszuschlie\u00dfen) und \u201cEdge Cache TTL\u201d (um den Cache nach einem bestimmten Zeitrahmen ablaufen zu lassen) f\u00fchrt zu folgender Implementierung in Cloudflare:<\/p>\n

Die Umsetzung: Seitenregeln f\u00fcr HTML-Caching in Cloudflare<\/h2>\n

In der \u201cSeitenregeln\u201d<\/a> in Cloudflare haben wir die folgenden Regeln hinzugef\u00fcgt, um das HTML-Caching f\u00fcr Benutzer zu aktivieren, die nicht eingeloggt sind und keine Produkte in ihrem Warenkorb haben:<\/p>\n

\"Seitenregel-Einstellungen<\/a><\/p>\n

Die erste Regel<\/strong> setzt die Caching-Stufe f\u00fcr alle URLs, die auf \u201c.php\u201d enden, auf \u201cStandard\u201d. Erinnere dich daran, dass die Caching-Stufe \u201cStandard\u201d 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\u00fcr alle URLs gew\u00e4hlt, die auf \u201c.php\u201d enden, denn auf dieser Website sind URLs, die auf \u201c.php\u201d enden, komplett dynamische Seiten, wie der Warenkorb oder der Bestellvorgang. Wir wollen auf keinen Fall HTML-Caching auf Seiten, die haupts\u00e4chlich aus Inhalten bestehen, die sich f\u00fcr jeden Nutzer \u00e4ndern.<\/p>\n

Die zweite Regel<\/strong> setzt dann die Cache-Ebene auf \u201cCache Everything\u201d f\u00fcr alle Seiten im Verzeichnis \u201c\/info\/\u201d. Die Cache-Ebene \u201cCache Everything\u201d bedeutet, dass das HTML-Caching f\u00fcr die Seiten, f\u00fcr die die Regel gilt, aktiviert ist.<\/p>\n

Wir setzen den Wert f\u00fcr \u201cEdge Cache TTL\u201d f\u00fcr alle Seiten im Verzeichnis \u201c\/info\/\u201d auf \u201ceinen Tag\u201d, da sich dieser Inhalt zwar t\u00e4glich \u00e4ndern kann, die Seiten aber keine Preise enthalten, so dass es nicht n\u00f6tig 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\u00fcgung gestellt. Nach Ablauf der 24 Stunden wird die gecachte Version der Seite gel\u00f6scht. Sobald sie gel\u00f6scht ist und die Seite erneut angefordert wird, holt Cloudflare eine neue Version der Seite vom Ursprungsserver und speichert diese Version f\u00fcr die n\u00e4chsten 24 Stunden.<\/p>\n

Schlie\u00dflich ist der Wert \u201cbypassCache\u201d der Einstellung \u201cBypass Cache on Cookie\u201d 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\u00fcr die Website zur\u00fcckgesetzt (\u201cStandard\u201d in diesem Fall - nicht \u00fcber eine Seitenregel definiert, sondern im Abschnitt \u201cCaching\u201d der Cloudflare-Schnittstelle).<\/p>\n

Bitte beachte, dass Cloudflare-Seitenregeln von oben nach unten angewendet werden und dass sp\u00e4tere Regeln nicht auf Seiten angewendet werden, auf die bereits eine fr\u00fchere Regel angewendet wurde. Das bedeutet, dass die zweite Regel nicht f\u00fcr die Seiten gilt, f\u00fcr die die erste Regel gilt, und die dritte Regel nicht f\u00fcr die Seiten, f\u00fcr die die erste und zweite Regel gilt.<\/em><\/p>\n

Die dritte Regel<\/strong> gilt in unserer Implementierung f\u00fcr alle verbleibenden URLs (alles au\u00dfer den Seiten, die von den ersten beiden Regeln abgedeckt werden) und setzt die Caching-Stufe auf HTML-Caching, wenn das Cookie \u201cbypassCache\u201d nicht vorhanden ist. Der einzige Unterschied zur zweiten Regel besteht darin, dass die Edge Cache TTL hier 30 Minuten statt einem Tag betr\u00e4gt.<\/p>\n

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\u00f6sung, die wir hier finden konnten, auch wenn sie nicht perfekt ist:<\/p>\n

Leider bietet Cloudflare nicht die M\u00f6glichkeit, den Cache regelm\u00e4\u00dfig 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\u00fcr die n\u00e4chsten 30 Minuten allen Nutzern zur Verf\u00fcgung. Nach Ablauf der 30 Minuten l\u00f6scht Cloudflare die zwischengespeicherte Version und wartet, bis die Seite erneut von einem Nutzer angefordert wird, bevor es eine neue Version f\u00fcr weitere 30 Minuten zwischenspeichert.<\/p>\n

Das bedeutet, dass die Nutzer\/innen im schlimmsten Fall bei unserer aktuellen Implementierung noch bis zu 30 Minuten lang die falschen Preise sehen k\u00f6nnen, 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 \u00e4ndern, nachdem sie ein Produkt in den Warenkorb gelegt haben. Dennoch arbeiten wir an einer ausgefeilteren L\u00f6sung f\u00fcr dieses Problem, die die Cloudflare-API einbezieht und auf die wir sp\u00e4ter noch eingehen werden (wenn wir \u00fcber weitere Optimierungspotenziale<\/a>).<\/p>\n

Die drei Seitenregeln, die du oben siehst, sind die exakte Implementierung in Cloudflare, die zu einer Erh\u00f6hung der Seitengeschwindigkeit von 28% f\u00fcr Reifen24 gef\u00fchrt 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\u00fcr Nutzerinnen und Nutzer setzt, die du vom HTML-Caching ausschlie\u00dfen m\u00f6chtest (z. B. eingeloggte Nutzerinnen und Nutzer oder Nutzerinnen und Nutzer, die Produkte in ihren Warenkorb gelegt haben). Daf\u00fcr gibt es keine Einheitsl\u00f6sung, aber im n\u00e4chsten Teil dieses Artikels zeigen wir dir, wie wir die Cookies in diesem speziellen Fall mit dem Google Tag Manager eingerichtet haben.<\/p>\n

Optional: Setzen von Cookies mit Google Tag Manager<\/h2>\n

Wenn du nach M\u00f6glichkeiten suchst, \u00c4nderungen an einer Website vorzunehmen, ohne das Entwicklerteam zu bel\u00e4stigen, ist der Google Tag Manager oft ein hilfreiches Tool. Trotzdem solltest du bedenken, dass es meist eine bessere L\u00f6sung als den Google Tag Manager gibt. Im Fall von Reifen24 brauchten wir eine L\u00f6sung, die nicht zu viele Entwicklerressourcen beansprucht, also haben wir uns entschieden, das \u201cbypassCache\u201d-Cookie mit dem GTM zu setzen.<\/p>\n

Wann immer ich ein Cookie mit dem Google Tag Manager setzen oder l\u00f6schen muss, beziehe ich mich auf dieser brillante Leitfaden<\/a> von Julius Fedorovicius<\/a>. Indem ich die Skripte kopiert habe, die Julius in seinem Artikel zur Verf\u00fcgung stellt, und sie ein klein wenig an meine Bed\u00fcrfnisse angepasst habe, kam ich auf die folgende Tag-Konfiguration im Google Tag Manager, um das \u201cbypassCache\u201d-Cookie zu setzen, wenn eine Seite geladen wird, w\u00e4hrend der Nutzer eingeloggt ist oder Produkte im Warenkorb hat:<\/p>\n

\"GTM-Tag-Konfiguration<\/a><\/p>\n

Um zu erkennen, ob ein Nutzer eingeloggt ist oder Produkte im Warenkorb hat, habe ich im Google Tag Manager zwei \u201cDOM Element\u201d-Variablen erstellt. Mit diesem Variablentyp k\u00f6nnen wir Werte aus HTML-Elementen extrahieren, indem wir CSS-Selektoren oder HTML-IDs verwenden. Julius hat auch eine Tolle Anleitung zu \u201cDOM Element\u201d Variablen in GTM<\/a>, falls du mehr Informationen zu diesem Thema brauchst.<\/p>\n

Mithilfe von \u201cDOM Element\u201d-Variablen k\u00f6nnen wir den Text des Anmeldelinks und den Wert der Warenkorbvorschau aus unserer Website extrahieren. Mithilfe dieser Variablen k\u00f6nnen wir dann Trigger erstellen, die ausl\u00f6sen, wenn eine Seite mit oder ohne Produkte im Warenkorb geladen wird oder wenn der Nutzer an- oder abgemeldet ist:<\/p>\n

\"Ausl\u00f6ser<\/a><\/p>\n

Die Ausl\u00f6ser \u201cProdukt im Warenkorb\u201d und \u201cEingeloggter Benutzer\u201d werden f\u00fcr das Tag verwendet, das du oben gesehen hast und das den \u201cbypassCache\u201d-Cookie setzt, und die Ausl\u00f6ser \u201cKein Produkt im Warenkorb\u201d und \u201cAusgeloggter Benutzer\u201d werden f\u00fcr das folgende Tag verwendet, das den Cookie f\u00fcr ausgeloggte Benutzer mit leerem Warenkorb l\u00f6scht, falls er vorhanden ist:<\/p>\n

\"GTM-Tag-Konfiguration<\/a><\/p>\n

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\u00e4ren, da die L\u00f6sung auf jeder Website anders aussehen w\u00fcrde, je nachdem, wie der Quellcode genau aussieht. Wenn du bei diesem Teil oder bei allem anderen, was in diesem Artikel erw\u00e4hnt wurde, Unterst\u00fctzung brauchst, hinterlasse einfach einen Kommentar und ich werde dir gerne helfen.<\/p>\n

Einschr\u00e4nkungen, weiteres Optimierungspotenzial & n\u00e4chste Schritte<\/h2>\n

Fassen wir zusammen, was wir mit der aktuellen Umsetzung erreicht haben und wo es noch Optimierungspotenzial gibt.<\/p>\n

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\u00e4ssigen Tracking-Daten dar\u00fcber, wie viel Prozent der Seitenaufrufe unter diesen Bedingungen stattfinden (Schande \u00fcber uns), aber aus der Analyse der Enhanced E-Commerce Tracking-Daten, die wir in Google Analytics haben, k\u00f6nnen wir schlie\u00dfen, dass in etwa 95% aller Sitzungen keine Produkte in den Warenkorb gelegt werden. Der Prozentsatz der nicht eingeloggten Nutzer ist sogar noch h\u00f6her.<\/p>\n

Das bedeutet, dass die meisten Besucherinnen und Besucher bereits von der HTML-Caching-Implementierung profitieren, aber wir m\u00f6chten nat\u00fcrlich auch, dass die Nutzerinnen und Nutzer superschnelle Seitenladezeiten erleben, nachdem sie Produkte in ihren Warenkorb gelegt haben und eingeloggt sind. Eine L\u00f6sung wie die besprochene weiter oben in diesem Artikel<\/a>, bei dem dynamische Elemente wie die Warenkorbvorschau oder personalisierte Bereiche auf ansonsten statischen Seiten \u00fcber JavaScript auf der Client-Seite hinzugef\u00fcgt werden, steht auf unserer Liste der geplanten Optimierungen.<\/p>\n

Eine weitere gro\u00dfe Einschr\u00e4nkung unserer aktuellen Implementierung ist, dass wir den Cloudflare-Cache f\u00fcr die meisten Seiten nach 30 Minuten ablaufen lassen m\u00fcssen, da sich die Preise h\u00e4ufig \u00e4ndern. F\u00fcr 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\u00fcssen derzeit bis zu 24 Mal am Tag vom Ursprungsserver geholt werden (zweimal pro Stunde, laut unseren aktuellen Einstellungen f\u00fcr den Cache-Ablauf).<\/p>\n

Wir arbeiten derzeit an einer automatischen L\u00f6sung, bei der wir nach jeder Aktualisierung pr\u00fcfen, welche Preise sich ge\u00e4ndert haben, und dann die Cloudflare API, um nur genau diese URLs aus dem Cache zu entfernen<\/a> die Preise enthalten, die sich ge\u00e4ndert haben. Auf diese Weise konnten wir die Edge Cache TTL-Einstellung entfernen oder auf einen deutlich l\u00e4ngeren Zeitraum (z. B. eine Woche) \u00e4ndern. Wir hoffen, dass diese Optimierung dazu beitr\u00e4gt, dass Seiten, f\u00fcr die nicht oft eine gecachte Version verf\u00fcgbar ist, noch schneller geladen werden. Sie d\u00fcrfte sich auch deutlich auf die Ladezeiten f\u00fcr Crawler auswirken, da diese noch h\u00e4ufiger als die Nutzer\/innen auf Seiten zugreifen, die nicht sehr regelm\u00e4\u00dfig besucht werden.<\/p>\n

HTML-Caching ist auf Seiten, die haupts\u00e4chlich dynamische Inhalte enthalten, wie z.B. der Warenkorb oder der Checkout-Prozess, nicht wirklich sinnvoll. F\u00fcr diese Seiten und auch f\u00fcr dynamische Inhaltselemente auf anderen Seiten, die nicht gecacht werden k\u00f6nnen, bietet Cloudflare eine zus\u00e4tzliche Funktion namens Railgun<\/a>. Kurz gesagt und ohne zu sehr ins technische Detail zu gehen, ist Railgun so etwas wie HTML-Caching f\u00fcr dynamische Inhalte. Es kann zusammen mit HTML-Caching, als Erg\u00e4nzung zu HTML-Caching oder v\u00f6llig unabh\u00e4ngig davon eingesetzt werden. Wenn du das Potenzial von HTML-Caching auf deiner Website ausgesch\u00f6pft hast oder zu dem Schluss gekommen bist, dass du es wegen zu vieler technischer Einschr\u00e4nkungen gar nicht einsetzen kannst, sollte die Implementierung von Railgun der n\u00e4chste logische Schritt sein.<\/p>\n

Wie du siehst, ist die 28% Verbesserung der durchschnittlichen Seitenladezeiten, die wir mit dieser Basisimplementierung erreicht haben (nur f\u00fcr bestimmte Nutzer und nur Caching HTML f\u00fcr 30 Minuten auf den meisten Seiten), erst der Anfang. Mit den n\u00e4chsten Schritten, die wir geplant haben, sollten wir in der Lage sein, noch bessere Ergebnisse zu erzielen.<\/p>\n

TL;DR<\/h2>\n