Cache Plugin and Leverage Browser Caching, Set Expires Header CDN Issue

Our tutorials on setup of W3 Total Cache Plugin and WP Super Cache Plugin are quite well known Cache Plugin guides and Frederick Townes, the key developer of W3 Total Cache Plugin has mentioned us in official note on WordPress Repository. Many thanks to Frederick and we have some responsibilities too, for an issue with CDN and both W3 Total Cache plugin and WP Super Cache plugin with CDN Sync Tool.

The user audience of W3 Total Cache plugin and WP Super Cache Plugin are not the same. W3 Total Cache plugin with proper settings can work brilliantly even on a shared server and almost all traditional servers, where as WP Super Cache plugin on Rackspace Cloud Sites with manual tweaks performs better. We can not expect that all users are either using Rackspace Cloud Sites or even a small percentage are doing so, not all users can tweak manually. An advanced user can test both and this article is for both the Plugins.

What is the Cache Plugin issue with Cache Plugin and Leverage Browser Caching, Set Expires Header

The problem on webpagetest.org is this :

And the reason you are seeing the F is here :

We are using Rackspace Cloud Files / Akamai CDN and it is a officially known fact that we can not set the expire header to more than 72 hours via control panel. This can be increased to 50 years with API. So quite obviously, it will seem to you that if W3 Total Cache plugin or WP Supercache Plugin + CDN Sync Tool changes the API, it will change the header.

No Cache Plugin can solve the problem

So apparently, W3 Total Cache plugin or CDN Snyc Tool (for WP super Cache plugin) can change their API call and you will get a nice A for leveraged Browser Caching and far set Expires Header. Come on. That is not so easy. I have worked for almost 3 months just to change it.  CDN Snyc Tool uses the API. So W3 Total Cache plugin does. There are two blogs who claims that they have successfully changed it. One of them are using Rackspace Cloud Files. You can test it, simply go to this question posted on WordPress W3 Total Cache Plugin support page and you will get the so called solution urls. At the time when we have tested, one blog uses no CDN and another uses Rackspace Cloud Files – but that page’s performance on webpagetest.org is exactly the same like us – F grade for Leverage Browser Caching, Set Expires Header. So either the person has not used his own method with that Cache Plugin he is using or it has failed.

We have tested over 100 websites who are using Rackspace Cloud Files or Akamai directly (like microsoft.com), Edge Cast (like gravatar.com), Google’s CDN, Page Speed specialist Sajal Kayan’s own blog (sajalkayan.com) – all have the same issue.

Inference

The highest time of expire header is 2.7 days for our website (Rackspace Cloud Files / Akamai CDN). From Control Panel it is set to 72 hours (that is the maximum). We can see the minimum expire is as small as 3 seconds. Now understand a big thing – if you change (somehow via API) it to 1 year, will this 3 seconds expire will change ? No. The highest will be of 1 year expire header but the minimum will be just few seconds, may be in 2 days. The range is now 1 second to 72 hours, that will be  1 second to 1 year. The range will change but the result will not much change simply because there will be some files with very low expire header.

What can be the solution

Look at this result from webpagetest.org. It is of us :

So, if we can change the “Failed” to our Maximum (2.4 – 2.7 days), it should show “WARNING” not “Failed”. This is happening because on the CDN the Edge servers automatically determine what should be the expire header – the longest set or the minimum. But we can not control via API. This automated calculation can not be changed. Instead, we have to think – what made those files to get the maximum possible TTL. We honestly found no logic after testing our 10+ domains with the same settings.