How to Add Far Future Expires Headers to Your WordPress Site

Categories: Site Optimization Tips

Few weeks ago I wrote on how to optimize your WordPress site for better performance which has some tips and tricks on how to speed up a WordPress Site. I received a few requests to elaborate on some of the points as not all of them are obvious changes. In this article I have explained how you can add far future expiry header to your image, css and javascript files to speed up your site.

Adding expires headers do not affect the site load time for a first time visitor but you will be surprised how much the page load time decreases (faster page load) for subsequent page views/return visits from that visitor. Expires header specifies a time far enough in the future so that browsers won’t try to re-fetch images, CSS, javascript etc files that haven’t changed (this reduces the number of HTTP requests) and hence the performance improvement on subsequent page views.

If your server is Apache (most web servers), you can use the ‘ExpiresDefault’ directive to set an expiration date relative to the current date.

ExpiresDefault “access plus 2 months”

This sets the expiry date of the file 2 months into the future from the current time. The following values can be used to specify the time period:

years
months
weeks
days
hours
minutes
seconds

eg. ExpiresDefault “access plus 14 days”

To add expires header to the image, CSS, javascript files add the following to your .htaccess file
#Expire Header <FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$"> ExpiresDefault "access plus 2 hours" </FilesMatch>
or
# Expire images header ExpiresActive On ExpiresDefault A0 ExpiresByType image/gif A2592000 ExpiresByType image/png A2592000 ExpiresByType image/jpg A2592000 ExpiresByType image/jpeg A2592000 ExpiresByType image/ico A2592000 ExpiresByType text/css A2592000 ExpiresByType text/javascript A2592000
A2592000 means 1 month in the future (60*60*24*30=2592000)

Keep in mind that when you use expires header the files are cached in the browser until it expires so do not use this on files that changes frequently. If you change/update a file that has a far future expiry (eg. CSS or javascript files) then you should rename that file and use the renamed version so the browser doesn’t fetch the old file.

Removing ETags

According to Wikipedia – “An ETag (entity tag) is an HTTP response header returned by an HTTP/1.1 compliant web server used to determine change in content at a given URL. When a new HTTP response contains the same ETag as an older HTTP response, the contents are considered to be the same without further downloading.”

ETags were added to provide a mechanism for validating entities that is more flexible than the last-modified date but If you’re not taking advantage of the flexible validation model that ETags provide, it’s better to just remove the ETag altogether. Removing the ETag reduces the size of the HTTP headers in the response and subsequent requests thus improving site performance.

Add the following to your .htaccess file to remove ETags:

FileETag none

These tweaks can dramatically improve the performance of your site even though they are minor and doesn’t take that long to apply. I have seen a 20% speed improvement on my page loads just by adding these tweaks. My home page used to take around 5 seconds to load but then it dropped to around 3 seconds after these tweaks. Below is a screenshot of YSlow:

Tags: Blog Setup, Site Optimization Tips, Web development, web masters, Wordpress, WordPress Tweaks

Similar posts that you may like

#1 by Darren (Green Change) on July 29, 2009 - 11:49 pm

Thanks for this great tip! I just tried it on my blog, and it speeds up access time hugely.

I’m also going to keep an eye on next month’s bandwidth stats – I’m sure this is going to reduce my bandwidth usage a lot due to caching of all the images etc.

Keep the good stuff coming!
Darren (Green Change)´s last blog ..Sydney Water Restrictions Eased

#2 by Johan on September 3, 2009 - 6:15 am

This is a great article, but I wonder what happens if you set the expires header one month in the future and you do a plugin or wordpress update? Will the javascript, css, … only be updated one month in the future for the person who just visted your site for the first time?

#3 by admin on September 4, 2009 - 12:38 am

@Johan, Yep thats right… you can exclude the Javascript and CSS files from caching or rename them manually after every update so the browser fetches the new file. It’s a little bit of a pain but it may be wort it depending on how many javascript and CSS files you have.

#4 by John on September 12, 2009 - 6:48 pm

Thanks for the tip. I just tried this and my YSlow score improved from a C to a B. However, I’m still getting these:

There is 1 component with misconfigured ETags
- http://mysite.com/images/favicon.ico

There are 2 static components without a far-future expiration date.
- http://www.google-analytics.com/ga.js
- http://mysite.com/images/favicon.ico

Any ideas?

#5 by admin on September 12, 2009 - 9:16 pm

Hi John, Please note that YSlow doesn’t recognize a component to have a far-future expiration header unless the expiration is set 2 or more months into the future. So say for example you set the expiration to 6 hours then the components will be cached and your subsequent page loads will be fast but YSlow won’t give you the rating for it as it’s not more than 2 months which they consider to be a far-future.

#6 by John on September 12, 2009 - 10:38 pm

I changed it from 1 month to 2 months and it’s still not being recognized by YSlow. Any other suggestions?

#7 by admin on September 13, 2009 - 5:43 am

@John, try the following.. (Please make sure you always keep a backup copy of your .htaccess file when you update it just in case something goes wrong)

<ifmodule mod_expires.c>
<filesmatch “\.(ico|jpg|jpeg|png|gif|js|css|swf)$”>
ExpiresActive on
ExpiresDefault “access plus 6 months”
</filesmatch>
</ifmodule>

#8 by Bill Gram-Reefer on October 20, 2009 - 12:53 am

I have tried both default and the long list (expires headers above) to .htaccess in ~/public_html/blog/HERE

Yslow still does not see that expires headers have been added. While i thas seen other improvements. Is .htaccess in wrong dir?
Bill Gram-Reefer´s last blog ..Learn Brunch Basics, Oct 24

#9 by admin on October 20, 2009 - 2:53 am

Hi Bill, if Wordpress is installed on that directory then it looks like the correct directory. Please note that YSlow won’t recognize it unless the expiry is long into the future (eg. 6 months) but you will see the performance improvement as the browser will cache the files.

#10 by Car Insurance Guy on November 8, 2009 - 4:36 pm

Ah!!! at last I found what I was looking for. Somtimes it takes so much effort to find even tiny useful piece of information.
Nice post. Thanks

#11 by viettel on November 22, 2009 - 11:23 am

I don’t know about ETags, why you tell should remove it buy Yahoo guide tell should added it ?
viettel´s last blog ..Hướng dẫn sử dụng hệ thống tài khoản của thuê bao trả trước

#12 by admin on November 22, 2009 - 9:19 pm

The answer is already in the post… it only advises to remove ETags if you are not taking advantage of this (most site’s don’t)

#13 by Twigs on December 6, 2009 - 7:59 pm

applying expire headers is giving me internal 500 errors. I am also using wp-super cache.

#14 by Harry on December 21, 2009 - 1:28 am

Aha,..
Got it from u. Im using both of Google Page Speed and Yahoo!YSlow. Bad report for my weblog. I think this posting is very usefull for me. Thank for sharing.

Best Regard,
Harry
Harry´s last blog ..You keep Commenting, I Always Follow You

#15 by Jason on January 8, 2010 - 5:14 pm

Thanks for this! One thing to be aware of, the .htaccess code may copy with fancy quotes, so you’ll need to make them plain quotes before uploading.
Jason´s last blog ..This Week in This Week in Tech: Genius

#16 by Doug on January 11, 2010 - 1:44 am