For many mid and large-size iOS apps, startup time is delayed by 100+ milliseconds due to 1 or more WKWebViews being created. This is usually due to 0-1 WKWebViews being created by first-party code and 1 or more different SDKs each creating their own WKWebView (IIRC for them to use a JS VM). Although SDK providers may not be willing (or able) to defer the creation of these WKWebViews past startup, I'm hopeful that there are still some ways to improve WKWebView creation time, and that I can share those ideas with them. Note that much of the time spent under the hood for WKWebView initialization seems to be on process pool creation and management. My ideas so far are:
- Defer WKWebView creation. This is an obvious one, but I generally want to look past it because SDKs are often unwilling to defer work like that and because it's going to cause frame drops whenever it does get loaded, even if not at startup.
- Use a shared WKProcessPool. Many companies wouldn't care all that much about sharing the same process space, so this would be a nice win
- Create the WKProcessPool or the WKWebViewConfiguration on a background thread (is this even safe to do?)
- Use some sort of lower-level API to run a JS VM, e.g. through WebKit2 directly, if such a public and stable API exists.
- Use JavaScriptCore. However, for reasons I can't recall, I believe this was a non-starter. It may have been JavaScriptCore's far slower performance, or the need to render actual web content.
What are people's thoughts on these ideas? Does anyone have any other ideas?
