Nach einem Theme-Update sehen manche Besucher weiterhin die alte JavaScript-Datei. Ursache ist eine pauschale Jahresfrist, obwohl sich die URL der Datei beim Release nicht geändert hat. Browser-Caching verbessert die Ladezeit nur dann zuverlässig, wenn Laufzeit und Versionierung zusammenpassen.
Dieser Leitfaden zeigt, welche WordPress-Ressourcen sich für lange Cache-Fristen eignen, wie Apache die Header setzt und warum dynamisches oder personalisiertes HTML anders behandelt werden muss.
Inhaltsverzeichnis
Was Browser-Cache-Header steuern
Cache-Controlund Expiresteilen dem Browser mit, wie lange eine Antwort ohne erneute Anfrage verwendet werden darf. Validatoren wie ETagoder Last-Modifiedermöglichen anschließend eine Revalidierung, bei der der Server gegebenenfalls nur Status 304 sendet.
Lange Fristen passen zu statischen Dateien, deren URL sich mit ihrem Inhalt ändert, etwa app.4f18c2.js. Veränderliches HTML, Warenkörbe und angemeldete Ansichten benötigen dagegen kurze, private oder vollständig deaktivierte Zwischenspeicherung.
Ein typischer Fehler nach einem Release
Eine kopierte .htaccess-Vorlage versieht alle Antworten mit einer Laufzeit von einem Jahr. Dadurch bleibt nicht nur app.jsveraltet; ein CDN ergänzt außerdem einen zweiten, widersprüchlichen Cache-Control-Header. Das Leeren des WordPress-Caches erreicht weder bereits gespeicherte Browserantworten noch alle CDN-Knoten.
Die Lösung trennt statische Assets von HTML, entfernt die doppelte Zuständigkeit und führt bei jeder Dateiänderung eine neue URL ein.
Warum die richtige Laufzeit wichtig ist
Wiederkehrende Besucher müssen CSS, JavaScript, Fonts und Bilder nicht bei jedem Seitenaufruf neu laden. Das spart Übertragungsvolumen und verkürzt die Ladezeit. Eine zu lange Frist für unverändert benannte Dateien hält jedoch Fehler und alte Gestaltung im Browser fest.
Bei personalisierten Antworten ist das Risiko größer: Falsch öffentlich gecachtes HTML kann Inhalte eines angemeldeten Zustands weitergeben. Legen Sie Cache-Regeln deshalb nach Ressourcentyp und Benutzerkontext fest, nicht pauschal für das gesamte WordPress-Verzeichnis.
Der sichere Einstieg
- Prüfen Sie in den Browser-Entwicklerwerkzeugen die aktuellen Header von HTML, CSS, JavaScript, Bildern und Fonts.
- Klären Sie, ob Apache, ein Cache-Plugin oder das CDN bereits Header setzt.
- Sichern Sie die aktive
.htaccessund bestimmen Sie eine Ebene als zuständig. - Beginnen Sie mit moderaten Fristen für statische Dateitypen.
- Veröffentlichen Sie eine harmlose Asset-Änderung und prüfen Sie, ob deren URL wechselt oder korrekt revalidiert wird.
Testen Sie anonym und angemeldet. Kontrollieren Sie neben Cache-Controlauch Expires, Age, ETag, Last-Modifiedund CDN-spezifische Header.
Die technische Umsetzung
mod_expireskann Ablaufzeiten anhand des tatsächlich gesendeten MIME-Typs erzeugen. Eine falsche Content-Type-Zuordnung verhindert daher, dass die erwartete Regel greift. mod_headersergänzt bei Bedarf gezielte Cache-Control-Werte.
Begrenzen Sie lange Fristen auf geeignete statische Formate. Die Direktive immutableist nur für Ressourcen sinnvoll, deren URL sich bei jeder Byteänderung zuverlässig ändert. Query-Versionen wie ?ver=1.2.3funktionieren nicht in jeder Zwischen-Cache-Konfiguration gleich zuverlässig; Hash-Dateinamen sind meist eindeutiger.
Beobachten Sie Origin und CDN getrennt. Doppelte Header können eine unklare Richtlinie ergeben, während ein Edge-Cache die Apache-Antwort verändern oder überlagern kann. Stimmen Sie außerdem die Aufbewahrung alter Build-Dateien auf die längste Cache-Frist ab, damit noch aktive URLs nicht vorzeitig verschwinden.
Risiken, Backup und Rollback
Die häufigsten Fehler sind lange Fristen für HTML, immutableohne echte Dateiversionierung und mehrere Ebenen, die denselben Header setzen. Auch die Verwechslung von no-cacheund no-storeführt zu falschen Erwartungen: Ersteres verlangt Revalidierung, letzteres untersagt das Speichern.
Stellen Sie bei veralteten oder widersprüchlichen Antworten die gesicherte .htaccesswieder her und entfernen Sie die betroffenen Header auf der zuständigen Ebene. Leeren Sie CDN- und Anwendungscaches gezielt; bereits im Browser gespeicherte lange Fristen lassen sich nur durch eine neue Asset-URL sicher umgehen.
Wie AIOWS unterstützt:
Wie AIOWS Htaccess Editor hilft
AIOWS Htaccess Editor bietet in unterstützten Apache-Umgebungen eine verwaltete Oberfläche für Änderungen an der .htaccessund erstellt vor dem Speichern automatisch eine Sicherung. Damit können MIME-spezifische Cache-Regeln nachvollziehbar ergänzt oder zurückgesetzt werden.
Erfassen Sie zunächst die vorhandenen Header und legen Sie fest, welche Ebene sie steuern soll. Bearbeiten Sie nur die Regeln für geeignete statische Dateien und prüfen Sie nach dem Speichern sowohl eine wiederholte Anfrage als auch ein neues Release. Die automatische Sicherung hilft beim Rollback; ein unabhängiger Dateizugriff bleibt für Serverfehler erforderlich.
Das Modul kann keine CDN-Richtlinie ändern und keine fehlende Asset-Versionierung erzeugen. Dynamische sowie personalisierte WordPress-Antworten müssen weiterhin vom jeweiligen Cache-System korrekt behandelt werden.
Passende AIOWS-Artikel
- WordPress-Cache leeren: Seiten-, Objekt-, Browser- und CDN-Cache
- Wie WordPress-Caching funktioniert
- WordPress-Sicherheitsheader mit .htaccess einrichten
Fazit
Vergeben Sie lange Cache-Fristen nur für statische Dateien mit zuverlässig wechselnder URL. Behandeln Sie HTML und angemeldete Ansichten separat, vermeiden Sie doppelte Header und prüfen Sie bei jedem Release, ob Besucher die neue Ressource erhalten.
