Hey Henrik,

I've seen similar things when using DXC's Cloudflare CDN, particularly in China using the Find JS.

Maybe you can try the DXC Paas Portal's new CDN Cache purging feature?

I have done that and it does not help, still takes like forever a lot of times

Do you use dbLocalizationProvider for localizations in that solution?

Yes I do @sebbe

Okey, I think that is why it is happening.

As it turns out, epi's javascript is not 100% javascript. It goes through a controller that add translations to the JS file.

Example the datepicker file you have in the screenshot, /episerver/Shell/11.22.0/ClientResources/EPi/shell/ui/nls/en-us/episerver.shell.ui.resources.datepicker.js, it contains en-us. So the controller tries to get the translations from the db provider, but doesn't find it. So it goes to the next language which for me was "en" and then "en-GB" which it of course didn't find anything. So for one js file, it went to the database 3 times for every resource key in the js file.

That will say that we send alot of db calls for every js file for every resource as episerver doesn't cache the js file, but recreates the files every time so when 3-4 editors tries to use the edit mode, it get very slow. Some editors had to wait like 15min to just access edit mode.

I have a support case going against episerver and I think Valdis have some ideas too on how to fix it.

I fixed it in my solution with importing the whole dbLocalizationProvider and modified it to return "null" if the resource key contains "/" so my solution is quicker now

p.s. https://twitter.com/Sebbe91/status/1182005022747443200 where I discussed this with @valdis

Episerver doesn't consider this as a bug, so they filled it as a feature request to cache the js resources.

Thanks Sebbe I did not know that and this started when we  did an upgrade and also added the localizationprovider.

It is good to know and I will also talk to Valdis, or I will use xml-files for the episerver internal stuff.

just uninstall that crappy provider 

Yes Valdis, I will do that and I will absolutly not drink a couple of beers with the author of it in Miami, just to show how angry I am! ;-)

@Henrik, thanks for bringing this issue, we were also facing this and was under investigation

@Valdis,

Our client went live on the first week of October, it was behind the Azure front door that sends 503 after 30 seconds and there is no way to extend it so far,

Exact Above problem, In app insights, I could see thousands of dependent calls for a single JS, We have to restart the website twice last week as CMS Editors is completely unresponsive.

Any option other then uninstalling this great addon ;)

We've recently launched CMS + Commerce with dbLocalizationProvider on DXC with 5 languages en-AU, en-NZ, zh-Hans, zh-Hant, zh-HK. We've had no reported issues. But I'll be having a close look next week.

@darren which version of episerver? I think (without checking much) it may have happened after they upgraded the UI because we didn't have any problems before. Or ofc it is a change @valdis did, who knows? :)

who knows ;)

if anyone else interested - DM me, will send link to upcoming version. Just need to be sure that fix does not break somethingz in your projects.

@sebbe I think you're right! This CMS is 11.19.01 we have not yet updated to the new UI 11.21.x or 11.22.0 yet.

v5.7.6 will contain fix (verified) for this performance issue along with new UI colors as well. keep an eye on feed

We experience the same issue in Episerver 11.11.0.

Many dojo files take almost 30s to load in CMS making editor wait for minutes.

Do you suggest upgrading to v5.7.6 DbLocalizationProvider.Episerver solves this issue or just upgrading Episerver cms to 11.2 solves this issue.

@valdis

just to latest v6.x if you can and time allows

Thanks Valdis, I'll try and revert with result