Browser-Caching richtig einstellen: Cache-Control, Expires und optimale Cache-Zeiten

Browser-Caching-Zeiten legen über HTTP-Cache-Regeln fest, wie lange statische Dateien Ihrer Website im Browser der Besucher gespeichert bleiben. In der Praxis werden für CSS, JavaScript, Bilder, Schriften und Icons vor allem Cache-Control-Header definiert, in manchen Umgebungen zusätzlich Expires-Header. Für versionierte CSS- und JS-Dateien sind zum Beispiel 1 Jahr sinnvoll, für Bilder je nach Einsatz 30 Tage bis 1 Jahr, während HTML-Seiten meist nur kurz zwischengespeichert oder bei jedem Aufruf erneut validiert werden sollten. Richtig konfiguriert verhindert Browser-Caching, dass identische Dateien immer wieder neu heruntergeladen werden, beschleunigt den Seitenaufbau und kann wichtige Core-Web-Vitals-Kennzahlen verbessern.

In diesem Leitfaden erklären wir, wie Browser-Caching funktioniert, welche Cache-Dauer für welchen Dateityp sinnvoll ist und wie Sie die Einstellungen in Apache, Nginx, LiteSpeed, WordPress und über ein CDN sauber umsetzen. Ziel ist nicht nur ein grüner Wert in einem Speed-Test-Tool. Entscheidend ist, Besuchern aktuelle Dateien auszuliefern, Serverressourcen effizient zu nutzen, TTFB und Bandbreitenverbrauch zu senken und bei wiederkehrenden Besuchern einen spürbaren Geschwindigkeitsvorteil zu erzielen. Besonders bei Shared Hosting, WordPress-Hosting und professionellen Unternehmenswebsites gehört eine durchdachte Cache-Strategie zu den wirksamsten Performance-Optimierungen mit vergleichsweise geringem Aufwand. Hostragons Webhosting-Pakete

Was ist Browser-Caching?

Browser-Caching bedeutet, dass statische Ressourcen, die beim Laden einer Webseite heruntergeladen werden, vorübergehend auf dem Gerät des Nutzers gespeichert werden. Ruft ein Besucher Ihre Startseite auf, lädt der Browser beispielsweise das Logo, CSS-Dateien, JavaScript-Dateien, Webfonts und Bilder. Sind für diese Dateien passende Cache-Header gesetzt, muss der Browser sie beim Wechsel auf eine Unterseite oder bei einem späteren erneuten Besuch nicht erneut vollständig vom Server anfordern. Das Ergebnis: Die Seite lädt schneller und fühlt sich flüssiger an.

Stellen Sie sich eine Startseite mit 2 MB Gesamtgröße vor. Davon entfallen 1,4 MB auf Bilder, 300 KB auf CSS- und JavaScript-Dateien und 100 KB auf Schriften. Beim ersten Besuch werden diese Ressourcen in der Regel heruntergeladen. Beim zweiten Besuch kann der Browser viele dieser statischen Dateien lokal aus dem Cache verwenden. Die über das Netzwerk übertragene Datenmenge sinkt dadurch deutlich. Besonders auf mobilen Verbindungen, bei internationalem Traffic und auf Websites mit vielen wiederkehrenden Nutzern ist dieser Unterschied unmittelbar spürbar.

Browser-Caching sollte nicht mit serverseitigem Caching verwechselt werden. Server-Cache speichert zum Beispiel PHP-Ausgaben, Datenbankabfragen oder fertige HTML-Seiten auf dem Server. Browser-Cache sorgt dagegen dafür, dass Ressourcen auf dem Gerät des Besuchers wiederverwendet werden. Für eine wirklich schnelle Website sollten beide Ebenen gemeinsam geplant werden. Bei WordPress-Websites sind Page Cache, Object Cache, CDN Cache und Browser Cache häufig Bausteine derselben Optimierungsstrategie. WordPress Hosting und Performance-Optimierung

Warum ist Browser-Caching für SEO wichtig?

Google bewertet Websites nicht allein nach Inhalt, sondern auch danach, ob Nutzer eine schnelle, stabile und angenehme Erfahrung machen. Browser-Caching ist zwar kein isolierter Ranking-Garant, unterstützt aber die technische SEO-Leistung, weil es Ladezeiten, Interaktionsverzögerungen und die Effizienz beim Nachladen von Ressourcen verbessert. Besonders bei wiederkehrenden Besuchern, beim Durchklicken von Kategorien, beim Wechsel zwischen Produktseiten oder bei längeren Blog-Sessions kann der Effekt erheblich sein.

Technische Performance bedeutet nach modernen SEO-Standards nicht nur, in Lighthouse eine hohe Punktzahl zu erreichen. Google betrachtet Nutzererfahrung im Zusammenhang mit LCP, INP, CLS, TTFB und realen Nutzerdaten. Wenn CSS- und JavaScript-Dateien unnötig wiederholt geladen werden, kann sich der Largest Contentful Paint verlängern. Werden Fonts auf jeder Seite neu angefordert, kann das die visuelle Stabilität beeinflussen. Werden große Bilder nicht sinnvoll gecacht, wirkt die Website gerade auf Mobilgeräten träge.

• Schnellere wiederkehrende Besuche: Nutzer müssen dieselben Dateien nicht erneut herunterladen.
• Geringerer Bandbreitenverbrauch: Der Server-Traffic sinkt, Hosting-Ressourcen werden effizienter genutzt.
• Bessere Crawling-Effizienz: Statische Ressourcen werden für Bots und Nutzer kontrollierter ausgeliefert.
• Niedrigere Absprungrate: Schneller ladende Seiten fördern Interaktion und Seitenaufrufe.
• Stabilere Performance: Lastspitzen auf Hosting- und CDN-Ebene lassen sich besser abfedern.

Die wichtigsten HTTP-Cache-Header

Browser-Caching-Zeiten werden über HTTP-Antwort-Header gesteuert. Die wichtigsten Header sind Cache-Control, Expires, ETag und Last-Modified. In modernen Projekten ist Cache-Control der zentrale Steuerungsmechanismus. Expires wird vor allem aus Gründen der Abwärtskompatibilität zusätzlich verwendet.

Cache-Control

Cache-Control teilt Browsern und zwischengeschalteten Cache-Systemen mit, wie eine Datei gespeichert und wiederverwendet werden darf. Besonders häufig kommen folgende Direktiven zum Einsatz:

• max-age: Gibt in Sekunden an, wie lange eine Ressource als frisch gilt. max-age=31536000 entspricht ungefähr 1 Jahr.
• public: Erlaubt das Speichern im Browser und in gemeinsamen Cache-Systemen wie CDNs.
• private: Bedeutet, dass die Ressource nur im Browser des jeweiligen Nutzers gespeichert werden soll.
• no-cache: Die Ressource darf gespeichert werden, muss aber vor der Verwendung beim Server validiert werden; es bedeutet nicht, dass Caching komplett deaktiviert ist.
• no-store: Die Ressource darf nirgendwo gespeichert werden; geeignet für Zahlungsseiten, Kundenbereiche und personenbezogene Daten.
• immutable: Signalisiert, dass sich die Ressource bis zum Ablauf der Cache-Zeit nicht ändert; ideal für Dateien mit versioniertem Dateinamen.

Ein typischer Header für eine statische Datei könnte so aussehen: Cache-Control: public, max-age=31536000, immutable. Damit wird dem Browser gesagt, dass er die Datei 1 Jahr speichern darf und sie nicht erneut prüfen muss, solange sich der Dateiname nicht ändert.

Expires

Der Expires-Header gibt an, bis zu welchem konkreten Datum und welcher Uhrzeit eine Ressource gültig ist. Für ein Bild kann zum Beispiel ein Expires-Wert gesetzt werden, der 30 Tage in der Zukunft liegt. Da Expires jedoch mit absoluten Zeitpunkten arbeitet, ist er weniger flexibel als Cache-Control. In aktuellen Konfigurationen sollte Cache-Control Vorrang haben; Expires kann ergänzend für ältere Clients oder Legacy-Setups gesetzt werden.

ETag und Last-Modified

ETag und Last-Modified sind Validierungsmechanismen. Der Browser kann den Server fragen, ob seine lokal gespeicherte Version einer Datei noch aktuell ist. Hat sich die Datei nicht geändert, antwortet der Server mit 304 Not Modified, und der Dateikörper muss nicht erneut übertragen werden. Das ist besonders nützlich für HTML oder andere Inhalte, die sich häufiger ändern können und für die Sie keine lange feste Cache-Dauer vergeben möchten.

Welche Cache-Dauer ist für welchen Dateityp sinnvoll?

Ein häufiger Fehler besteht darin, allen Dateitypen dieselbe Cache-Dauer zu geben. HTML, CSS, JavaScript, Bilder, Fonts und API-Antworten haben jedoch völlig unterschiedliche Aktualisierungszyklen. Die Grundregel ist einfach: Wenn sich der Dateiname bei Änderungen zuverlässig ändern lässt, darf die Datei lange gecacht werden. Wenn sich der Inhalt unter gleichem Dateinamen häufig ändert, sind kurze Zeiten oder Revalidierung die bessere Wahl.

Diese Tabelle ist ein praxisnaher Ausgangspunkt, kein starres Gesetz. In einem Online-Shop sollten HTML-Seiten mit Preis- und Lagerinformationen nicht aggressiv im Browser gecacht werden. Produktbilder können dagegen bei sauberer Dateiversionierung problemlos 1 Jahr im Cache bleiben. Auf einer Unternehmenswebsite lassen sich Logo, Fonts und Theme-Dateien lange speichern; häufig wechselnde Aktionsbanner sind mit 7 bis 30 Tagen oft sicherer konfiguriert.

Wie plant man Browser-Caching-Zeiten richtig?

Eine erfolgreiche Cache-Strategie beginnt mit einer sauberen Einteilung der Dateien auf Ihrer Website. Technisch werden Regeln meist nach Dateiendungen geschrieben. Strategisch entscheidend ist jedoch, wie oft sich die jeweiligen Inhalte ändern und wie kritisch Aktualität für den Nutzer ist.

1. Statische und dynamische Ressourcen trennen

CSS, JS, JPG, PNG, WebP, SVG und WOFF2 sind typische statische Ressourcen. HTML, Warenkorb, Kundenkonto, Suchergebnisse und API-Antworten gelten als dynamisch oder zumindest kontextabhängig. Statische Ressourcen können lange gecacht werden, während dynamische Inhalte mit mehr Vorsicht behandelt werden sollten. Bei nutzerspezifischen Inhalten darf insbesondere kein public cache verwendet werden.

2. Dateiversionierung verwenden

Der sichere Weg zu langen Cache-Zeiten ist Dateiversionierung. Wenn Sie style.css für 1 Jahr cachen und anschließend den Inhalt ändern, sehen manche Nutzer möglicherweise weiterhin das alte Design. Besser ist es, Dateinamen wie style.2026.01.css, app.v12.js oder hashbasierte Namen wie app.8f3a2.js zu verwenden. Bei einer Änderung wird ein neuer Dateiname ausgeliefert, und der Browser lädt automatisch die neue Ressource.

WordPress-Themes und moderne Build-Tools können diese Aufgabe automatisieren. Wenn Sie ein Theme entwickeln, erleichtert der version-Parameter in wp_enqueue_style und wp_enqueue_script die Versionsverwaltung über Query String oder Dateiname. Da manche CDN-Konfigurationen Query Strings beim Caching unterschiedlich behandeln, ist ein Hash direkt im Dateinamen oft die robustere Lösung.

3. Bei HTML nicht zu aggressiv sein

HTML-Seiten enthalten den eigentlichen Inhalt, den Nutzer sehen. Deshalb werden sie meist nur kurz gecacht oder über Revalidation gesteuert. Bei Blogartikeln können 5 bis 10 Minuten ausreichend sein; bei Nachrichten, Kampagnen, Preis- oder Verfügbarkeitsseiten ist oft eine noch kürzere Dauer sinnvoll. Wenn Sie in WordPress Page Cache verwenden, sollten Browser-Cache-Header immer zusammen mit Server-Cache und CDN-Purge-Mechanismen betrachtet werden.

4. Cache auf sicherheitskritischen Seiten deaktivieren

Login-Seiten, Kundenbereiche, Checkout-Schritte, Bestellübersichten, Rechnungen und Seiten mit personenbezogenen Daten sollten Header wie Cache-Control: no-store, private verwenden. Browser-Caching ist ein Performance-Werkzeug, darf aber niemals die Vertraulichkeit von Nutzerdaten gefährden. SSL ist in diesem Zusammenhang eine grundlegende Voraussetzung. Hostragons SSL-Zertifikate

Browser-Caching mit Apache .htaccess einstellen

Auf Apache-Servern wird Browser-Caching häufig über die .htaccess-Datei konfiguriert. Für viele Website-Betreiber mit Shared Hosting ist das der praktischste Weg. Voraussetzung ist, dass die Module mod_expires und mod_headers aktiv sind. In hochwertigen Hosting-Umgebungen sind diese Module in der Regel bereits verfügbar.

Die Logik ist einfach: lange Cache-Zeiten für Bilder und Fonts, lange Zeiten für versionierte CSS- und JS-Dateien, kurze Revalidierung für HTML. In den Regeln der .htaccess-Datei werden je nach Dateityp ExpiresByType und Header set Cache-Control definiert. Für image/webp, image/jpeg, image/png und image/svg+xml kann beispielsweise 1 Jahr gelten; für text/css und application/javascript ebenfalls 1 Jahr; für text/html hingegen no-cache.

Erstellen Sie vor Änderungen unbedingt ein Backup Ihrer .htaccess-Datei. Ein falsch geschriebenes Regelwerk kann schnell zu einem 500 Internal Server Error führen. Nach der Änderung sollten Sie die Website in einem privaten Browserfenster öffnen und anschließend im Network-Tab der DevTools die Response Headers der betroffenen Datei prüfen. Wird Cache-Control nicht angezeigt, kann das Servermodul deaktiviert sein, ein CDN den Header verändern oder ein Plugin die Header überschreiben.

Typische Startwerte auf Apache-Seite sind: CSS und JS mit max-age=31536000, Bilder ebenfalls mit max-age=31536000, PDF-Dateien mit max-age=2592000, HTML mit max-age=0 und no-cache. Diese Werte sind ein guter Einstieg, sollten aber an den Veröffentlichungsrhythmus Ihrer Website angepasst werden. Wenn Sie in der Hostragons-Hosting-Infrastruktur Performance-Einstellungen über .htaccess nutzen, prüfen Sie zusätzlich, ob es Konflikte mit Cache-Optionen Ihres Themes oder Ihrer Plugins gibt. Apache .htaccess Leistungsanpassungen

Browser-Caching mit Nginx konfigurieren

Auf Nginx-Servern werden Cache-Header innerhalb von server- oder location-Blöcken definiert. Nginx wird besonders bei trafficstarken Projekten geschätzt, weil statische Dateien sehr performant ausgeliefert werden können. Das Grundprinzip besteht darin, über dateiendungsbasierte location-Regeln passende expires- und add_header-Cache-Control-Werte zu setzen.

Ein typischer Ansatz sieht so aus: Statische Ressourcen wie CSS, JS, WebP, JPG, PNG, SVG und WOFF2 erhalten expires 1y sowie Cache-Control public, immutable. Für HTML-Ausgaben wird expires off oder no-cache verwendet. Wenn ein CDN vorgeschaltet ist, sollten Sie zusätzlich testen, wie das CDN die vom Origin-Server gelieferten Cache-Control-Header interpretiert.

Bei Nginx ist wichtig zu wissen, dass die add_header-Direktive je nach Konfiguration nur für bestimmte Antwortcodes greift. In modernen Setups kann der Parameter always sinnvoll sein. Außerdem können doppelte oder widersprüchliche Cache-Control-Werte entstehen, wenn dieselben Header gleichzeitig von Anwendung, Nginx und CDN gesetzt werden. In diesem Fall sollte klar definiert werden, welche Ebene die maßgebliche Quelle für Cache-Regeln ist.

Caching in LiteSpeed- und WordPress-Websites

LiteSpeed-Server bieten besonders in WordPress-Projekten in Kombination mit dem LiteSpeed Cache Plugin einen starken Performance-Vorteil. Dennoch sollten Browser-Caching und Page Cache sauber voneinander getrennt betrachtet werden. Wenn im LiteSpeed Cache Plugin die Option Browser Cache aktiviert ist, können Cache-Header für statische Dateien automatisch gesetzt werden. Trotzdem lohnt es sich, die tatsächlichen Zeiten zu kontrollieren.

In WordPress ist die empfohlene Praxis, statische Assets lange zu cachen und Dateiversionierung aktiv zu halten. Wenn Sie ein Theme aktualisieren, CSS ändern oder JavaScript anpassen, sollte das Cache-Plugin den Cache leeren. Wird ein CDN genutzt, muss zusätzlich ein CDN-Purge erfolgen. Andernfalls können einzelne Besucher noch das alte Design sehen oder auf fehlerhaftes JavaScript stoßen.

Beliebte Cache-Plugins bieten Funktionen wie Browser Cache, Minify, Combine, Critical CSS, CDN-Integration und Object Cache. Es ist jedoch nicht immer sinnvoll, alle Optionen gleichzeitig und maximal aggressiv zu aktivieren. Richten Sie zuerst die Browser-Cache-Header ein und testen Sie anschließend Minify- und Combine-Einstellungen. Da HTTP/2 und HTTP/3 heute weit verbreitet sind, ist das Zusammenführen jeder einzelnen Datei nicht mehr so entscheidend wie früher. In manchen Fällen verschlechtert es sogar die Cache-Effizienz.

Wenn Ihre WordPress-Website langsam ist, liegt das Problem nicht automatisch nur am Browser-Cache. Eine aufgeblähte Datenbank, ein schweres Theme, zu viele Plugins, nicht optimierte Bilder oder ein ressourcenschwaches Hosting-Paket können die Performance ebenfalls bremsen. Bewerten Sie Cache-Einstellungen deshalb immer gemeinsam mit hochwertigem Hosting, einer aktuellen PHP-Version und einer korrekten SSL-Konfiguration. Hostragons WordPress-Hosting

Wie sollten Cache-Zeiten bei Nutzung eines CDN eingestellt werden?

Ein CDN liefert statische Dateien über geografisch nahe Edge-Server an den Nutzer aus. Browser-Cache speichert die Datei zusätzlich direkt im Browser des Besuchers. Arbeiten beide Ebenen sauber zusammen, steigt die Performance deutlich. Wichtig ist jedoch, dass die im CDN-Panel eingestellte Edge-Cache-Dauer mit den Cache-Control-Headern des Origin-Servers harmoniert.

Ein bewährter Ansatz ist: Auf dem Origin-Server erhalten statische Dateien 1 Jahr Cache-Control, im CDN wird ein gleicher oder bewusst kontrollierter TTL-Wert festgelegt. Bei Dateiänderungen werden Dateinamen versioniert oder ein CDN-Purge ausgeführt. Wenn Sie HTML-Seiten über das CDN cachen, sollten Sie sehr gezielte Regeln erstellen. Warenkorb, Konto, Checkout und Admin-Bereich müssen unbedingt vom Cache ausgeschlossen werden.

Ein typisches Problem bei CDN-Websites ist, dass nach einem Update weiterhin alte Dateien angezeigt werden. Ursache ist meist, dass der Inhalt unter gleichem Dateinamen geändert wurde oder kein CDN-Purge stattgefunden hat. Die stabilste Methode ist, im Build-Prozess Dateien mit Hash im Namen zu erzeugen und im HTML den neuen Dateinamen zu referenzieren. Dann fordern Browser und CDN automatisch die neue Datei an, selbst wenn alte Assets noch irgendwo gespeichert sind.

Schritt-für-Schritt-Checkliste für die Umsetzung

Die folgende Checkliste bietet einen praktischen Umsetzungsplan für Browser-Caching-Zeiten. Bei einer kleinen Unternehmenswebsite lässt sich das oft innerhalb von 30 bis 60 Minuten umsetzen. Bei Online-Shops oder individuellen Webanwendungen sollte die Testphase großzügiger geplant werden.

• 1. Dateiinventar erstellen: Trennen Sie CSS, JS, Bilder, Fonts, PDF, HTML und API-Antworten.
• 2. Aktualisierungsfrequenz bestimmen: Notieren Sie, welche Dateien täglich, wöchentlich oder nur monatlich geändert werden.
• 3. Versionierungsstrategie wählen: Nutzen Sie Datei-Hashes, Versionsparameter oder Build-Nummern.
• 4. Serverregeln ergänzen: Definieren Sie Cache-Control-Header in Apache, Nginx, LiteSpeed oder im CDN-Panel.
• 5. Sichere Seiten ausschließen: Verwenden Sie no-store für Admin, Checkout, Warenkorb, Kundenkonto und personenbezogene Daten.
• 6. Gründlich testen: Prüfen Sie mit Chrome DevTools, curl -I, WebPageTest, Lighthouse und echten Geräten.
• 7. Nach dem Go-live überwachen: Achten Sie auf alte Dateien, Layoutfehler oder JavaScript-Probleme.

Wie testet man Browser-Caching?

Der schnellste Weg zur Prüfung führt über die Entwicklertools des Browsers. Öffnen Sie Ihre Website in Chrome, wechseln Sie in den DevTools zum Network-Tab, klicken Sie auf eine CSS-Datei oder ein Bild und prüfen Sie im Bereich Response Headers den Cache-Control-Wert. Beim zweiten Laden können in der Status-Spalte Hinweise wie memory cache oder disk cache erscheinen.

Wenn Sie mit der Kommandozeile arbeiten, zeigt der Befehl curl -I ihre-domain.de/datei.css die Antwort-Header an. Dort können Sie Cache-Control, Expires, ETag und Last-Modified kontrollieren. Fehlt der erwartete Header, überschreibt möglicherweise die Anwendung, der Webserver oder das CDN Ihre Einstellung.

Für Performance-Tests eignen sich Lighthouse, PageSpeed Insights und WebPageTest. Trotzdem sollten Sie deren Empfehlungen nicht blind übernehmen, sondern im Kontext echter Nutzerabläufe bewerten. Lighthouse empfiehlt für statische Dateien oft lange Cache-Zeiten, erwartet diese Aggressivität aber nicht für HTML-Seiten. Außerdem weisen Testtools teilweise auf Drittanbieter-Skripte hin. Bei Google Fonts, Werbenetzwerken oder Social-Media-Skripten können Sie die Cache-Dauer meist nicht selbst steuern.

Häufige Fehler beim Browser-Caching

Browser-Caching wirkt auf den ersten Blick simpel. Falsch konfiguriert kann es jedoch zu Update-Problemen, Sicherheitsrisiken und schlechter Nutzererfahrung führen. Die folgenden Fehler treten besonders häufig bei Einsteigern und schnell gewachsenen Websites auf.

• Alle Ressourcen 1 Jahr cachen: HTML, API-Antworten und nutzerspezifische Inhalte gehören nicht in diese Kategorie.
• Lange Cache-Zeiten ohne Dateiversionierung: Nutzer können weiterhin alte CSS- oder JS-Dateien erhalten.
• CDN-Purge vergessen: Auch wenn der Origin aktualisiert wurde, kann das CDN alte Dateien ausliefern.
• Mehrere Cache-Plugins stapeln: Mehrere Plugins können dieselben Header setzen und Konflikte verursachen.
• Drittanbieter-Warnungen falsch interpretieren: Cache-Header externer Skripte liegen häufig nicht in Ihrer Kontrolle.
• Sichere Seiten cachen: Für Checkout- und Kontoseiten sollte no-store verwendet werden.

Empfohlene Startwerte

Für eine neue Website lassen sich sichere Startwerte so zusammenfassen: Versionierte CSS- und JS-Dateien 1 Jahr; Bilder 1 Jahr, häufig wechselnde Kampagnenbilder 30 Tage; Fonts 1 Jahr; PDF-Dateien je nach Aktualisierungsrhythmus 7 bis 180 Tage; HTML-Seiten no-cache oder nur wenige Minuten. Dieser Ansatz hält die Balance zwischen Performance und Aktualität.

Bei einer klassischen Unternehmenswebsite funktionieren lange Cache-Zeiten meist problemlos. Bei einem Online-Shop können Sie statische Dateien auf Produktseiten lange cachen, müssen Preis, Lagerbestand, Warenkorb und Nutzerdaten aber vom Cache ausschließen. Bei Nachrichten- oder Blog-Portalen lassen sich Bilder und Theme-Dateien lange speichern, während HTML-Ausgaben an die Veröffentlichungsfrequenz angepasst werden sollten. Auch Domain, SSL und Hosting-Infrastruktur sind Teil derselben Performance-Kette. Hostragons Domainabfrage Hostragons Unternehmenshostinglösungen

Fazit

Richtig geplante Browser-Caching-Zeiten können die Performance Ihrer Website bei wiederkehrenden Besuchen deutlich verbessern. Die wichtigste Regel lautet: Versionierte statische Dateien erhalten lange Cache-Zeiten, HTML-Seiten und Seiten mit personenbezogenen Daten kurze Zeiten, Revalidierung oder no-store. Ob Apache, Nginx, LiteSpeed, WordPress oder CDN: Die Logik bleibt gleich. Ressourcentyp erkennen, Aktualisierungsfrequenz festlegen, Cache-Control-Header testen und nach der Veröffentlichung weiter beobachten.

Kurz gesagt: Browser-Caching ist eine kostengünstige, aber sehr wirkungsvolle Maßnahme zur Ladezeitoptimierung. Wenn Sie Ihre Website auf Hostragons-Infrastruktur betreiben, können Sie passend zu Ihrem Hosting-Typ geeignete Cache-Einstellungen wählen und damit sowohl Nutzererfahrung als auch technische SEO stärken. Um die passende Hosting-Lösung zu finden, können Sie die Hostragons-Hosting-Optionen prüfen oder die Cache-Konfiguration Ihrer bestehenden Website Schritt für Schritt kontrollieren. Hostragons Hosting-Pakete

Häufig gestellte Fragen

Wie lange sollte Browser-Caching dauern?

Für versionierte statische Dateien wie CSS, JS, Bilder und Fonts sind 30 Tage bis 1 Jahr ideal. Bei HTML-Seiten ist Aktualität wichtiger, daher sind no-cache, max-age=0 oder kurze Zeiträume von wenigen Minuten meist die bessere Wahl.

Was ist der Unterschied zwischen Cache-Control und Expires?

Cache-Control ist der modernere und flexiblere HTTP-Header und arbeitet mit Regeln wie max-age in Sekunden. Expires gibt dagegen ein festes Datum mit Uhrzeit an. In aktuellen Projekten sollte Cache-Control Priorität haben; Expires kann ergänzend für Abwärtskompatibilität gesetzt werden.

Wie aktiviert man Browser-Caching in WordPress?

In Plugins wie LiteSpeed Cache, WP Rocket oder W3 Total Cache kann die Option Browser Cache beziehungsweise Browser-Caching aktiviert werden. Zusätzlich lassen sich über .htaccess oder die Serverkonfiguration je nach Dateityp passende Cache-Control-Header setzen.

Werden Website-Updates bei langen Cache-Zeiten nicht angezeigt?

Wenn Sie eine CSS- oder JS-Datei unter demselben Dateinamen ändern, können einige Nutzer tatsächlich noch die alte Datei sehen. Verhindern lässt sich das durch Dateiversionierung, Hash-Dateinamen und bei CDN-Nutzung durch einen gezielten Purge.

Sollten Zahlungs- und Kundenbereichsseiten gecacht werden?

Nein. Seiten mit Zahlungsdaten, Warenkorb, Konto, Rechnungen oder Admin-Funktionen sollten sichere Header wie Cache-Control: no-store, private verwenden. Für Performance sollte niemals die Sicherheit personenbezogener Daten geopfert werden.