YSlow & Google Page Speed .htaccess Code - How To Speed Up Your Website Tutorial

Lucky you! You just stumbled across a gold mine of htaccess goodies. Lets implement some of those initially seemingly meaningless phrases YSlow and Google Page Speed present you with. If you've been looking around Google for the optimal code to place into your htaccess to speed up your website then you have no doubt seen the wide range of different code snippets. Which ones are correct? Who is right? The problem is this is not simple html where any number of people can simply hand you the answer. No this is many times more difficult to get right, and therefore finding individuals and/or tutorials to dole out the correct answer is difficult to say the least - at least I found it to be.

When it comes to your htaccess you DO NOT want to just throw in the first piece of code you find on the web. Your htaccess has a tremendous influence on your website. It can do many powerful things but it can also easily break it. Nor is it forgiving. One wrong character in there and the whole site shows up blank or other. So, needless to say, I Googled around for weeks for this stuff, and asked many - many questions in forums, in order to come up with the leanest and best performing code. These snippets below work on Appache servers. If you find one doesn't work for you, call your host and see if the apache modules are turned on and/or enabled on your server. If not, ask them to turn it for you. I had to sit on the phone for two hours with my host to get my server configured correctly. Here is what I came up with...

Good htaccess resources I found helpful

Website performance, speed, and headers testing

Compress Your Files

No need to deflate images or media files (img, swf, video, mp3, ect) they are already compressed. Further compressing them can break them.

# Compress Files
<FilesMatch ".(js|css|html|php|xml)$">
SetOutputFilter DEFLATE
</FilesMatch>

Turn off ETags

Your site gets served faster with ETags off if your site is served from multiple servers. If not, or your on shared hosting, there is no benifit to turning them off. However, if off, they will cause no harm if your using some form of cache control as well.

# Turn off ETags
Header unset ETag
FileETag None

Cache Files

Google suggests to use Expires instead of Cache Control because of wider support. All online sources suggest caching for a long period of time frequently used and unfrequently updated media files. However, best practices say, cache files for no longer than one year. Many suggest caching CSS and JS files for long periods of time too. And most say cache HTML/PHP pages for 1 day or less. However, after giving this some thought, I came to the conclusion that if I'm going to cache my CSS and JS files then I needed to cache my HTML files too. 9 times out of 10, whenever I update one, I'm usually updating one of the others as well. Well when the user came back to my site, if one file extension was cached and one was not, they would very likely see some unstyled or missing elements (or un JS'ed). Plus caching your HTML dramatically speeds up loading. So instead of the full year of caching you will find elsewhere, I did a simple happy medium of 90 days for all files. Who are we kidding anyway? In my opinion, 90% of the time their cache will either be cleared or have run out of memory by the time 90 days comes around anyway.

# Cache Files 90 Days
<filesMatch ".(html|css|js|swf|pdf|xml|mp3|gif|jpg|png)$">
ExpiresActive On
ExpiresDefault "access plus 90 days"
Header append Cache-Control "public"
</filesMatch>

UTF-8 Encoding and English Language For All File Extensions

Ask Apache - Setting charset in htaccess is a good resourse on this. Yslow I think it was suggested I add UTF-8 encoding in my headers (FYI - not just in a meta tag in the head of the doc). Supposedly doing so allows the browser to start parsing the page immediately. Otherwise it has to wait until it reads the meta tag. However, it's a good idea to keep the meta tag in place for portability reasons and local testing. The first line is all thats needed for html/php pages to output the correct encoding and content type. But if you want to include the other extensions then use the second line as well. If memory (and common sense) serves me correct, ".html" is not needed on that second line, but everyone else uses it so I did too just incase. And I thought it was a good idea to add my default language too.

# UTF-8 encoding and English language for all file extensions
AddDefaultCharset utf-8
AddCharset utf-8 .html .css .js .xml
DefaultLanguage en-US

ADVERTISE HERE