Using localStorage/sessionStorage as a static data cache

[SteveTheTechie]

I would like pitch the possibility of CKE5 doing more with localStorage/sessionStorage to enhance performance. One possibility would be for caching static data such as language strings and error messages.

[Reinmar]

I've read about similar ideas, but I'm not sure that they apply to the case when all these data are loaded as a part of a JS file. Once a browser download a JS file requested by a page, that file is cached, so it's a very similar result as using localStorage (but faster, easier, etc.).

I think that using a localStorage is more useful if some data is retrieved using XHR, WebSockets, or if some processing is involved. Then the application needs to cache them manually.

Still, maybe someone will find some use case for localStorage in our situation, so I'm opening this ticket for further discussion.

[fredck]

Well, the example about language files may still fit. This would avoid even the eventual server ping query to check for file changes before taking it from cache (depending of caching settings, ofc).

There could be then some hardcoded/configuration way to invalidate the local storage when changes happen (new releases or new updates to files).

[SteveTheTechie]

Just saw this thread again. I did a Google search on this:
https://www.google.com/search?q=performance+comparison+local+storage+vs+browser+cache

http://www.mobify.com/blog/smartphone-localstorage-outperforms-browser-cache/
https://jsperf.com/localstorage-versus-browser-cache
http://jsperf.com/localstorage-versus-browser-cache-json-performance

If the above article is credible, it appears that local storage may be faster on mobile devices. If you are committed to better supporting mobile devices, I think this is worth keeping in mind.

[fredck]

Thanks for sharing @SteveTheTechie... I still find this idea very interesting. Even more now.

There is a good chance that, for a matter of simplicity, we'll not have anything around that at the very first stage, but I see it with good eyes having this enhancement introduced in the future.

[Reinmar]

localStorage space is relatively small, 5MB on most browsers, and it can only store string data. This is effectively halved because localStorage stores strings as double-byte characters (UTF-16).
localStorage reads and writes do block the rendering thread. Where possible reads/writes should be done after initial page rendering is complete. You may want to avoid operations that are likely to cause performance problems such as a very large numbers of operations (thousands or tens of thousands of reads or writes), as well as read/write operations larger than 1MB.

So not only reading from the local storage on page load would block its rendering, but also we need to parse the data. Plus, there's a chance that our cache is empty (because it's a first time load or the localStorage is full), so we'll need to do a round trip anyway. Taking all this into account I find it really hard to find a nice use case for us. It's a great thing for website devs, but not necessarily us.

[fredck]

I meant to say that we don't need to drop the idea because of negative assumptions, neither take it as good because of positive assumptions. It is an interesting suggestion that, if confirmed in the future, based on real experimentation, could be interesting to adopt.

I'm also advising not to spend further energy on this at this stage as we don't expect to have such kinds of enhancements introduced right now. Let's leave it for the future, whenever the proper time for it will come.

[Reinmar]

Cleaning up outdated discussions. See #186