Issue metadata
Sign in to add a comment
|
Performance regression loading first page in WebView
Reported by
andrew.j...@gmail.com,
May 3 2018
|
||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. Start an Android app with a WebView 2. Load a URL into the WebView 3. Observe the time at which JavaScript execution begins What is the expected behavior? JavaScript execution start time does NOT regress from Chromium v65 What went wrong? I have observed a significant regression in when JavaScript execution begins between Chromium v65 and 66 (first noticed on 66.0.3359.106, still present in 66.0.3359.126) for the first page loaded in my app. By the end of page loading v66 seems to catch up, however the early content is delayed. Did this work before? Yes 65.0.3325.109 Does this work in other browsers? Yes Chrome version: 66.0.3359.126 Channel: stable OS Version: Flash Version: I work as an engineer at Amazon on an application utilizing a WebView. On Apr. 18th we noticed a performance regression between window.performance.timing.navigationStart and when the WebView begins to process JavaScript (and other standard metrics around that point such as window.performance.timing.domLoading) at the slower percentiles only. Analysis showed this to be due to the ~25% rollout of Chrome v66.0.3359.106 for Android with affected users regressing about 600-800ms. The trend stabilized around April 20th until Apr 24th when v66.0.3359.126 was rolled out and the overall metrics regressed again, this time at all percentiles, correlating strongly with the adoption curve of Chrome v66. The newer v66 revision (ending with .126) appeared to be slightly faster than the first version (ending with .106) but slower than v65. That said, it’s always a little murky trying to segment during an adoption period as users don’t update uniformly across the expected performance spectrum. This regression is limited to the first page loaded per Application Start. Note that it is not correlated to the first WebView created – we notice no regression from simply calling “new WebView(context)”. Subsequent page loads also do not show a regression. My app utilizes the WebViewClient#shouldInterceptRequest method to inject an alternate InputStream which is available earlier than letting Chromium make a network call for the main document when loading the first page during app start. We do this because it results in significant performance improvements for initial render – this is a feature we’ve had around for a while and it was tested to make a significant improvement in rendering times. I have not noticed any change in timing up to when shouldInterceptRequest is called, nor when onPageStarted is called. The stream returned however is instrumented and I have noticed a regression of ~1300ms in the time it takes Chromium to call read() for the first time on this stream. This leads to the regressions seen in starting JavaScript execution (as measured by simply recording the time at the top of the <head> in JavaScript), window.performance.timing.domLoading and other similar timing points near the start of page rendering. It does appear that by the end of the page load the timing metrics are roughly back to the Chrome v65 values. We try to optimize our page for initial render times rather than page end though. To rule out an issue related specifically to intercepted requests and reading of those streams I disabled this shouldInterceptRequest feature temporarily. While disabled we simply return null to shouldInterceptRequest and let Chromium load the page over the network. Metrics immediately regressed by the expected amounts (based on gains seen when first implementing this feature). I have since re-enabled the feature and seen metrics return to the values immediately preceding this test.
,
May 3 2018
Which device have you tried and failed to reproduce this locally? In your metrics, is there any way to split by other dimensions, like android OS version, or device? Might plausibly be related to crbug.com/837640 . No solution to that either yet..
,
May 3 2018
I tested locally on a Nexus 6P with OS 6.0.1. I split Prod metrics on OS version, app version, device model, country, network type, etc - the regression is consistent across all of these. The regression was seen on every major device I split on including Samsung, LG, Motorola and Pixel devices - definitely nothing unique to manufacturer or model. As a general rule of thumb, slower devices tended to regression more, even on a percentage basis. Faster devices still regressed, but by a smaller percent (and obviously absolute value). The 600-800ms figure was based on a slower percentile of the overall set of users; the fastest percentiles still regressed by ~100ms however. Looking at bug 837640 now.
,
May 3 2018
Seems like crbug.com/837640 could be related. Note that my regression only impacts the first page loaded - not sure with the other bug if they ever get to a second page. Given that I have had trouble reproducing this myself I can't comment on the effects of multiprocess mode. As for the Pixel 2, I do notice the regression there, however it does appear to be a smaller magnitude than other devices, even compared to other relatively fast devices. Given the number of changes going on at a time, it is within the realm of possibilities that the Pixel 2 (and Pixel 2 XL) are not showing the regression.
,
Jun 4 2018
M67 with fix for crbug.com/837640 is rolling out to stable in a low percentage right. Did your metrics start to come back down?
,
Jun 6 2018
,
Aug 1
andrew.janzen@ did you get a chance to confirm the fix?
,
Aug 2
Hi - we had a few other events occur simultaneously to your rollout that makes direct comparison at scale an issue without having polluted data. Some evidence points to M67 fixing the issue, however it is inconclusive.
,
Aug 2
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 3
> Some evidence points to M67 fixing the issue, however it is inconclusive. I'll optimistically close this (there's no obvious path forward unless we get more data). If you see metrics come back up on M67+, please ping this thread and we'll gladly reopen it. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rbyers@chromium.org
, May 3 2018Components: Mobile>WebView