Suggestions for WebView pre-loading and pre-rendering

[Igor Proskurin]

Hi WebView team,

In aGMM, we're experimenting with showing some of the features in the WebView and looking into ways to optimize "showing" latency. 

One thing we're looking at is pre-loading WebView HTML/JS/resources. This can be done either in the native code side with shouldInterceptRequest injections later OR in WebView using ServiceWorkers to prefetch the page.

From the information I found, the former isn't recommended since shouldInterceptRequest will limit us to 3 threads and slow down rendering significantly. The latter, on the other hand, requires keeping whole WebView in memory.

Another way, is to allocate WebView and pre-render everything in background (e.g. using loadUrl()).

If we have to keep WebView in memory anyway, this seems as a better direction.

So my questions are:

Is there best-practices that proved to perform best in this use-case?

Also, Is there a way to implement lazy rendering of WebView?

Any other suggestions, pointers are more than welcome!

Thank you,

Igor

[Bo Liu]

I don't know much about service workers or webview's implementation of service worker to comment on that, so I'll skip that part of the question. +tim who might be able to say more.

For the shouldInterceptRequest idea, aside from perf (which imo is not a big deal), mixing two network stacks is probably going to introduce a lot of edge cases

Webview does not have special features to pre-load stuff. The pre-render feature in chrome is implemented above the "content" layer, which is roughly where webview sits; pre-render is basically equivalent to create a webview and call loadUrl before displaying it. Imo this is the only legitimate thing you can do.

I don't understand the goal here though. Is it that the webview/page that's being pre-loaded may not actually be shown, so you want to minimize resources in that case?

This is the second time this question came up today. And I have no idea what "lazy rendering" means.

 

Any other suggestions, pointers are more than welcome!

Thank you,

Igor

--
You received this message because you are subscribed to the Google Groups "android-webview-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-webview-dev+unsubscribe...@chromium.org.
To post to this group, send email to android-webview-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/CAKuFF9TRnzo69x196K_98KKb31BQhp09pb0GeceTeHo%2B2LQrMQ%40mail.gmail.com.

[Igor Proskurin]

To add some more context: there's a button in our native app that is clicked 10% of the time. When the button is clicked, we show WebView with some interactive content. There are two goals

• Minimize time before the user sees the WebView content in 10% of cases
  
• In 90% when user doesn't click on the button, minimize resources (both memory allocated and network bytes received).

Re: lazy loading in my interpretation - loading all of the HTML/JS/Image resources in the background and postpone actual web page rendering in WebView until WebView is displayed.

[Bo Liu]

Have you analyzed how much of the delay is for network, and how much of it is due to other stuff? Eg the first webview created in an app is going to be more expensive than the second, so just creating and destroying a webview at some idle point will make the next one faster; it does take memory though.

But basically there is no lazy load feature.

For the "background webview" idea, you can try pauseTimers (which affects all webviews) or onPause while you load a page into a webview. Webview has has to do more work than necessary while in "background" for compatibility, but I think onPause should kill a bunch of activities.

To unsubscribe from this group and stop receiving emails from it, send an email to android-webview-dev+unsub...@chromium.org.

To post to this group, send email to android-webview-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/CAKuFF9SAQsPn%3D5GZ8r%3DHhDWknx%3Du-b%2BdcpPmkJqQLTLmRSoN9w%40mail.gmail.com.

[Igor Proskurin]

Thanks Bo, that's helpful. I'll play around with onPause() and pauseTimers().

Will loadUrl() still load stuff even after we call onPause() and pauseTimers() on WebView? If so, that's pretty much is lazy rendering I was looking for!

I'm running WebView on WiFi and network delay is a small portion of the latency I observe.

On Thu, Mar 16, 2017 at 2:33 PM, Bo Liu <bo...@chromium.org> wrote:

Have you analyzed how much of the delay is for network, and how much of it is due to other stuff? Eg the first webview created in an app is going to be more expensive than the second, so just creating and destroying a webview at some idle point will make the next one faster; it does take memory though.

But basically there is no lazy load feature.

For the "background webview" idea, you can try pauseTimers (which affects all webviews) or onPause while you load a page into a webview. Webview has has to do more work than necessary while in "background" for compatibility, but I think onPause should kill a bunch of activities.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/CAKuFF9SAQsPn%3D5GZ8r%3DHhDWknx%3Du-b%2BdcpPmkJqQLTLmRSoN9w%40mail.gmail.com.

[Bo Liu]

onPause is roughly equivalent to switching to another tab in chrome. pauseTimers is stopping setTimeout in js. Neither should affect page loading.