Optimisation: Cache language files for Vorto properties

[PeteDuncanson]

This was an issue raised by Simone (@simonech) at Code Garden before my back office optimisation talk. I don't know all the details but I'm hoping this description will be enough to understand the issue and do some more digging.

It seems that when loading a Vorto property it makes a call to the server for a language file (or list of languages of some sort). This is done per property so if you have several properties they all make this same call even though its doubtful they would change between properties.

Suggest this is called once and cached and then reused client-side. This does raise the issue of how do you invalidate the cache but that could either be done via a timestamp (micro caching for just 5 seconds while everything loads might do it) or something a bit more robust...I think micro cache should do, it can reload it each page just not multiple times on a page.

This "could" be fixable via the work in this issue (http://issues.umbraco.org/issue/U4-11386) with Service workers but I think better to fix it at source.

[mattbrailsford]

Good spot. Maybe just loading it once per "editor load" would be ok. So when you open an editor it just gets requested once and all vorto probs on the front end use the same result.

I'll have a play when I have a sec though.

Thanks for reporting.

[simonech]

Could also be done using the "sync" mechanism the same way you sync open tabs and current tab.
You just load the languages once and sync its content to all other properties in the page.

Anyway this seems like a more generic issue. There should be a way to adopt the "service worker" approach (or something similar) to all API calls done in the backend, and just load them once per editor (even if reused in different properties). For example the configuration of doctypegrid editor, where every "cell" loads the overall configuration. But this is beyond the scope of this issue :)

[PeteDuncanson]

@simonech I logged that other issue with service workers we discussed here too btw: http://issues.umbraco.org/issue/U4-11388