This plugin will allow you to easily add a “far future expiration” date for various static file types on your WordPress powered site to improve page load time (site speed).
Adding far future expiry header to your static resources (images, js, css) can improve the site speed. If you are using a caching plugin like W3 Total Cache then that plugin can do this for you too. However, I don’t use a caching plugin on all my sites (caching plugins are really good but for some sites/projects they add more hassle than its worth). This little plugin comes in handy in situations like that.
How The Plugin Works
This plugin will modify your .htaccess file by inserting code which will add expires headers for common static file types (this will tell the browser to cache those files).
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.
Download the Plugin
Download the WP Far Future Expiration Plugin
Installing the Far Future Expiry Plugin
Below are the steps for setting up the plugin.
- Go to the Add New plugins screen in your WordPress admin area
- Click the upload tab
- Browse for the plugin file (far-future-expiration.zip)
- Click Install Now and then activate the plugin
Usage Instruction
To use this plugin do the following:
- Ensure that the “mod_expires” module is enabled from your host’s main configuration file
- Check with your hosting provider or if you have access to the httpd.conf file the following line should be uncommented:
LoadModule expires_module modules/mod_expires.so - Enable the “Far Future Expiration” checkbox
- Set the number of days till expiry
- Select the file types you wish to enable the “far future expiration” feature for by using the checkboxes in the “File Types” section
NOTE: When you use this plugin, the file selected file types are cached in the browser until they expire. Therefore you should not use this on files that change frequently.
Enabling Gzip Compression
You can optionally enable gzip compression on your site using this plugin.
Gzip compression speeds up your site by compressing the page output and sending the compressed date to your visitors browser. When enabled, the plugin will do gzip compression if the visitor’s browser can handle it.
Plugin Compatibility
Works with the latest version of WordPress.
Plugin Requirement
Requires WordPress 3.5 or higher.
Check out our WordPress plugins page for more cool WordPress plugins.
It doesn’t store or save any IP address or personal info. It is GDPR compliant.
Hi,
It doesn’t seem that any personal information or IP addresses are being saved, however, could you please confirmt whether this plugin is GDPR compliant?
Thanks!
Jay
I Thought I cant Configure htaccess file but your post realy helps me. Thanks For The Amazing Information
@Joy, it only breaks when you enable a feature in the far future expiry plugin or it breaks even without this plugin? What kind of mobile device are you using for testing?
i really love your plugin, it works well and gives me 100% in page speed insights in google… however when i view my site in mobile it totally breaks… all are just letters and symbols.. can you help me?
@Harry, You can’t set expiry date of files hosted on an external server. Those external scripts will likely have the expiry date set by the server where it is hosted.
Hi, thanks for this. Most of the Yslow punishment always comes from external scripts, especially Google stuff (analytics, maps, G+ etc. Thanks Google…).
Is there any way to fix expiration dates from files from external servers? I know we can’t change these files, but can we tell browsers not to fetch new ones?
Cheers!
@James, I will try to add it to the WP repository.
Any plans to move this to the WP repo for plugins? It’s a great tool but this makes large-scale deployment just a tad more time-consuming. I also want to make sure I’ll always have the latest. Thanks!
@Vincent, yeah sure I will look into it.
Great plugin and thanks for the february update. Maybe you could add the possibility to cache font file, they are pretty heavy sometimes… Maybe a combo like “eot,ttf,woff” and another for “svg”… ?
Thanks!
@Bob, If you apply frequent CSS or JS tweaks to the site without changing the name of the script files then you probably don’t want to use far future expiry header on them. If you make changes to the files then empty the cache then it will be all good for new visitors but old visitors who already have a cached copy of the static file (which is not expired) will continue to see the old file (Thats basically what you are telling the browser to do by specifying far future expiry). If you have made a lot of changes to a CSS or JS file then the technique is to change the name of the script so it becomes a new static resource.
In what kinds of cases would one NOT want to select css, js, and flash? I’m asking because they’re de-selected by default.
If I enable them, and then make changes to a css or js file, I assume I’d need to empty all the caches (via W3 Total Cache), and then the FFE plugin would reset the expires period. Is this correct?
Thanks!
@Bob, There should be no conflict between the W3 Total Cache plugin and this one.
Does this plugin replicate any of the functionality of W3 Total Cache, or are there any potential conflicts? For example, one of the settings in Browser Cache of W3TC is ‘Set Expires Header’. Does that have any bearing on the use of your plugin?
Thanks!
@Joachim, How long did you use for the expiry value?
Hi
I tried installing this, set it up and got “Your .htaccess file was successfully modified”
However, when re-testing the site at pingdom, it doesn’t seem like the expiry date has been changed (Still get told to set a long expiry)
Ideas?
@Michael, Thank you for pointing that out. I have fixed this bug now. Please download v1.1 from this page and use it (the bug is fixed in the new version).
Hi!
Cool Plugin! Thanks for providing it!
But I think there is a little bug:
In the Administration the Plugin asks for the Time für the Expiration in Days.
If I look at the entry in the .htaccess it is “hours” (in my Example I had inputed “60 Days” in the Plugin Adminarea):
ExpiresDefault “access plus 60 hours”
I changed that to
ExpiresDefault “access plus 60 days”
Michael