Full-Page-Caching für einen Hyvä-Shop mit Cloudflare – aber sicher

Ein schnelles Theme hilft, eine gecachte Seite hilft mehr. Die schnellste Serverantwort ist die, die PHP gar nicht erst erreicht.

Hyvä-Shops eignen sich gut für Caching, weil das HTML schlank ist und persönliche Daten separat geladen werden. Das macht aber nicht jede Caching-Regel sicher.

Dieser Beitrag erklärt, wie wir Full-Page-Caching in Hyvä mit vorgeschaltetem Cloudflare angehen und welche Fehler wir gesehen haben.

Zwei Cache-Ebenen, zwei Aufgaben

Zwischen Besucher und PHP liegen in der Regel zwei Ebenen:

• Der Full-Page-Cache von Magento. Magento speichert gerenderte Seiten und liefert sie aus, ohne die komplette Anwendung auszuführen. Als Cache-Backend nutzen wir Redis oder Valkey. Varnish ist eine weitere gängige Option.
• Das CDN. Cloudflare sitzt vor dem Server, terminiert TLS nah beim Besucher und cacht statische Dateien.

Der Cache von Magento kennt Store Views, Währungen und Kundengruppen. Cloudflare kennt sie nicht – es sei denn, Sie teilen es ihm mit.

Deshalb ist der Full-Page-Cache von Magento die Basisschicht, und Edge-Caching von HTML ist ein optionaler Schritt obendrauf.

Warum Hyvä das Caching erleichtert

Eine gecachte Seite muss für alle, die sie erhalten, gleich aussehen. Alles Persönliche, etwa der Mini-Warenkorb oder der Name des Kunden, muss nachträglich ergänzt werden.

Magento löst das mit privaten Inhalten, auch Customer Sections genannt. Luma lädt sie über Knockout und RequireJS.

Hyvä lädt dieselben Section-Daten mit wenig eigenem JavaScript und löst dann ein private-content-loaded Event aus. Alpine.js-Komponenten reagieren darauf und füllen die persönlichen Bereiche.

<div x-data="{ count: 0 }"
     @private-content-loaded.window="count = $event.detail.data.cart?.summary_count || 0">
    <span x-text="count"></span>
</div>

Das Ergebnis ist eine Seite, die vollständig gecacht werden kann, gefolgt von einem leichten Request für die persönlichen Bereiche.

Individuelle Templates müssen diesem Muster folgen. Gibt ein Entwickler Kundendaten direkt in einem PHTML-Template aus, bricht dieser Block das Caching oder zeigt – schlimmer noch – die Daten eines Kunden einem anderen an.

Was Cloudflare immer cachen sollte

Statische Dateien und Medien sind der einfache Teil und bringen den größten Gewinn bei geringstem Risiko.

• Statische Inhalte unter pub/static. Im Produktionsmodus enthalten die URLs eine Deploy-Version, daher können Sie lange Cache-Lebensdauern verwenden.
• Produkt- und Theme-Bilder unter pub/media. Cachen Sie sie lange und leeren Sie den Cache nach einem vollständigen Bild-Resize.
• Schriften. Selbst gehostete Schriften gehören zu den statischen Inhalten und werden mit ihnen gecacht.

In einem Hyvä-Shop deckt das die meisten Requests einer Seite ab, denn eine Hyvä-Seite stellt von vornherein relativ wenige Requests.

HTML sicher am Edge cachen

Cloudflare cacht HTML standardmäßig nicht. Sie können es per Cache-Regeln aktivieren, übernehmen dann aber Aufgaben, die sonst Magento erledigt.

Wenn Sie diesen Weg gehen, sind diese Regeln das Minimum:

• Bypass für alles Persönliche oder Transaktionale. Warenkorb, Checkout, Kundenkonto, Wunschliste, Admin, die REST- und GraphQL-Endpunkte sowie die Customer-Section-Requests dürfen nie vom Edge ausgeliefert werden.
• Bypass, wenn der Besucher einen anderen Kontext hat. Magento setzt das X-Magento-Vary Cookie, wenn der Kontext vom Standard abweicht, zum Beispiel bei angemeldeten Kunden oder einer anderen Währung. Requests mit diesem Cookie sollten an den Origin gehen.
• Cachen Sie nur GET-Requests mit erfolgreicher Antwort.
• Halten Sie Store Views getrennt. Teilen sich Sprachen eine Domain, muss die URL die Store View eindeutig erkennen lassen, sonst werden Seiten in einer Sprache Besuchern einer anderen ausgeliefert.
• Kurze Lebensdauern für HTML. Preise und Bestände ändern sich. Eine kurze Edge-Lebensdauer begrenzt den Schaden, wenn ein Purge vergessen wird.

Wenn Ihnen der Pflegeaufwand für diese Regeln zu hoch ist, halten Sie HTML aus dem Edge-Cache heraus. Magentos eigener Cache ist auf einem gut abgestimmten Server bereits schnell, und statische Dateien am Edge erledigen den Großteil der Arbeit.

Purging: der Teil, den viele vergessen

Magento leert Cloudflare nicht von selbst. Jeder Cache, den Sie hinzufügen, braucht eine passende Purge-Routine.

• Nach einem Deploy leeren Sie den Magento-Cache und den Cloudflare-Cache und wärmen Sie anschließend die wichtigsten Seiten vor.
• Nach einem vollständigen Bild-Resize leeren Sie den Cache nach Hostname. Bei uns waren einmal Bilder im CDN gecacht, bevor der Resize-Cache existierte, und das CDN lieferte die alte Antwort aus, bis wir den Cache geleert haben.
• Nach Preis- oder Bestandsänderungen sorgen Sie dafür, dass das betroffene HTML abläuft, entweder durch kurze Lebensdauern oder einen gezielten Purge.

Unsere Deploy-Schritte beschreiben wir in Produktionsmodus und Deploys für Hyvä-Shops.

Ein sinnvolles Standard-Setup

Für die meisten Hyvä-Shops starten wir mit einem Setup, das schnell ist und wenig Raum für Fehler lässt, und fügen Edge-Caching von HTML nur hinzu, wenn es einen klaren Grund gibt.

• Magento-Full-Page-Cache aktiviert, mit Redis oder Valkey als Backend und genug Arbeitsspeicher für den gesamten Katalog.
• Statische Inhalte und Medien am Edge gecacht mit langen Lebensdauern.
• HTML wird durch Cloudflare durchgereicht an den Magento-Cache, sodass Store Views, Währungen und Kundengruppen von Magento behandelt werden.
• Ein Warm-up nach jedem Purge für Startseite, Hauptkategorien und meistverkaufte Produkte.
• Monitoring der Cache-Trefferquoten in Magento und in Cloudflare, damit eine fehlerhafte Regel schnell auffällt.

So bleibt die Time to First Byte für die meisten Besucher niedrig, ohne das Risiko, vom Edge die falsche Seite auszuliefern.

Auch individuelle Extensions verdienen eine Prüfung. Ein Modul, das das Caching für einen häufig genutzten Block deaktiviert oder jeder Antwort ein Cookie hinzufügt, kann einen gecachten Shop unbemerkt in einen ungecachten verwandeln.

Stolpersteine, auf die wir gestoßen sind

• Header-basierte Logik wird am Edge ignoriert. Der Einstiegsplan von Cloudflare hat seinen Bild-Cache nicht nach dem Accept-Header unterschieden, daher blieb unsere WebP-Negotiation in nginx wirkungslos. Stattdessen haben wir die Logik nach Magento verlagert, siehe WebP-Bilder hinter Cloudflare ausliefern.
• Sicherheitsregeln, die Tests beeinflussen. Unser nginx blockiert Bot-User-Agents. Labortools, die sich als solche zu erkennen geben, erhalten einen 403. Das sieht nach einer schnellen Seite aus, ist aber kein echtes Ergebnis.
• Den Origin statt der echten URL testen. Testen Sie immer die öffentliche URL hinter dem CDN, nachdem Sie den Cache geleert und aufgewärmt haben.

FAQ

Brauche ich Varnish für einen Hyvä-Shop?

Nicht unbedingt. Der integrierte Full-Page-Cache von Magento mit Redis oder Valkey funktioniert auf einem passend dimensionierten Server gut. Varnish ist eine valide Wahl, vor allem bei höherem Traffic.

Ist es sicher, das gesamte HTML in Cloudflare zu cachen?

Nur mit strikten Bypass-Regeln für persönliche Seiten, angemeldete Besucher und andere Kontexte sowie einer zuverlässigen Purge-Routine. Ohne diese sollte das HTML-Caching in Magento bleiben.

Warum stellt der Mini-Warenkorb auf einer gecachten Seite trotzdem einen Request?

Das ist so gewollt. Hyvä lädt die Customer Sections nach der Seite, damit das HTML für alle gecacht werden kann, und nur die persönlichen Bereiche werden pro Besucher abgerufen.

Für Hyvä optimierte Server mit Caching, CDN und Purge-Routinen gehören zum Leistungsumfang unserer Hyvä-Pakete. Für reines Hosting siehe Magento Hosting.