Javascript Files and Caching
You will notice that the performance of Dynamics CRM can be negatively affected when you have loads of Javascript codes embedded into the form of an entity. It is recommended that you take out the Javascript codes from the form and place them in a separate script file which can then be loaded in the form. This will cause the script to be downloaded only once and therefore improve performance when opening the page again. For some info on how to load javascript files in CRM, look at one of my previous posts.
There is one issue though when doing so. When the file has been changed on the server, it will still be cached on the client's machines. You can force Internet Explorer to check the Javascript file to see if it has been changed. One of my German colleagues (Christian Niss) has learned me that it is possible to modify the iis-cache settings for just the javascript file.
If you switch off "enable content expiration" and add a custom http header for the javascript file only:
Cache-Control: max-age=259200, must-revalidate
It should set client side caching of the file to three days (259200 sec), but each time the script is being used the browser must check if a more recent file is available on the server.
Good luck with caching!
11 comments:
I guess this is the "proper" way to do tihngs then! I posted an alternative solution to the same problem last year on my blog: http://thecrmgrid.wordpress.com/2007/10/22/prevent-caching-of-javascript-include-files-during-development/
Hi Greg,
Your solution does work perfectly as well for refreshing the javascript file. The main difference is that by using a random number as appendix to the url will cause the page to be reloaded everytime which will loose the advantage of not having to download the file.
For most implementations both solutions work fine, it's especially for the large javascript files for which I would recommend the solution above.
Ronald
Hi, I want to create CRM workflow which updates the case follow up date based on priority. I
f priority is high --> follow up date would be 24 hrs (1 day) after the case create date.
If priority is normal --> follow up date would be 72 hrs (1 day) after the case create date
Now the problem is that CRM includes (or counts) the weekends (Saturday/Sundays) while calculating the days after 3 days. I want to exclude these non business days to be counted in workflow.
Is there any ways we can avoid saturdays/sundays while dynamically setting date values in CRM 4.0 workflow? Any idea??
Thanks
Regards,
Mayank (mayank.pujara@iris.co.uk)
If I have special folder for all .js files then can I set client side caching to this folder and not to every .js file?
Hi Yuri,
I would expect that to work. Could you test and confirm?
This method has saved me about 2 seconds on a page load! Brilliant! But i cannot get the page to recognise that the js file has been updated without having to delete all cached files on the client side. IIS is setup as in the screen shot. Anything i could be missing?
Cheers
Anonymous wrote:
..But i cannot get the page to recognise that the js file has been updated without having to delete all cached files on the client side. IIS is setup as in the screen shot. Anything i could be missing?...
I have it also. Do we still need to delete all cache files?
(From same anonymous that posted "... But i cannot get the page to recognise that the js file has been updated")
I have found a revision of this method at http://www.maijspace.nl/crm-40-loading-custom-javascript-files-prototype which seems to have done the trick.
Enjoy!
I have a question regarding this caching though.
Is it supported by Microsoft ?
This is a difficult case for the level of supportness. Basically you're just using javascript to load an external page which should be ok. The page will not download to the outlook client though. You should copy the files to the outlook client manually and check how to get the link working on that client.
Furthermore, for an official statement on this you should contact the microsoft support desk.
If the response is marked as “public” then it can be cached, even if it has HTTP authentication associated with it, and even when the response status code isn’t normally cacheable.
JavaScript Training
Post a Comment