I’ve made a few changes on one of my sites and they are showing immediately on Safari but not on Google Chrome. Does anyone know why this is? Apologies if this has been posted before but I haven’t got a clue why this is.
Clear your cache in Chrome.
thanks for the quick reply I suspected that may be it but was reluctant to clear the cache in Chrome as it means you start getting those annoying ‘this website uses cookies - click that you accept & understand this’ type messages all over again from regularly visited websites.
Try this instead of clearing your browser cache:
1 Like
Will, are you sure that is correct? I’ve alway interpreted 'cache busting links" on as action that will “bust” the cache… or “clear” the cache. This in not true? “Cache busting links” enabled respects the cache??? Is it me or is that verbiage counter intuitive if what you say is true…
For sanity (and because I’m using RW every day) I use a Cache Killer extension in Chrome and I leave it on. That way I get my “fresh” page/css/etc every time. But you have to remember also what’s happening with your site visitors.
Theoretically there are several levels of caching happening (both server side and client side) and different files and content are cached differently by different web browsers.
The links cache-busting refers to in RW are mostly your CSS and JS links. Ordinarily when you visit a webpage, the files will be stored in the users cache for a couple of hours or days, depending on their browser settings, or what the .htaccess file on the web server says. A typical link to a theme CSS file might look something like this:
rw_common/themes/aptenon/consolidated.css
Each time the user goes to the webpage, the cached file will be used. But if they CMD + R the page, the cached files are purged and will be called again new from the server. So we can refer to this as “soft caching” - files which stick around for a little while but are easy to reload.
Now when you enable ‘cache busting’ in RW, a query string gets appended to the file link like this:
rw_common/themes/aptenon/consolidated.css?rwcache=510515126
In Chrome, no matter how many times a user hits CMD + R, these cache-busting files will not be erased from a users cache and reloaded again. Indeed, the only way to reload these files is if one of these two events occurs:
- The query string 510515126 changes to something else, if RW changes the contents of the file on a republish (e.g. adding a new stack to a page)
- The browser cache is hard reset in the Chrome settings
Whether you think the terminology RW uses is correct or not is subjective. Chrome hangs onto cache-busted links more resiliently than Safari or Firefox does. But I see the same behavior all the time on other publishing platforms too which append date stamps or query strings onto site files.
For sites I’m updating or building in RW, I ALWAYS keep cache-busting links turned off. I only enable cache-busting links once a site is complete. It saves a lot of hassle that way.
3 Likes
Thanks for the detail Will. But according to your sentence as quoted here it sounds like it’s just the opposite of what I thought. I had my cache-busting turned ON thinking that “cache-busting” was in fact “busting” (clearing) the cache. Now I can go turn them all off. I very much appreciate the info though it was only the terminology that confused me.
Will… your products and input continue to be the “spark” that makes RW “sizzle!”
1 Like
Thanks for the explanation Will it makes much more sense to me now. I’ve turned off “Generate Cache-Busting Links” as I don’t need it on.
I think what confused me was since RW5 I’d never had a problem seeing changes in Chrome before. Presumably this is a RW7 feature that by default is turned on.
i can refresh Chrome but I don’t want people to visit my website after a while without seeing changes, cause the average internet user won’t think about that