HTAccess

Wer eine Webseite wie die MSXFAQ bei einem Shared Hoster betreibt, muss sich eigentlich um  nichts kümmen. Als dann aber Google wieder mal den Algorithmus für den Suchindex verändert hat, ist mir z.B. aufgefallen, dass meine Webseite etwas schneller sein könnte, wenn der Webserver "Caching" zu lassen würde. Zudem könnte ein komprimieren der Seite weitere Performancevorteile bringen. Bandbreite ist insbesondere auf Mobilgeräten nicht unbeschränkt vorhanden.

Auch andere Einstellungen lassen sich nur in der ".htaccess" vornehmen. Die ".htaccess" ist eine gesonders geschützte Systemdatei und wird vom Webserver nicht ausgeliefert. Sie können also nicht selbst direkt diese Datei anschauen. ich habe die wesentlichen Änderungen daher hier für mich und wen es sonst interessiert dokumentiert.

Defaults

Mein Hoster "1und1" hat natürlich schon eine ".htaccess" in dem Basisverzeichnis vorbereitet. Bei mir war dies:

# -FrontPage-
IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName msxfaq.de
AuthUserFile /homepages/xx/d99999999/htdocs/msxfaq/_vti_pvt/service.pwd
AuthGroupFile /homepages/xx/d99999999/htdocs/msxfaq/_vti_pvt/service.grp

Ich habe aber natürlich die Pfade auf die AUTH-Dateien zur Sicherheit unkenntlich gemacht. Die hier noch sichtbaren "Frontpage-Extensions" sind aber nicht mehr aktiv und die Inhalte der AUTH-Dateien daher auch nicht mehr da. Insofern ist das nicht mehr relevant.

Umleitung von "OFFICE365"

Ehe ich den Bereich "Cloud" angelegt hatte, lagen die meisten Seite unter dem Verzeichnis "Office 365". Damit alte Zugriffe auf diesen Bereich nicht ins Leere laufen, habe ich über die ".htaccess" hier eine Umleitung konfiguriert.

#redirect old directories and files to new files
RedirectMatch ^/office365/(.*)$ http://www.msxfaq.de/cloud/$1

Sie können es gerne ausprobieren. http://www.msxfaq.de/office365/index.htm wird direkt auf http://www.msxfaq.de/cloud/index.htm umgeleitet

Performance müssen

Es gibt einige Seiten, die eine Performance Analyse von Webseiten erlauben. An erster Stelle natürlich auch die Google Tools

Die meisten Einstellungen gibt natürlich der WebHoster vor, aber dass per Default z.B. Kompression und Caching bei 1und1 wohl abgeschaltet ist. ist nicht verständlich. Kompression kostet vielleicht CPU-Leistung und kann beim Shared Hosting ein Problem werden. dem Client aber das Caching zu verhindern, weil per Default keine Policy angegeben wird, ist aber unsinnig. Seit April 2015 werden solche "Fehler" z.B. bei Google wohl negativ betrachtet.

Also ist es an der Zeit etwas zu ändern und der Hebel ist die ".htaccess"-Datei beim Webhoster.

Caching

Zuerst habe ich mich dem Caching angenommen und über folgende Einstellung dafür gesorgt, dass die verschiedenen Dateitypen im Cache gehalten werden.

# Browsercache 
<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresByType image/ico "access 1 week"
 ExpiresByType image/x-icon "access 1 week"
 ExpiresByType text/css "access 1 week"
 ExpiresByType image/bmp "access 1 week"
 ExpiresByType image/gif "access 1 week"
 ExpiresByType image/jpg "access 1 week"
 ExpiresByType image/jpeg "access 1 week"
 ExpiresByType image/png "access 1 week"
 ExpiresByType application/javascript "access 1 week"
 ExpiresByType application/x-javascript "access 1 week"
 ExpiresByType application/x-shockwave-flash "access 1 week"
 ExpiresDefault "access 1 day"
</IfModule>

# BEGIN Cache-Control Headers 
<ifModule mod_headers.c> 
 <filesMatch "\.(ico|jpe?g|png|gif|swf|css)$"> 
 Header set Cache-Control "public" 
 </filesMatch> 
 <filesMatch "\.(js)$"> 
 Header set Cache-Control "private" 
 </filesMatch> 
 <filesMatch "\.(x?html?)$"> 
 Header set Cache-Control "private, must-revalidate" 
 </filesMatch> 
</ifModule> 
# END Cache-Control Headers

Diese Änderungen sind relativ schnell erfolgt. Kürzere Werte als 1 Woche für statiche Inhalte werden von Google als Fehler bewertet.

Kompression

Eine weitere Option teilt dem Webserver mit, dass er die Inhalte komprimieren kann, d.h. gerade HTML-Seiten können per GZIP sehr stark verkleinert werden

# gzip aktivieren
<IfModule mod_gzip.c>
 mod_gzip_on       Yes
 mod_gzip_dechunk  Yes
 mod_gzip_item_include file      \.(html?|txt|css|js|php|pl)$
 mod_gzip_item_include mime      ^text/.*
 mod_gzip_item_include mime      ^application/x-javascript.*
 mod_gzip_item_exclude mime      ^image/.*
 mod_gzip_item_exclude rspheader ^Content-Encoding:.gzip.
</IfModule>

Die Option sollten den Apache dazu bringen, Inhalte on the fly zu komprimieren, wenn der Webhoster das zulässt

Zeichensatz

Bislang habe ich den Zeichensatz einer HTML-Seite immer im HTML-Header angegeben.

oder in Textform:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 

Genau genommen ist das aber schon "zu spät", denn der Client hat die Datei ja schon geladen und "Interpretiert "diese. Wenn er dabei den falschen Zeichensatz nimmt, dann kann er diese Info gar nicht mehr lesen.

Entsprechend schreiben die verschiedene "Optimierungstools", dass man das besser schon im HTTP-Header macht und das kann man auch über den Webserver einstellen.

AddCharset UTF-8 .html

Da bei mir alle Seiten als UTF-8 gespeichert sind, ist dies bei mir die richtig Einstellung.

Weitere Links