why you should NOT be adjusting expires and cache-control headers for pagespeed insights and on your WordPress website

Intro To Expires Headers

Lots of people are onto using Google’s pagespeed insight and gtmetrix,

You’ll often get a results saying some URLs need an expires header. It will be dragging down your score, and you hate the big fat F … FAIL .. Loser score you get attributed.

But what do these expires headers do ?

They tell the browser its OK to use old versions of images, css, and javascript. If the browser has already seen those assets, then just keeping using the old version for X time.

It does NOT effect the first visit to the page. HUH !! surely that’s what those reports are about . Nope, has no effect first time, as how can you have a cached version on your PC already.

It does effect subsequent visits, like you come back tomorrow or next week. And it does effect the next page you click.

My recommendation is to have them set just enough for most users session on your WordPress site.

No effect on the actual WordPress pages

You can’t set the headers on the WordPress pages. The WordPress pages are set to expire immediately, one view, for one user, once.

The expires-headers are only for all the rest of the junk on the page, like images, css and js.

No effect on resource usage

The little assets like images, css and css use little or no resources from your WordPress hosting. It takes almost no time and CPU or memory for those assets to be sent to the user. So you’re not scaling your server more. It’s the big and slow in comparison WordPress pages that hog all the resources.

Developers hate them

If your site has regular changes, then have some users with different versions of files is going to cause headaches. Once a user has an asset, say a CSS file that has a month expiry set, and the developer changes it then the user is stuck with the old version.

This can be avoided with putting in a version number in the the resource url, like mystyle.css?ver=12

Advanced topics on Expires Headers

I think they are really a hangover from when the world wide web (yes, in the old days) had a lot more caching. At one staging ISPs and corporates ran large caching servers to speed up the web. Those large caches would hold those assets for longer, and it would help load time on your server.

If you have an ‘origin pull’ CDN like cloudflare these Expires-Headers are a double edged sword:

• Firstly, they dramatically help cloudflare. Cloudlfare acts as the PC when connecting to your website, and your expires headers could give it permission to cache the assets files (jss, css,images) for a month. This is great – because the CDN can do a better job.
• Secondly, it’s a real pain. If cloudflare get’s hold of an asset with 30 days expiring, it will keep hold of it, and give it out for 30 days. But if you update that asset CloudFlare won’t know, and it will continue to use the old asset.

OK, here’s what you need in .htaccess

 

<IfModule mod_expires.c>
# Enable expirations
ExpiresActive On 
# Default directive
ExpiresDefault "access plus 1 month"
# My favicon
ExpiresByType image/x-icon "access plus 1 month"
# Images
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
# CSS
ExpiresByType text/css "access plus 1 month"
# Javascript
ExpiresByType application/javascript "access plus 1 month"
</IfModule>

 

By Scott Farrell on October 24th, 2016 , Follow @scott_WordPress Tweet to @scott_WordPress