Dieses Tutorial erklärt, wie Sie nginx so konfigurieren können, dass der Expires-HTTP-Header und die max-age-Direktive des Cache-Control-HTTP-Headers von statischen Dateien (wie Bilder, CSS- und Javascript-Dateien) auf ein Datum in der Zukunft gesetzt werden, damit diese Dateien werden von den Browsern Ihrer Besucher zwischengespeichert. Dies spart Bandbreite und lässt Ihre Website schneller erscheinen (wenn ein Benutzer Ihre Website zum zweiten Mal besucht, werden statische Dateien aus dem Browser-Cache geholt).
1 Vorbemerkung
Ich gehe davon aus, dass Sie ein funktionierendes Nginx-Setup haben, z. wie in dieser Anleitung gezeigt:Nginx mit PHP 7 und MySQL 5.7 (LEMP) unter Ubuntu 16.04 LTS installieren
2 Konfiguration von nginx
Der Expires-HTTP-Header kann mit Hilfe der Expires-Direktive gesetzt werden, die innerhalb von http {}, server {}, location {} oder einer if-Anweisung innerhalb eines location {}-Blocks platziert werden kann. Normalerweise verwenden Sie es in einem Standortblock für Ihre statischen Dateien, z. wie folgt:
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
} Im obigen Beispiel erhalten alle .jpg-, .jpeg-, .png-, .gif-, .ico-, .css- und .js-Dateien einen Expires-Header mit einem Datum, das 365 Tage in der Zukunft von der Zugriffszeit des Browsers liegt. Stellen Sie daher sicher, dass der location {}-Block wirklich nur statische Dateien enthält, die von Browsern zwischengespeichert werden können.
Laden Sie nginx nach Ihren Änderungen neu:
/etc/init.d/nginx reload
Sie können die folgenden Zeiteinstellungen mit der expires-Direktive verwenden:
- off bewirkt, dass die Expires- und Cache-Control-Header nicht geändert werden.
- epoch setzt den Expires-Header auf den 1. Januar 1970 00:00:01 GMT.
- max setzt den Expires-Header auf den 31. Dezember 2037 23:59:59 GMT und das Cache-Control-Maximalalter auf 10 Jahre.
- Eine Zeit ohne @-Präfix bedeutet eine Ablaufzeit relativ zur Zugriffszeit des Browsers. Es kann eine negative Zeit angegeben werden, die den Cache-Control-Header auf no-cache setzt. Beispiel:läuft am 10. Tag ab; oder läuft am 14w3d ab;
- Eine Zeit mit einem @-Präfix gibt einen absoluten Tagesablauf an, der entweder in der Form Hh oder Hh:Mm geschrieben wird, wobei H von 0 bis 24 und M von 0 bis 59 reicht. Beispiel:läuft ab @ 15:34;
Sie können die folgenden Zeiteinheiten verwenden:
- ms:Millisekunden
- s:Sekunden
- m:Minuten
- h:Stunden
- d:Tage
- w:Wochen
- M:Monate (30 Tage)
- y:Jahre (365 Tage)
Beispiele:1h30m für eine Stunde 30 Minuten, 1y6M für ein Jahr und sechs Monate.
Beachten Sie auch, dass Sie bei Verwendung eines weit in der Zukunft liegenden Expires-Headers den Dateinamen der Komponente ändern müssen, wenn sich die Komponente ändert. Daher ist es eine gute Idee, Ihre Dateien zu versionieren. Wenn Sie beispielsweise eine Datei javascript.js haben und diese ändern möchten, sollten Sie dem Dateinamen der geänderten Datei eine Versionsnummer hinzufügen (z. B. javascript-1.1.js), damit Browser sie herunterladen müssen. Wenn Sie den Dateinamen nicht ändern, laden Browser die (alte) Datei aus ihrem Cache.
Anstatt den Expires-Header auf die Zugriffszeit des Browsers zu stützen (z. B. expires 10d;), können Sie ihn auch auf das Änderungsdatum einer Datei basieren (bitte beachten Sie, dass dies nur für echte Dateien funktioniert, die auf der Festplatte gespeichert sind! ), indem Sie das modifizierte Schlüsselwort verwenden, das der Zeit vorangeht:
expires modified 10d;
3 Testen
Um zu testen, ob Ihre Konfiguration funktioniert, können Sie die Netzwerkanalysefunktion der Entwicklertools im Firefox-Browser verwenden und über Firefox auf eine statische Datei (z. B. ein Bild) zugreifen. In der Header-Ausgabe sollten Sie jetzt einen Expires-Header und einen Cache-Control-Header mit einer max-age-Anweisung sehen (max-age enthält einen Wert in Sekunden, z. B. 31536000 ist ein Jahr in der Zukunft):
4 Links
- nginx HttpHeadersModule:http://wiki.nginx.org/HttpHeadersModule
Über den Autor
Falko Timme ist Der Besitzer von 
Timme Hosting (ultraschnelles Nginx-Webhosting). Er ist der Hauptbetreuer von HowtoForge (seit 2005) und einer der Kernentwickler von ISPConfig (seit 2000). Er hat auch zum O'Reilly-Buch "Linux System Administration" beigetragen.