6

I have a static resource bundle (MIME Type: application/x-zip-compressed) which contains my .css and .js files.

I have noticed that when I upload a new version of the static resource it can take a long time before it can actually be downloaded (even with Incognito, clearing browser cache, disabling the cache with DevTools) from the community URL e.g.: /sfsites/c/resource/my-static-resource/css/my-stylesheet.css

Community will keep serving the old file for hours or even days before the new file finally appears. I observe this by comparing the output of the Community resource script/link URL to the actual file from the static resource bundle downloaded directly from the org.

This caching is causing problems for us because we cannot deploy script or styling fixes or new features with any predictability. In a hotfix scenario we would have to implement temporary measures while waiting for the actual hotfix (.css or .js fix) to finally propagate.

What is the reason for this server-side caching behavior? Is there any way I can force the Community to flush the server-side static resource cache?

NB: I have tried manually appending a query parameter to the link/script URL but it is ignored.

NB: The script / link tags are inserted in the Head Markup section of the Community site, so there is no support for URLFOR or similar.

Improve this question
2
  • 1
    Very likely this is an issue with the "Enable secure and persistent browser caching to improve performance" that you'll find in the Setup > Security > Session Settings editor (you actually have to scroll up the initial access to this page to find the caching definition). The problem with unchecking this is that it really can slow down page delivery and rendering. Also re-checking it too soon means that some users will still receive the old file.
    – Phil W
    Nov 9, 2020 at 8:02
  • That would make sense, but yeah this is a large website with thousands of users, so would be tricky to time the re-enablement, because leaving it off is not acceptable. Could this potentially be automated in a job or external script?
    – Andreas Warberg
    Nov 9, 2020 at 8:07

4 Answers 4

Reset to default
5

The naming pattern that URLFOR generates includes a timestamp that you can emulate:

/sfsites/c/resource/1604909594818/my-static-resource/css/my-stylesheet.css

On the client-side you can use new Date().getTime() to generate that number but that will avoid any caching at all (returning the latest version). But that is better than flipping the caching switch that affects all caching.

You can also query the StaticResource and use the actual LastModifiedDate timestamp in the URL and that will also give you caching too at the cost of a bit more complexity.

PS

Per Phil's comment below, I'd missed the point about the markup being static HTML. Unfortunately that leaves you having to move over to this Use Third-Party JavaScript Libraries pattern for the situation to be handled automatically. If you are OK with manually changing the timestamp you could also do that getting the value via the Developer Console using e.g.

StaticResource sr = [select LastModifiedDate from StaticResource where ...];
System.debug('>>> ' + sr.LastModifiedDate.getTime());
Improve this answer
8
  • When looking at the original posting I was slightly surprised not to see the timestamp part of the path but assumed communities handled the URL differently. If adopting this approach I'd say it is necessary to use the resource's LastModifiedDate, or are you saying that the timestamp value in the URL path is otherwise ignored and you'll get the file regardless? If so, then since the URL is being hard-coded in the head markup then it becomes a process of manually updating the head markup to change the arbitrary timestamp value in the URL when the file is changed.
    – Phil W
    Nov 9, 2020 at 8:22
  • Yeah my original answer isn't any help with no ability to add JavaScript...
    – Keith C
    Nov 9, 2020 at 8:40
  • Well, if they can get the LastModifiedDate for the static resource they can manually set that in the URL... and update the head markup each time...
    – Phil W
    Nov 9, 2020 at 8:50
  • 3
    Yes - though perhaps easy to forget.
    – Keith C
    Nov 9, 2020 at 8:53
  • 1
    Seems to me that you need to introduce an indirection for accessing the CSS. Are you able to make reference to a component, in the head markup, that itself gets the CSS filename using URLFOR or similar?
    – Phil W
    Nov 9, 2020 at 10:03
0

With the exception of Apex code, practically everything that's in your Site is bundled together and published as a single unit. That means that any changes you make to the site must be Published before they have any effect. You can, of course, use the Preview mode to test changes, but the public site itself is not affected by most changes until you're ready to commit to those changes.

Improve this answer
0

In case anyone else runs into this and is using static resources in a Formula, the following works like a charm:

IMAGE('/s/sfsites/c/resource/'+(TEXT(UNIXTIMESTAMP(NOW()))) +/Brands/'+Name+'.jpg', Name)

Improve this answer
0

Any news/changes on this issue? I have same problem, but I'm, actually doing and @import in the CSS overrides in the Experience Builder:

@import url('/s/sfsites/c/resource/xxx/css/styles.css');

So adding a timestamp is not a good option.

SF persistently loads old version of the CSS file. It does not have anything to do with Session Settings. My guess it's some sort of CDN that caches static resources. I'd really have a way to force-refresh that.

Also I think it has very little to do with the Experience Site itself and republishing the site in the builder does not influence that at all.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .