[RESOLVED] Recent Chrome Issue - cache

jeepin81

Has anyone else noticed that you need frequently clear your cache while developing and using Chrome to test. It seems every CSS, Javascript change I need to either hit F5 a handful of times or actually go in and clear my cache from history.

Previously I know it required at least a refresh but now it seems like it requires the entire cache to be cleared.

One thing I've been doing that works w/o having to clear cache is viewing src and either going to the CSS or Javascript doc opening in the browser and refreshing that and it seems to work.

Just curious if anyone has experienced this OR if there is fix out there. I'm having no luck doing a google search.

Thanks.

Derokorian

You should test with dev tools open, and then in the dev tools settings you can disable cache while the tools are open. I just refresh once to validate any given change.

jeepin81

Thanks for the reply....

I am familiar w/ the dev tools and disabling cache. I was just wondering if Chrome had an updated that was causing more wide spread issue. Now when we do updates to our site(s) not only our internal staff but customers running into cached versions. I just seems like the last 2 weeks we've noticed it being more prevalent.

Just thought I'd check to see if anyone else has noticed that.

Derokorian

Ah I didn't know you meant in general use. You had said "while developing" so I assumed you meant only when working locally or with a testing environment. The best way to deal with this for the end user (IMO) is to add a timestamp or md5 checksum to the file name, such that browsers see it as a new file. The timestamp would be the file's last modified date, or an md5 checksum which would just be over the contents of the file (so that it changes when the file changes).

dalecosp

I have more trouble personally with Firefox doing this. As for the real issue (now that it's open), server settings are likely to blame. Check for expires tags, Etags, etc., etc., in the headers being served by your WWW server(s). As Dero alludes to, we have ours set to allow caching of JS, CSS, and image files for one year. If we change anything JS/CSS wise, we then alter our HTML headers to add a unique query string to the resource(s), which causes all the end-user UA's to refetch them. Our email editors have to do this too whenever an image changes (like when the new magazine cover comes out the 1st of each month).

Some of our newer projects, we have a TS in the config file:

//config.php

$css_ts = "123456";

Then the headers don't have to be changed, just the config file:

//header.php

<link rel='stylesheet' type='text/css' src='/css/styles.css?<?php echo $css_ts; ?>'>

Derokorian

dalecosp;11058615 wrote:
//config.php

$css_ts = "123456";
Then the headers don't have to be changed, just the config file:
//header.php

<link rel='stylesheet' type='text/css' src='/css/styles.css?<?php echo $css_ts; ?>'>

My approach is similar, but more simplistic. My build script changes the url to include the md5 hash of the file.

sed -e "s/main-build.css/main-build.css?`md5sum resources/css/main-build.css |cut -f1 -d' '`/" -i resources/views/main.html

jeepin81

ahh! Thanks guys. That works great.