Ihre Kunden sehen die alte Version des Shops: Browser-Cache und Versionierung

Sie haben einen Designfehler in der mobilen Ansicht behoben, geprüft, dass alles gut aussieht, und das Thema abgehakt. Am nächsten Tag schickt Ihnen ein Kunde einen Screenshot mit der verschobenen Seite, genau wie vorher. Sie können es nicht nachstellen. Der Kunde irrt sich nicht: Sein Browser verwendet weiterhin das alte Stylesheet, das er beim letzten Besuch im Shop gespeichert hat.

Es ist eines der verwirrendsten Probleme bei der Pflege eines Shops, weil es demjenigen, der die Änderung vornimmt, nie passiert. Sehen wir uns an, warum es auftritt und wie Sie es vermeiden.

Warum der Browser Dateien speichert

Damit Seiten schnell laden, speichert der Browser eine Kopie der Dateien, die sich selten ändern: Stylesheets, Skripte, Bilder und Schriften. Wenn er sie das nächste Mal braucht, nimmt er seine Kopie, statt sie beim Server anzufordern. Wie lange er sie aufbewahrt, bestimmen die Cache-Header, die der Server mit jeder Datei mitschickt.

Für einen Shop ist es gut, wenn diese Dateien lange gespeichert werden: weniger Anfragen, schnellere Seiten, weniger Last auf dem Server. Das Problem entsteht, wenn Sie eine davon ändern und ihre Adresse gleich bleibt. Der Browser kann nicht wissen, dass es eine neue Version gibt, und verwendet seine weiter, bis sie abläuft.

Die Symptome

• Verschobenes oder unvollständiges Design nur bei manchen Kunden.
• Ein Button, der nichts tut, weil das HTML neu ist, das JavaScript aber alt (oder umgekehrt).
• JavaScript-Fehler in der Konsole, die in Ihrem Browser nicht auftreten.
• Beschwerden, die nach ein paar Tagen von selbst verschwinden, wenn die Kopien ablaufen.
• Das klassische „Bei mir funktioniert es“ des Entwicklers, der mit geleertem Cache neu lädt.

Es ist nicht nur der Browser

Zwischen Ihrem Server und dem Kunden können mehrere Schichten Kopien vorhalten:

• Der Cache von PrestaShop für zusammengefasste Dateien. Wenn Sie die Option zum Zusammenfassen, Komprimieren und Cachen von CSS und JS aktiviert haben, liefert der Shop Dateien aus, die aus Ihren erzeugt wurden. Ändern Sie eine Quelldatei und wird die zusammengefasste Version nicht neu erzeugt, sieht niemand die Änderung, nicht einmal Sie.
• Der Template-Cache von Smarty, wenn Sie ein Template geändert haben.
• Ein Seiten-Cache in einem Modul oder auf dem Server, der das HTML mit den alten Adressen speichert.
• Ein CDN oder ein Proxy vor dem Shop, mit einer eigenen Kopie der Dateien.
• Der Browser jedes einzelnen Kunden.

Die ersten vier haben Sie in der Hand: Sie zu leeren gehört zu jeder Designänderung. Die letzte nicht: Sie können nicht jeden Kunden bitten, seinen Cache zu leeren.

Die Lösung: Die Adresse ändert sich, wenn sich die Datei ändert

Die Standardtechnik heißt Versionierung (oder Cache Busting). Dabei enthält die Adresse der Datei etwas, das sich bei jeder inhaltlichen Änderung ändert. Zum Beispiel durch einen Parameter: Aus custom.css?v=20 wird custom.css?v=21. Für den Browser ist das eine neue Adresse, also lädt er sie herunter; und solange sie sich nicht ändert, darf er sie so lange speichern, wie er will.

Diese Kennung lässt sich auf verschiedene Weise berechnen:

• Nach dem Änderungsdatum der Datei. Automatisch: Jedes Mal, wenn Sie die Datei speichern, ändert sie sich. Nur was sich geändert hat, wird neu geladen.
• Nach einem Hash des Inhalts. Ebenso automatisch und genauer, muss aber berechnet werden.
• Eine globale Versionsnummer, die Sie bei jedem Deployment selbst erhöhen. Dann wird alles neu geladen, auch wenn sich nur eine Datei geändert hat.

Wenn PrestaShop die Dateien zusammenfasst und komprimiert, erzeugt es beim Neuerzeugen bereits neue Namen für die zusammengefasste Datei. Aber nicht alle Shops nutzen diese Option (manchmal gibt es damit Probleme mit der Ladereihenfolge bestimmter Module), und sie deckt keine einzeln geladenen Dateien ab.

Vorsicht mit den Datumsangaben beim Deployment

Die Versionierung nach Änderungsdatum hat einen Haken: Wenn Sie die Dateien mit einem Werkzeug hochladen, das das ursprüngliche Datum beibehält (manche FTP-Programme, manche Arten des Deployments oder der Wiederherstellung von Sicherungen), ändert sich die Datei, ihr Datum aber nicht, und die Versionskennung bleibt gleich. In solchen Fällen müssen Sie nach dem Deployment von Hand eine neue Version erzwingen können.

Und wenn ich die Cache-Dauer verkürze?

Das ist die Versuchung, wenn sich das Problem wiederholt: den Server so einstellen, dass der Browser CSS und JS nur ein paar Minuten speichert oder immer nachfragt, ob es eine neue Version gibt. Das funktioniert, aber Sie zahlen bei jedem Besuch dafür: mehr Anfragen, längeres Warten auf dem Smartphone und mehr Last auf dem Server, auch für Dateien, die sich monatelang nicht ändern. Mit der Versionierung können Sie genau das Gegenteil tun: lange Cache-Zeiten beibehalten, was der Geschwindigkeit zugutekommt, denn wenn sich eine Datei ändert, ändert sich auch ihre Adresse.

Sinnvoll ist dagegen, dass das HTML der Seiten nicht lange im Browser oder in Zwischenschichten gespeichert wird, denn es enthält die Adressen mit der Version. Bleibt das alte HTML im Cache, fordert es weiter die alten Dateien an, auch wenn sie versioniert sind.

Was Sie nach jeder Designänderung tun sollten

1. Leeren Sie den Cache von PrestaShop (Templates und zusammengefasste Dateien) unter Erweiterte Einstellungen → Leistung.
2. Wenn Sie einen Seiten-Cache oder ein CDN haben, leeren Sie diese.
3. Prüfen Sie, dass die Adressen der geänderten CSS- und JS-Dateien eine neue Versionskennung haben (im Quelltext der Seite).
4. Testen Sie in einem Browser, mit dem Sie den Shop schon vor der Änderung besucht hatten, ohne dessen Cache zu leeren: So sieht es ein echter Kunde.
5. Testen Sie auf dem Smartphone, das meist ältere Kopien hat.

So lösen Sie es in PrestaShop

Rekire Cache Buster hängt an jede lokale CSS- und JS-Datei des Frontends eine Versionskennung (?v=) an, damit der Browser die neue Datei herunterlädt, sobald sie sich ändert. Es gibt zwei Modi: automatisch, mit der Version aus dem Änderungsdatum jeder Datei, oder manuell, mit einem einheitlichen Token, das Sie selbst ändern. Sie können es für CSS, für JS oder für beides aktivieren, und die Schaltfläche Jetzt Neuladen erzwingen zwingt alle Besucher, CSS und JS nach einem Deployment neu zu laden, genau das, was Sie brauchen, wenn Ihre Art des Hochladens die Dateidaten beibehält. Dateien, die von einer anderen Domain oder einem CDN ausgeliefert werden, und solche, die bereits eine eigene Version tragen, lässt es unberührt, und es fasst nichts zusammen und komprimiert nichts, verändert also die Ladereihenfolge nicht. Kompatibel mit PrestaShop 1.7, 8 und 9.