Statischer Content (Bilder, Javascripts, .HTML Files) können vom Client auch gecacht werden um die Daten nicht immer wieder zu übertragen. Das schont sowohl den Traffic als auch die Zeit, welche benötigt wird um die Seite zu rendern. Im Normalfall werden solche Inhalte ohne “Cache-Control” zum Client geschickt:
Dieses Verhalten kann man natürlich anpassen. Entweder direkt im IIS oder via Web.config
web.config Einstellungen
Da man nicht immer Zugriff auf den IIS hat, kann diese Einstellung ab IIS7 auch via der web.config erledigen (unter dem ASP.NET Development Server funktioniert diese Einstellung allerdings nicht, nur IIS7/IIS7.5 oder IIS Exoress) :
<system.webServer>
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
</staticContent>
</system.webServer>
Durch diese Einstellung wird dem Client über den HTTP Response Header mitgeteilt, dass diese Inhalte 30 Tage lang gültig sind. Wenn sich allerdings an den Daten häufiger etwas ändert, dann sollte man eher eine niedrigere Zeit nehmen – 1 Tag zum Beispiel ist schon mal ein Anfang ;).
Die komplette Dokumentation findet sich hier.
Nach der Änderung sieht die Response zum Beispiel so aus:
Cache-Control vs. Expire
Wer sich fragt, ob es nicht besser wäre die “Expire” Headers mitzuschicken (wie z.B. hier empfohlen), der sollte sich diesen Post genauer durchlesen.
Grundaussage: Eigentlich machen beide Header dasselbe, allerdings muss “Expire” eine genaue Datumsangabe enthalten. Solange man dies nicht über eine Library macht, sollte man lieber das einfachere “Cache-Control” nutzen, da man nur in Probleme läuft, wenn man die Datumsgrenze nicht anpasst.
Best Practices – auch von Yahoo empfehlen
Auch von Yahoo wird es empfohlen Expiration Headers bzw. Cache Control zu setzen. YSlow von Yahoo ist ein tolles Tool um “Performance-Flaschen-Hälse” zu finden.
