Even if we move the back-end into a worker thread in bug 814257, we still have the problem that the UI really wants to know the list of existing accounts and the name of the Inbox (it could be localized) in order to present what appears to be a usable UI to the user. If we cache this information in the front-end, our UI can: - Determine if there are any accounts and go to the "hey, you're a new user, create an account!" page if appropriate. - If there are accounts, pick the default account and know its inbox's potentially-localized name so we can show the empty list of messages. In terms of where we cache, I think an IndexedDB database that (almost) never bumps its version number is probably the way to go. In the event we need to bump the version number, we would probably just have ourselves block and wait on the back-end to load and tell us the state of things. In terms of what we cache, the easiest/simplest thing to do is probably just to latch the wire representations of the accounts that are told to us and the (first) inbox for the primary account. When the real queries come in we would need special-case logic to merge what shows up with what we have present; it shouldn't be too bad. I don't think we would want to cache messages in the front-end because there are potentially way too many moving parts and duplication of logic. It's better to optimize the startup of the back-end instead of that. ALTERNATIVE 1: Don't do this and just make the back-end up start-up faster. ALTERNATIVE 2: Use a background process so the back-end is usually already started up.