Ich habe schon lange nach einer optimalen htaccess gesucht, die möglichst alle (viele) Empfehlungen von PageSpeed sauber umsetzt. Wo wenn nicht bei google wurde ich heute endlich fündig!

Ich habe von der originalen htaccess Datei eine wichtige Teilmenge für mich abgezwackt, die all meinen Seiten ein paar Flügel verliehen hat!

Vielleicht kann der ein oder andere damit ja auch was gescheites anfangen:

1. Komprimieren der Inhalte mit Deflate nach Dateityp

# Deflate Compression by FileType
<IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/plain
 AddOutputFilterByType DEFLATE text/html
 AddOutputFilterByType DEFLATE text/xml
 AddOutputFilterByType DEFLATE text/css
 AddOutputFilterByType DEFLATE text/javascript
 AddOutputFilterByType DEFLATE application/xml
 AddOutputFilterByType DEFLATE application/xhtml+xml
 AddOutputFilterByType DEFLATE application/rss+xml
 AddOutputFilterByType DEFLATE application/atom_xml
 AddOutputFilterByType DEFLATE application/javascript
 AddOutputFilterByType DEFLATE application/x-javascript
 AddOutputFilterByType DEFLATE application/x-shockwave-flash
</IfModule>

2. Komprimieren der Inhalte mit Deflate nach Dateiendungen. Zudem wir der Default Ablaufdatum (1 Monat) für das Caching der betroffenen Dateien gesetzt

# Deflate Compression by MimeType
<IfModule mod_deflate.c>
 <FilesMatch "\.(js|jpg|jpeg|gif|png|css|txt|html)$">
  ExpiresActive on
  ExpiresDefault "access plus 1 month"
  SetOutputFilter DEFLATE
 </FilesMatch>
</IfModule>

3. Komprimieren der Inhalte mit gzip:

# gzip Compression if availiable
<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 handler   ^cgi-script$
 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>

4. Cache Ablauf auf einen Monat setzen

# turns cache on for 1 month
<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresByType text/css "access plus 1 month"
 ExpiresByType text/javascript "access plus 1 month"
 ExpiresByType text/html "access plus 1 month"
 ExpiresByType application/javascript "access plus 1 month"
 ExpiresByType application/x-javascript "access plus 1 month"
 ExpiresByType application/xhtml-xml "access plus 600 seconds"
 ExpiresByType image/gif "access plus 1 month"
 ExpiresByType image/jpeg "access plus 1 month"
 ExpiresByType image/png "access plus 1 month"
 ExpiresByType image/x-icon "access plus 1 month"
</IfModule>
<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>

5. ETags deaktivieren

# Turn ETags Off
<ifmodule mod_headers.c>
 Header unset ETag
 Header unset Last-Modified
</ifmodule>
FileETag None

add following to your .htaccess file for enabling expire-header (expire apache module must be installed):

<IfModule mod_expires.c>
    # turn on the module for this directory
    ExpiresActive on
    # set default
    ExpiresDefault "access plus 24 hours"

    # cache common graphics
    ExpiresByType image/jpg "access plus 1 months"
    ExpiresByType image/gif "access plus 1 months"
    ExpiresByType image/jpeg "access plus 1 months"
    ExpiresByType image/png "access plus 1 months"

    # cache CSS
    ExpiresByType text/css "access plus 1 months"

    # cache other filetypes
    ExpiresByType text/javascript "access plus 1 months"
    ExpiresByType application/javascript "access plus 1 months"
    ExpiresByType application/x-shockwave-flash "access plus 1 months"
</IfModule>

[via]

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^Java
RewriteRule ^.*$ - [F]

by Peregrino Will Reign

• Sicherheit in WordPress: 10 Schritte zum Schutz des Admin-Bereichs
  Der Administrationsbereich einer Webanwendung ist das beliebteste Ziel der Angreifer und gehört somit besonders gut und wirksam geschützt. Nicht anders ist es in WordPress: Beim Initialisieren eines neuen Blog legt das System einen Administrationsnutzer mit einem durchaus sicheren Passwort an und sperrt den öffentlichen Zugang zum Bereich mit sämtlichen Einstellungen durch eine Login-Seite ab. Der Grundstein der Absicherung ist gelegt. Wir graben tiefer!
  Ein wirklich sehr lesenswerter Artikel! Die kleinen Tutorials sind sehr gut beschrieben und sind zudem gut mit Bildern illustriert.
• 11 Vital Tips and Hacks to Protect Your WordPress Admin Area
  As we continued to emphasize the security of your WordPress admin panel due to the recent attack on our site, we have compiled a fully detailed article that will highlight some of the must have security measures for your WordPress Admin Area.
  Dieser Artikel beinhaltet einige Schritte, die in dem oberen Artikel nicht aufgeführt sind

Schuld daran ist dann eine automatisch generierte .htaccess Datei im root der WP-Installation, die eine mod_rewrite Regel benutzt. Diese .htaccess Datei muss dann einfach per FTP (am Besten im internen domaingo Kundenmenü FTP Browser) gelöscht werden und das Blog ist wieder erreichbar!

Domaingo Nutzer könne also erst mit den Taripaketen “Power L” und “Power XL” das Apache Modul nutzen. Das Funktioniert seit Mai 2005.