Browser cache inconsistency way too common

jfriend

The scene goes like this.

Customer: My site is all messed up in one browser, but not in the other.

Someone on dgrin: It works fine for me in both my browsers. Did you change anything recently?

Customer: It's really messed up for me - the whole gallery is blank. I didn't change anything. What do I do?

Customer: Is this what my customers are seeing?

Someone on dgrin: Try clearing your browser cache and then see if it works.

Customer: Did that. All fixed now - thanks.

Customer: Do my customers have to clear their browser cache?

Someone on dgrin: Hopefully not, but I'm not sure.

It seems like this is happening way too often these days. I get that a given Smugmug page is now a collection of a whole bunch of things (CSS stylesheets, JavaScript files, HTML pages, images, etc...) all with different cache lifetimes. And, clearly if two items are updated in a way that they have dependencies on each other, it's a recipe for problems until the cache lifetime causes both to be refreshed for everyone. Is this what is happening to so many people? It seems to me like the most likely cause.

But, Smugmug could take control of this and guarantee that this problem never happens if the included files (stylesheets, javascript files, etc...) were NEVER modified without also changing their filename and leaving the old one in place. Then a customer would always get a consistent version of the files. If the customer got an old version of the HTML file (not that likely because this is generated by Smugmug servers and not cached much if any), it would have a consistent set of old includes in it that would still work. If the customer got a new version of the HTML file, it would refer to the new include files which can't be out of date in the browser cache because they never previously existed. Wala, every customer sees a consistent set of changes right away and there can never be a version mismatch in the browser cache.

I do see that all included .js and .css files in my site do appear to have some sort of generated numbers in them except for the third party ones (quantserve, google-analytics, etc...). But, are the numbers getting changed everytime there's a change made to the file? If they were, I don't understand how anybody could ever get one of these browser cache problems.

Any ideas on why there are so many browser cache problems?

Andy

Hi John, thanks for posting your observation and question.

I'll make sure that the Sorcerers see this.

bwg

jfriend wrote:

Any ideas on why there are so many browser cache problems?

Just because clearing the cache (or force refreshing) appears to fix the problem doesn't necessarily mean its a cache problem.

For instance, if the site has problems for a minute or two, you may get no galleries. You refresh and refresh but the site is still having problems so you still see no galleries. By the time it takes you to clear your cache, the site is working fine and your perception is that clearing the cache must have fixed it. When in reality, going to get a cup of coffee would have had the same result.

I browse the site all day and have never had a 'cache problem' where clearing the cache magically made things better.

Unfortunately we have had more than our normal share of site glitches this week and that may be the root of all this.

jfriend

bigwebguy wrote:

Just because clearing the cache (or force refreshing) appears to fix the problem doesn't necessarily mean its a cache problem.

For instance, if the site has problems for a minute or two, you may get no galleries. You refresh and refresh but the site is still having problems so you still see no galleries. By the time it takes you to clear your cache, the site is working fine and your perception is that clearing the cache must have fixed it. When in reality, going to get a cup of coffee would have had the same result.

I browse the site all day and have never had a 'cache problem' where clearing the cache magically made things better.

Unfortunately we have had more than our normal share of site glitches this week and that may be the root of all this.

27 recommendations to clear the browser cache in the last month here on dgrin. Only a couple of those were the last few days. It often seems to work and it's a popular recommendation from those who offer advice on dgrin (because it frequently works). It feels to me like there's more to it than glitches from the last couple days. Ask your support heroes and dgrin moderators why they frequently recommend it. Ask them if it often works.

bwg

jfriend wrote:

27 recommendations to clear the browser cache in the last month here on dgrin. Only a couple of those were the last few days. It often seems to work and it's a popular recommendation from those who offer advice on dgrin (because it frequently works). It feels to me like there's more to it than glitches from the last couple days. Ask your support heroes and dgrin moderators why they frequently recommend it. Ask them if it often works.

All of our css, javascript and static images have specific filenames every time they are changed. CSS and static images are served from a CDN so the old files are available if requested. Javascript files are generated on the fly because the url you request isn't an actual file, but instructions on what files to bundle together and return. The timestamp on the end of the javascript request is for browser caching purposes only and is ignored when we get the request so there is no way of requesting an "old" javascript file. You will always get the most recent one.

So to answer your questions: Yes, we are taking control of this by making unique filenames and yes the filenames update with each change to the file.

You said it yourself, this should *guarantee* that we don't have cache problems.

It's difficult to say what exactly is happening without seeing the cached files from the affected users. If they did a shift + refresh in IE or Firefox (or simple refresh in safari since it ignores expires headers on every refresh) then clearing the cache shouldn't do a thing.

I can talk with our support heroes and ask them to gather more information when they handle a case like this.

jfriend

bigwebguy wrote:

All of our css, javascript and static images have specific filenames every time they are changed. CSS and static images are served from a CDN so the old files are available if requested. Javascript files are generated on the fly because the url you request isn't an actual file, but instructions on what files to bundle together and return. The timestamp on the end of the javascript request is for browser caching purposes only and is ignored when we get the request so there is no way of requesting an "old" javascript file. You will always get the most recent one.

So to answer your questions: Yes, we are taking control of this by making unique filenames and yes the filenames update with each change to the file.

You said it yourself, this should *guarantee* that we don't have cache problems.

It's difficult to say what exactly is happening without seeing the cached files from the affected users. If they did a shift + refresh in IE or Firefox (or simple refresh in safari since it ignores expires headers on every refresh) then clearing the cache shouldn't do a thing.

I can talk with our support heroes and ask them to gather more information when they handle a case like this.

It sounds like you're doing the right things. And that still leaves it a mystery as to why users occasionally have problems that clearing the cache appears to fix? I guess gathering more info on specific cases is the best idea. Thanks for listening.