When is site.min.js refreshed?

Questions
1

There is the V parameter on the site.min.js. (?v=random-string)
When is the site.min.js name changed so the browser wont read it from the cache?

Litium version: 6

2

The random string is the hash of the content of the file. Update the content of the file and the hash will be changed.

3

Is there a possibility that chrome and safari on Mac are caching it different?

On 3 deploys now it haven’t been a problem for me, but the client complains on some errors that have been resolved by refreshing the cache.

4

I did a test on what you said, and it indeed seems to update the name, so that works

5

I think all browsers are following the http-standard and caching files depend on the full url with query string.

If you have multiple servers it exists possibility that the html is downloaded from a server that have the file updated and a new hash, the second request to download the new css/js file will come to a server that not is updated and the content is downloaded to the browser and cached for wrong hash-query-parameter.

6

It’s for ByRydens on a single server where Litium is the host, so it shoulde’t be any special things done to that site. It’s strange but i guess we will leave it for now and do a closer look next release.

7

Do you see any instance where this could be a problem?

Our client wasen’t using the site the entire last week, opened it today and still had the cache problem. Started working after “ctrl + f5”.
Is it possible that the HTML gets cached? Because the v= parameter was indeed updated.

8

We got 1 more example now:
I have the same setup but not the problem

Windows, Chrome.

Open Byrydens.com => Old Hash
Ctrl + F5 => New hash

Any thoughts?

9

When loading your site the cache header for the stylesheet is not included. Do you have the caching in web.config commented out?

10

Hmm, i guess you mean this part?

 <location path="ui">
<system.web>
  <customErrors mode="Off" />
</system.web>
<system.webServer>
  <httpErrors>
    <remove statusCode="500" subStatusCode="-1" />
    <remove statusCode="404" subStatusCode="-1" />
  </httpErrors>
  <!-- 
enable static content cache to get better performance and pagespeed.
if static content in this folder is changed during the cache-time it 
is not reflected to the client before cache expires or user are doing 
a hard refresh.
-->
  <staticContent>
    <!--<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="06:00:00" />-->
  </staticContent>
</system.webServer>

Should i remove the comment on “clientCache”? I can’t recall us ever changing anything about this

11

@patric.forsgard any idea? Apperently more clients are experiencing it

12

If the clientCache is commented out, then the browser will use the ETag to decide if the information should be reused. if the clientCache is in use, the appropriate cache header is added to the request.

Not sure if enable that the file should be cached at the client will solve your issue either but I think it is worth a try.

13

I’m not exactly sure what you mean that i should try
i tried adding this

 <staticContent>
    <clientCache cacheControlMode="DisableCache" />
 </staticContent>

Then it should reload every time, mabye worth a try?

14

I have never tried DisableCache and that seams to be a performance killer… I think that you should remove comment on the default value <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="06:00:00" /> and the file will be cached in 6 hours and then a check is made to the server.

I haven’t hear about your problem from anyone else and I don’t have any answer for you why you site behave like this.

15

We found the issue now, I guess we can blame my lack of knowlage, I had added a parameter to “settings.addToCartUrl” in the SiteInfoController, and diden’t know that got cached until the websitesttings is update…

So now it works after republishing websitesettings.
I guess we should look into adding assembly version or something to that hash to.

16

Good that you find the reason.

Adding assembly version to the hash may get the file to reload at client when it not is needed.

17

Yes, thats true. But might be worth that extra reload to prevent this type of error to occure again

18

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.