Performance-Ratgeber

Deutlich kürzere Ladezeiten für wiederkehrende Besucher

Browser-Caching speichert Dateien lokal beim Besucher – CSS, JavaScript, Bilder und Schriften müssen nicht bei jedem Besuch neu geladen werden. Das Ergebnis: Deutlich schnellere Ladezeiten und weniger Server-Last. In diesem Leitfaden zeigen wir Ihnen, wie Sie Browser-Caching nutzen und richtig konfigurieren.

Was ist Browser-Caching?

Wenn jemand Ihre Website besucht, lädt der Browser alle Ressourcen herunter: HTML, CSS, JavaScript, Bilder, Schriften usw. Bei Browser-Caching speichert der Browser diese Dateien lokal auf der Festplatte des Besuchers. Beim nächsten Besuch muss er sie nicht erneut vom Server laden – er nutzt einfach die gespeicherte Version.

❌ Ohne Caching

Erster Besuch: 2,5 MB Download, 3,2 Sekunden Ladezeit
Zweiter Besuch: 2,5 MB Download, 3,2 Sekunden Ladezeit
Dritter Besuch: 2,5 MB Download, 3,2 Sekunden Ladezeit

✅ Mit Caching

Erster Besuch: 2,5 MB Download, 3,2 Sekunden Ladezeit
Zweiter Besuch: 45 KB Download, 0,4 Sekunden Ladezeit
Dritter Besuch: 45 KB Download, 0,4 Sekunden Ladezeit

Der Unterschied ist enorm: Statt 2,5 MB müssen nur noch 45 KB geladen werden – das ist eine Reduzierung um 98%. Für wiederkehrende Besucher bedeutet das nahezu sofortige Ladezeiten.

Browser-Caching für Apache (.htaccess)

Die meisten Webhoster nutzen Apache als Webserver. Die Caching-Konfiguration erfolgt über die .htaccess-Datei im Root-Verzeichnis Ihrer Website. Falls die Datei noch nicht existiert, erstellen Sie sie einfach.

📄 .htaccess – Empfohlene Caching-Konfiguration

# Browser-Caching aktivieren
<IfModule mod_expires.c>
    ExpiresActive On

    # Standard-Cache: 1 Jahr für statische Assets
    ExpiresDefault "access plus 1 year"

    # HTML-Dateien: 1 Stunde (ändern sich häufig)
    ExpiresByType text/html "access plus 1 hour"

    # CSS und JavaScript: 1 Monat
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"

    # Bilder: 1 Jahr (ändern sich selten)
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"

    # Schriften: 1 Jahr
    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType application/font-woff "access plus 1 year"
    ExpiresByType application/font-woff2 "access plus 1 year"

    # Videos: 1 Jahr
    ExpiresByType video/mp4 "access plus 1 year"
    ExpiresByType video/webm "access plus 1 year"
</IfModule>

# Cache-Control Header setzen
<IfModule mod_headers.c>
    # Für statische Dateien: öffentlich cachebar
    <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|css|js|woff|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>

    # Für HTML: kürzerer Cache, Revalidierung nötig
    <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "public, max-age=3600, must-revalidate"
    </FilesMatch>
</IfModule>

Browser-Caching für Nginx

Wenn Ihr Webserver Nginx nutzt, erfolgt die Konfiguration in der Server-Block-Konfiguration. Diese befindet sich meist unter /etc/nginx/sites-available/.

⚙️ nginx.conf – Empfohlene Caching-Konfiguration

server {
    # ... Ihre anderen Einstellungen ...

    # HTML-Dateien: kurzer Cache
    location ~* \.html?$ {
        expires 1h;
        add_header Cache-Control "public, must-revalidate";
    }

    # CSS und JavaScript: mittlerer Cache
    location ~* \.(css|js)$ {
        expires 1M;
        add_header Cache-Control "public, immutable";
    }

    # Bilder: langer Cache
    location ~* \.(jpg|jpeg|png|gif|webp|svg|ico)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # Schriften: langer Cache
    location ~* \.(woff|woff2|ttf|otf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # Videos: langer Cache
    location ~* \.(mp4|webm|ogg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

Nach Änderungen an der Nginx-Konfiguration müssen Sie den Server neu laden:

🐧 Linux

sudo systemctl reload nginx
oder (bei älteren Systemen):
sudo service nginx reload

🪟 Windows

Navigieren Sie zum Nginx-Installationsverzeichnis und führen Sie aus:
nginx.exe -s reload

🍎 macOS

sudo nginx -s reload
oder bei Installation via Homebrew:
brew services restart nginx

Optimale Cache-Dauern für verschiedene Dateitypen

  • HTML (1 Stunde – 1 Tag): HTML-Dateien enthalten Ihre Inhalte und ändern sich häufig. Ein kurzer Cache stellt sicher, dass Besucher aktuelle Inhalte sehen.
  • CSS & JavaScript (1 Woche – 1 Monat): Stylesheets und Scripts ändern sich bei Updates. Ein mittlerer Cache ist ideal – kombiniert mit Cache-Busting für Deployments.
  • Bilder (6 Monate – 1 Jahr): Bilder ändern sich selten. Ein langer Cache reduziert Traffic erheblich. Neue Bilder bekommen meist neue Dateinamen.
  • Schriften (1 Jahr): Webfonts ändern sich praktisch nie. Maximaler Cache ist hier perfekt.
  • Videos (1 Jahr): Große Dateien, die sich selten ändern. Langer Cache spart enorm viel Bandbreite.
  • Favicon (1 Jahr): Das Website-Icon ändert sich extrem selten. Kann problemlos lange gecacht werden.

Cache-Busting: Updates trotz langem Cache

Problem: Sie haben CSS-Dateien mit 1-Jahr-Cache konfiguriert. Jetzt ändern Sie das Design – aber Besucher sehen die alte Version aus dem Cache. Die Lösung heißt Cache-Busting.

Methode 1: Versionsnummer im Dateinamen
Statt style.css nutzen Sie style.v2.css. Bei jedem Update erhöhen Sie die Versionsnummer. Der Browser sieht einen neuen Dateinamen und lädt die Datei neu.

Methode 2: Query-String-Parameter
Nutzen Sie style.css?v=1.2.3 in Ihrem HTML. Bei Updates ändern Sie die Versionsnummer. Vorsicht: Manche Proxy-Server cachen Dateien mit Query-Strings nicht.

Methode 3: Hash im Dateinamen (beste Lösung)
Build-Tools wie Webpack oder Vite generieren automatisch Dateinamen mit Content-Hash: style.a3f2b9c1.css. Ändert sich der Inhalt, ändert sich der Hash – perfektes Cache-Busting.

Caching testen: Funktioniert es wirklich?

Nach der Konfiguration sollten Sie testen, ob Caching wirklich aktiv ist. Es gibt mehrere Methoden:

🔧 Chrome DevTools

F12 drücken → Network-Tab → Seite neu laden → Spalte "Size" prüfen. Bei gecachten Dateien steht "(from disk cache)" oder "(from memory cache)".

🌐 GTmetrix

Online-Tool, das Ihre Caching-Header analysiert und konkrete Verbesserungsvorschläge gibt. Zeigt auch Cache-Dauer für jede Datei.

Zu GTmetrix →

⚡ PageSpeed Insights

Google prüft Ihre Cache-Richtlinien und warnt bei zu kurzen Cache-Dauern. Zeigt genau, welche Ressourcen optimiert werden sollten.

Zu PageSpeed Insights →

📡 RedBot

Detaillierter Header-Checker von der Internet Society. Analysiert alle Cache-Header und erklärt, was sie bedeuten.

Zu RedBot →

Cache-Control Header verstehen

Der Cache-Control-Header ist der moderne Standard für Caching-Anweisungen. Er ersetzt den älteren Expires-Header und bietet mehr Kontrolle.

  • public: Darf von Browser und Proxy-Servern gecacht werden. Ideal für statische Assets.
  • private: Nur im Browser cachen, nicht auf Proxys. Für personalisierte Inhalte.
  • max-age=31536000: Cache-Dauer in Sekunden (31536000 = 1 Jahr).
  • immutable: Die Datei ändert sich nie. Browser müssen nicht prüfen, ob eine neue Version existiert.
  • must-revalidate: Browser muss beim Server prüfen, ob die Datei noch aktuell ist, bevor er die Cache-Version nutzt.
  • no-cache: Darf gecacht werden, aber Browser muss vor Nutzung beim Server prüfen ob aktuell.
  • no-store: Niemals cachen. Für sensible Daten wie Bankdaten oder persönliche Informationen.

WordPress: Caching mit Plugins

Für WordPress-Websites gibt es mehrere Plugins, die Browser-Caching automatisch konfigurieren. Sie bieten grafische Oberflächen und übernehmen die .htaccess-Anpassungen für Sie.

  • WP Rocket (Premium): Das umfassendste Caching-Plugin. Automatische Konfiguration, Page-Caching, Browser-Caching, Minifizierung – alles aus einer Hand. Kostet ab 49€/Jahr.
  • W3 Total Cache (Kostenlos): Mächtiges kostenloses Plugin mit allen Features. Etwas komplexere Einrichtung, aber sehr effektiv.
  • WP Super Cache (Kostenlos): Einfaches Plugin von Automattic (WordPress-Entwickler). Weniger Features, dafür sehr zuverlässig und leicht zu konfigurieren.
  • LiteSpeed Cache (Kostenlos): Wenn Ihr Hoster LiteSpeed verwendet, ist dies das beste Plugin. Nutzt Server-Level-Caching für maximale Performance.

Häufig gestellte Fragen

Alles, was Sie wissen müssen

Funktioniert Browser-Caching nur für statische Dateien?

Nein, auch dynamische HTML-Seiten können gecacht werden. Allerdings sollten Sie hier kürzere Cache-Dauern wählen (z.B. 1 Stunde), damit Besucher aktuelle Inhalte sehen. Für personalisierte Inhalte (z.B. eingeloggte Benutzer) verwenden Sie "private" statt "public" im Cache-Control-Header.

Wie kann ich den Cache leeren, wenn ich Updates mache?

Sie können den Cache Ihrer Besucher nicht direkt leeren. Deshalb ist Cache-Busting wichtig: Ändern Sie den Dateinamen oder fügen Sie einen Versions-Parameter hinzu (z.B. style.css?v=2). Moderne Build-Tools wie Webpack machen das automatisch durch Hash-basierte Dateinamen.

Kann Caching zu Problemen führen?

Ja, wenn falsch konfiguriert. Häufigste Probleme: (1) Zu lange Cache-Dauern für HTML – Besucher sehen veraltete Inhalte. (2) Kein Cache-Busting – Updates werden nicht angezeigt. (3) Sensible Daten werden gecacht. Die Lösung: Unterschiedliche Cache-Dauern für verschiedene Dateitypen und Cache-Busting für Updates.

Wie viel Performance bringt Browser-Caching wirklich?

Für wiederkehrende Besucher enorm viel. Typischerweise reduziert sich die Ladezeit um 70-90%. Ein Erstbesucher profitiert nicht vom Browser-Cache, aber ab dem zweiten Besuch sind die Verbesserungen massiv. Bei Websites mit vielen Stammbesuchern (Blogs, Shops, Web-Apps) ist der Impact enorm.

Funktioniert die .htaccess-Konfiguration bei jedem Hoster?

Die Konfiguration funktioniert bei den meisten Hostern, die Apache verwenden. Voraussetzung: Die Module mod_expires und mod_headers müssen aktiviert sein (bei den meisten Hostern Standard). Bei Nginx müssen Sie die Server-Konfiguration anpassen. Shared-Hosting-Nutzer haben hier oft keinen Zugriff – nutzen Sie dann WordPress-Plugins.

Was ist der Unterschied zwischen Browser-Cache und Server-Cache?

Browser-Cache speichert Dateien beim Besucher lokal. Server-Cache speichert generierte HTML-Seiten auf dem Server, damit sie nicht bei jeder Anfrage neu generiert werden müssen. Idealerweise kombinieren Sie beides: Server-Cache für schnelle HTML-Generierung, Browser-Cache für wiederkehrende Besucher.

Sollte ich "immutable" für alle statischen Dateien nutzen?

Nur wenn Sie sicher sind, dass die Datei sich nie unter demselben Namen ändert. Bei versionierten Dateien (style.v2.css) oder Hash-basierten Namen (style.a3f2b9.css) ist "immutable" perfekt. Ohne Versionierung riskieren Sie, dass Besucher veraltete Versionen sehen. Nutzen Sie dann stattdessen "must-revalidate".

Über den Autor

Sascha Fix ist PHP-Entwickler und SEO-Spezialist aus Witzeeze in Schleswig-Holstein und betreut kleine und mittlere Unternehmen. Für Webentwicklung begeistert er sich seit 1999, hauptberuflich arbeitet er als Entwickler, nebenberuflich selbstständig. Mehr über mich.

Zuletzt aktualisiert:

🚀

Caching professionell einrichten lassen?

Ich konfiguriere Browser-Caching, Server-Caching und CDN für optimale Performance – und sorge dafür, dass Updates trotzdem problemlos funktionieren.

Sascha Fix, Webentwickler aus Witzeeze in Schleswig-Holstein

Direkter Draht

Lieber kurz fragen?

Ich bin Sascha Fix. Sagen Sie mir, worum es geht – das Erstgespräch ist kostenlos und unverbindlich.

Jetzt anfragen