Browser-Cache: Erzwingt Ihre HTML-Seite jedes Mal ein Neuladen?

Ohne Cache-Header lädt der Browser die gesamte Seite bei jedem Besuch neu herunter. Test #02 prüft Ihre Cache-Richtlinie in Sekunden.

Ihr Besucher lädt eine Seite. Er klickt einen Link, dann kommt er zurück. Ohne Cache-Header lädt der Browser den gesamten HTML-Code erneut herunter — gleicher Inhalt, gleiches Gewicht, gleiche Wartezeit. Jedes einzelne Mal.

Browser-Caching für HTML-Seiten ist eine der am meisten übersehenen Performance-Einstellungen. Alle cachen Bilder und CSS, aber das HTML-Dokument selbst? Die meisten WordPress-Seiten haben keine passende Cache-Richtlinie dafür.

Test #02 von Orilyt prüft die Cache-Header der HTML-Antwort. Nicht die Assets, nicht die Bilder — das Hauptdokument. Er überprüft Cache-Control, Expires, ETags und Last-Modified in einem Durchgang. Das Ergebnis zeigt, ob wiederkehrende Besucher ein schnelles Erlebnis oder einen redundanten Download bekommen.

Wie Browser-Caching für HTML funktioniert

Wenn ein Server eine HTML-Seite sendet, kann er Header einschließen, die dem Browser sagen, wie er sie cachen soll. Die Hauptakteure:

1. Cache-Control: max-age=N — sagt dem Browser, diese Seite N Sekunden lang aufzubewahren, ohne den Server erneut zu fragen. Ein max-age von 600 bedeutet 10 Minuten lokaler Cache
2. Cache-Control: s-maxage=N — wie max-age, aber für gemeinsame Caches (CDNs, Proxies). Hat Vorrang vor max-age, wenn vorhanden
3. Expires — ein älterer Header, der ein absolutes Datum/Uhrzeit für den Ablauf setzt. Funktioniert als Fallback, wenn Cache-Control fehlt
4. ETag und Last-Modified — Validatoren, die bedingte Anfragen ermöglichen. Statt neu herunterzuladen, fragt der Browser „hat sich das seit X geändert?" — wenn nicht, antwortet der Server mit 304 Not Modified (kein Body)

Cache-Control: no-store bedeutet, der Browser darf die Seite nie cachen. Cache-Control: no-cache bedeutet, er kann sie cachen, muss aber jedes Mal revalidieren. Beide lösen bei jedem Besuch eine Serveranfrage aus.

Für HTML-Seiten, die sich selten ändern (die meisten WordPress-Inhalte), ist ein max-age von 300–3600 Sekunden kombiniert mit ETags der goldene Mittelweg. Die Seite lädt sofort aus dem Cache, und die nächste Revalidierung ist leichtgewichtig.

Wie Orilyt Ihre Cache-Richtlinie bewertet

Test #02 liest die Antwort-Header und bewertet die Caching-Richtlinie:

1. Bewertung 90 — Cachefähig mit einer TTL über 300 Sekunden. Der Browser kann die Seite mindestens 5 Minuten lang aus seinem lokalen Cache bereitstellen. Bestes Ergebnis
2. Bewertung 70 — Cachefähig, aber die TTL ist kurz oder fehlt. Die Seite hat Cache-Header, aber das Frischefenster ist zu kurz, um nützlich zu sein
3. Bewertung 30 — Nicht cachefähig oder keine Cache-Header erkannt. Der Browser lädt die volle Seite bei jedem Besuch herunter. Das ist der Standard für die meisten unkonfigurierten Websites

Der Test erkennt auch die Anwesenheit von Validatoren (ETag, Last-Modified), ob die Seite als private markiert ist und ob Set-Cookie-Header das Caching beeinträchtigen.

Warum HTML-Caching oft fehlt

HTML-Cache ist weniger verbreitet als Asset-Caching wegen einer grundlegenden Spannung: Seiten können sich ändern. Aber es gibt klügere Lösungen als gar kein Caching:

1. WordPress-Standard — WordPress setzt keine Cache-Control-Header standardmäßig. Der Server (Apache, Nginx) muss separat konfiguriert werden, und die meisten Hosting-Panels tun das nicht
2. Dynamische Seiten mit Set-Cookie — wenn die Antwort Set-Cookie enthält, überspringen viele CDNs und Proxies das Caching. Login-Seiten, WooCommerce-Warenkörbe und personalisierte Inhalte lösen dies aus
3. no-store überall — einige Sicherheits-Plugins oder schlecht konfigurierte Caching-Plugins setzen no-store auf jeder Seite, einschließlich statischer Inhalte, die gecacht werden sollten
4. Fehlende ETag/Last-Modified — ohne Validatoren kann der Browser keine bedingten Anfragen stellen. Er verwendet entweder blind die gecachte Version oder lädt die ganze Seite herunter. Die meisten übersehen das

Die zentrale Erkenntnis: Für 90 % der WordPress-Seiten (Blog-Beiträge, Service-Seiten, Landing Pages) ist ein moderates max-age (300–600 s) mit ETag-Revalidierung sicher und effektiv. Der Browser bekommt einen schnellen Cache-Hit, und Änderungen verbreiten sich innerhalb von Minuten.

Cache-Richtlinie als Verkaufsargument

Für Freelancer und Agenturen ist eine fehlende Cache-Richtlinie ein starker Audit-Befund. Sie betrifft jeden wiederkehrenden Besucher — und wiederkehrende Besucher sind Ihr wertvollster Traffic.

Im Orilyt-Bericht generiert Test #02 eine strukturierte FIA-Empfehlung:

1. Fakt: „Kein Cache-Control- oder Expires-Header auf dem HTML-Dokument. Keine Caching-Richtlinie erkannt"
2. Auswirkung: „Jeder Besuch löst einen kompletten Seitendownload aus, auch für wiederkehrende Besucher. Verschwendung von Bandbreite und unnötige Ladezeit"
3. Aktion: „Cache-Control: public, max-age=600 zu HTML-Antworten hinzufügen. ETag-Validierung für intelligente Revalidierung einrichten"

Eine Bewertung von 30/100 bei der Cache-Richtlinie signalisiert eine Website, die nicht über die Grundlagen hinaus optimiert wurde. Es ist das Detail, das ein professionelles Audit von einem generischen „Ihre Website ist langsam"-Bericht unterscheidet.

Machen Sie wiederkehrende Besuche sofort

Browser-Caching für HTML ist keine Frage von aggressivem Caching oder Veralterungsrisiken. Es geht darum, dem Browser zu sagen: „Du kannst das ein paar Minuten behalten, und hier ist, wie du prüfen kannst, ob sich etwas geändert hat."

Test #02 prüft das in einem Durchgang. Keine manuelle Header-Inspektion, keine Terminal-Befehle — nur eine Bewertung (90, 70 oder 30) mit einer klaren Erklärung und einer umsetzbaren Korrektur.

Wenn Sie Kunden-Websites auditieren, ist die Cache-Richtlinie einer dieser Befunde, die mit bloßem Auge unsichtbar, aber in Daten messbar sind. Es ist die Art von Verbesserung, die einen echten Unterschied macht — und fast nichts kostet.