HTML-Caching mit Cloudflare machte einen Onlineshop 28 Prozent schneller.

Das Ergebnis

Am 20. März 2019 haben wir für einen deutschen Onlineshop das HTML-Caching in Cloudflare aktiviert. Der Bericht zu den Seitenladezeiten in Google Analytics zeigte den Effekt ab diesem Tag. Die durchschnittliche Antwortzeit des Servers fiel von rund 1,5 Sekunden auf unter eine Sekunde.

Verglichen wurde der Zeitraum ab dem 21. März, dem Tag nach der Umstellung, mit dem Zeitraum davor. In dieser Zeit gab es keine anderen Änderungen, die Lade- oder Antwortzeiten spürbar beeinflusst hätten. Gemessen ist das mit der Ladezeit aus Google Analytics. Core Web Vitals wie LCP gab es damals noch nicht.

Standard-Caching und HTML-Caching

Cloudflare sitzt als Netz aus Servern zwischen Besuchern und dem eigenen Webserver. Dateien, die im Cache liegen, liefert Cloudflare direkt aus. Der eigene Server muss dann nicht jede Anfrage selbst beantworten.

Im Standard cacht Cloudflare nur statische Dateien, erkannt an der Dateiendung, etwa Bilder, CSS, JavaScript, Schriften und PDFs. HTML-Seiten holt Cloudflare bei jeder Anfrage frisch vom Server, weil sich ihr Inhalt je Besucher und über die Zeit ändern kann. Das gilt laut Cloudflare-Dokumentation bis heute. HTML-Caching ist eine Zusatzeinstellung, die du gezielt für bestimmte Seiten und Besucher einschaltest.

Drei Hürden im Onlineshop

Die Warenkorb-Vorschau

Auf jeder Seite des Shops stand eine Vorschau des Warenkorbs mit Anzahl und Summe. Cloudflare speichert die Fassung einer Seite, die ein echter Besucher als Erster abruft. Ohne Ausnahme hätte der nächste Besucher den Warenkorb seines Vorgängers gesehen.

Der Name eingeloggter Kunden

Nach dem Login zeigte der Shop den Namen des Kunden im Kopfbereich. Auch dieser Name wäre im Cache gelandet und allen folgenden Besuchern angezeigt worden.

Preise, die sich alle 30 Minuten ändern

Die Preise wurden alle 30 Minuten aktualisiert. Welche Preise sich bei einem Lauf ändern, war vorher nicht absehbar. Eine gecachte Produkt- oder Kategorieseite durfte deshalb nicht lange alte Preise zeigen.

Cookie und Ablaufzeit

Gesucht war ein Weg, der wenig Entwicklungsaufwand braucht. Eine saubere Variante wäre gewesen, Warenkorb und Namen erst im Browser per JavaScript einzusetzen. Dann wäre das HTML für alle gleich und ohne Einschränkung cachebar. Das hätte aber größere Umbauten im Shop verlangt.

Wir haben deshalb nur anonyme Besucher mit leerem Warenkorb aus dem Cache bedient. Dafür gab es in Cloudflare die Einstellung „Bypass Cache on Cookie“, damals nur in den Tarifen Business und Enterprise. Sobald ein Besucher etwas in den Warenkorb legte oder sich einloggte, setzte der Shop ein Cookie namens bypassCache. War es vorhanden, ging die Anfrage am Cache vorbei zum Server. Für die Preise sorgte die „Edge Cache TTL“ dafür, dass Cloudflare eine gespeicherte Seite nach 30 Minuten verwirft.

Die Umsetzung in drei Page Rules

Page Rules greifen von oben nach unten, und für eine URL gilt nur die erste passende Regel. Regel 2 betrifft deshalb keine URL aus Regel 1, Regel 3 nur den Rest.

Die 30 Minuten waren ein Kompromiss. Cloudflare speichert eine Seite beim ersten Abruf und verwirft sie 30 Minuten später, unabhängig vom Zeitpunkt des Preis-Updates. Im ungünstigsten Fall sah ein Besucher also höchstens 30 Minuten lang einen alten Preis. Beschwerden über Preise, die sich im Warenkorb änderten, gab es in der Testphase keine.

Das Cookie per Google Tag Manager

Je nach Shopsystem gibt es passende Cookies schon, oder die Entwicklung setzt sie. Hier haben wir das Cookie mit dem Google Tag Manager gesetzt, weil das ohne Entwicklungsaufwand ging. Zwei Variablen vom Typ „DOM-Element“ lasen den Text des Login-Links und den Wert der Warenkorb-Vorschau aus. Daraus entstanden vier Trigger für die Zustände „Produkt im Warenkorb“, „leerer Warenkorb“, „eingeloggt“ und „ausgeloggt“. Ein Tag setzte bypassCache, sobald ein Produkt im Warenkorb lag oder der Kunde eingeloggt war. Ein zweites Tag löschte das Cookie bei leerem Warenkorb und Logout. Eine Lösung im Shop selbst ist robuster. Der Tag Manager war hier der schnelle Weg zum Test.

Grenzen und nächste Schritte

Laut den E-Commerce-Daten in Google Analytics legten in etwa 95 Prozent der Sitzungen Besucher nichts in den Warenkorb. Der Anteil nicht eingeloggter Besucher war noch höher. Die meisten Besucher profitierten also schon von der einfachen Lösung.

• Seiten mit wenig Traffic lagen selten im Cache, weil die Kopie nach 30 Minuten verfiel. Das trifft Crawler stärker als Besucher, weil sie oft genau solche Seiten abrufen.
• Als nächster Schritt war geplant, nach jedem Preis-Update nur die URLs mit geänderten Preisen über die Cloudflare-API aus dem Cache zu löschen. Die Ablaufzeit hätte dann deutlich länger sein können.
• Warenkorb und persönliche Bereiche sollten später per JavaScript im Browser nachgeladen werden, damit auch Besucher mit Warenkorb gecachte Seiten bekommen.

Was hat sich seitdem geändert?

Die Fallstudie stammt von 2019. Die Messung und das Ergebnis gelten für diesen Zeitraum, und neu getestet haben wir sie nicht. Einiges an der Technik ist heute anders.

• Page Rules werden durch Cache Rules ersetzt. „Cache Everything“ heißt dort „Eligible for cache“, die Edge Cache TTL wird zur Edge TTL, und „Bypass Cache on Cookie“ wird zu einer Regel mit dem Feld http.cookie und der Einstellung „Bypass cache“. Cache Rules gibt es in allen Tarifen.
• Die Reihenfolge ist umgekehrt. Cache Rules lassen sich stapeln, und bei Konflikten gewinnt die letzte passende Regel. Die Ausnahme für Warenkorb und Login gehört deshalb ans Ende.
• Universal Analytics ist abgeschaltet. Heute misst du die Serverantwort als TTFB und die Wirkung auf die Nutzer mit den Felddaten aus CrUX, etwa LCP. Mehr dazu im Ratgeber Core Web Vitals.

So sähe das Setup heute als Cache Rules aus.

Häufige Fehler

• Cache Everything für die ganze Domain ohne Ausnahme für Warenkorb, Login und Checkout.
• Beim Umstieg auf Cache Rules die Reihenfolge der Page Rules übernehmen. Die Ausnahme steht dann oben und wird überschrieben.
• Eine lange Ablaufzeit für Seiten mit Preisen ohne gezieltes Löschen aus dem Cache.
• Das Cookie wird gesetzt, beim Logout oder leerem Warenkorb aber nie gelöscht. Diese Besucher bekommen dann nie gecachte Seiten.
• Nach der Umstellung nicht prüfen, ob die Antwort im Header cf-cache-status HIT oder BYPASS zeigt.

Häufige Fragen