Caching und Compressing Optimierung in der .htaccess
Heutzutage gehört es meiner Meinung nach zum guten Ton, Caching und Compressing Mechanismen zu nutzen, um die Trafficlast zu minimieren. Dies fördert einerseits den schnelleren Seitenaufbaue und andererseits auch die Lastsenkung auf Serverseite.
Beim Apache kann man via .htaccess verschiedene Möglichkeiten nutzen, um eben diese oben genannten Effekte zu erzielen. Ich selber nutze die folgende Konfiguartion auf allen Webseiten von mir:
# BEGIN Compress text files
<IfModule mod_deflate.c>
<FilesMatch "\.(css|js|x?html?|php)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
# END Compress text files
# BEGIN Expire headers
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 216000 seconds"
ExpiresByType application/x-javascript "access plus 216000 seconds"
ExpiresByType text/html "access plus 600 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
</IfModule>
# END Expire headers
# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
<FilesMatch "\\.(ico|jpe?g|png|gif|swf)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
<FilesMatch "\\.(css)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>
<FilesMatch "\\.(js)$">
Header set Cache-Control "max-age=216000, private"
</FilesMatch>
<FilesMatch "\\.(x?html?|php)$">
Header set Cache-Control "max-age=600, private, must-revalidate"
</FilesMatch>
</IfModule>
# END Cache-Control Headers
# BEGIN Turn ETags Off
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
FileETag None
# END Turn ETags Off
# BEGIN Remove Last-Modified Header
<IfModule mod_headers.c>
Header unset Last-Modified
</IfModule>
# END Remove Last-Modified Header |
Im ersten Teil werden Textdateien komprimiert, um sie schneller durch die Leitung schicken zu können, der Client packt diese Daten dann wieder aus und wertet sie entsprechend aus. Die Prozessorlast die durch ein- und auspacken der Daten sowohl beim Server als auch beim Client entsteht, kann getrost vernachlässigt werden. Das Komprimieren bringt hier mehr Gewinn als die wenige verlorene Prozessorzeit.
Im zweiten Teil werden die Cachingzeiten für verschiedene Dateien festgelegt. So kann man zum Beispiel das Favicon sehr lange cachen, HTML Seiten aber wesentlich kürzer. Die oben genannten Zeiten kann man natürlich beliebig verändern. Bei mir leisten sie bisher sehr gut Dienste und der Seitenaufbau geht deutlich flotter von
statten.
Im dritten Teil der .htaccess Datei werden die Verhalten der Caches festgelegt. Es wird bestimmt wo gecached werden soll, also zum Beispiel auf einem Proxyserver oder nicht oder lokal bei jedem User. Dadurch erzielt man eine noch bessere Lastverteilung auf seinen Seiten.
Im vierten und letzten Teil werden schließlich die sogenannten ETags deaktiviert und der Last-Modified-Header im HTTP Request/Response unterdrückt. Dies verschlankt den HTTP Header selber noch etwas. Beide Tags werden nicht umbedingt gebraucht und werden eh durch die oberen Einstellungen quasi ersetzt.
(via)
9 Comments
Ich würde fast alles unterschreiben. Nur dein letzter Absatz ist IMHO Blödsinn. Gerade die ETag- und Last-Modified-Header ermöglichen dem Client ein sinnvolles Caching und die “Ersparnis” der paar Bytes pro Request rechtfertigen IMHO nicht die Nachteile (eben schlechtes oder gar inkorrektes Caching von Inhalten), die dadurch entstehen.
Wenn sich eine Datei geändert hat, dann möchte ich nicht warten, bis der Client sie durch deine ExpiresByType Direktiven und Cache-Control-Header erzwungen künstlich lange Wartezeit erneut herunterlädt, sondern sofort. Und eben das leisten die ETag- und Last-Modified-Kopfzeilen.
Meiner Meinung nach wäre das aber doch doppelt gemoppelt: einerseits sagst du, du möchtest caching anbieten, andererseits soll sich der client aber nach den etags richten. ich finde eins von beiden ausreichend, aber das kann man ja je nach fall anpassen.
Woher weiß ich, dass diese Maßnahmen auch greifen? Du könntest bitte noch kurz erklären, wie Du überprüfst, dass auch funktionierst, was Du konfiguriert hast.
Wenn Du vorher gar keine Cachingmassnahmen ergriffen hast, dann merkst Du es meistens einfach durch aufrufen der Seite, sie reagiert schneller.
Prüfen kannst Du es zum Beispiel mit YSlow von Yahoo.
Hallo,
ich bin jetzt alles andere als ein Homepage-Profi, aber ich beiss mich durch wenn ich etwas wissen will :-)
Die letzten Tage hab ich viele viele Infoseiten zum Thema .htaccess und cache durchforstet und dabei eine ganze Menge gelesen (*Kopfbrumm*).
Das Beste was ich gefunden habe steht hier bei Google-Code:
http://code.google.com/speed/page-speed/docs/caching.html#LeverageBrowserCaching
Dort schreiben sie dass entweder mod_expires ODER nod_header UND ENTWEDER ETag ODER LastModified im Header haben sollte. So ganz ohne Versionshinweis (über Etag oder LastModified) kann doch gar nicht überprüft werden ob die Clientversion mit der Serverversion überinstimmt oder neu geladen werden muss. Wenn ich meinen gesammelten Browser-Cache durchsuche, sehe ich dass ziemlich alle Einträge sowohl Etag als auch Last Modified drinn haben (Redundanz..)
Gruss Stefan
Danke für den Hinweis :)
[...] v';var flattr_tag='htaccess,tipp,Trick,Webmaster'; Nachdem ich ja schon einige Tipps und Tricks zur Caching-Optimierung via .htacess gegeben habe, folgen nun einige allgemeine Dinge die sich immer gut in einer .htaccess machen [...]
[...] Steuerung über das Apache-Modul mod_headers.c für Caching-Anweisungen wird ebenso nicht auf jedem Server unterstützt bzw. bei manchen Hosting-Angeboten dem Nutzer nicht [...]
Hallo kann nur sagen hast ne top Seite hier…
Bis bald sky