Very slow first navigation

[Urmeli0815]

Description A customer is experiencing a very long load time (22sec) of a webpage in WebView2 which is loaded in Edge almost instantly. We already reinstalled WebView2. Customer only uses MS Defender as Antimalware. As the UserData-Folder we use a subfolder in %LOCALAPPDATA%.

Version SDK: 109.0.1518.46 Runtime: 115.0.1901.203 Framework: Win32 OS: Win10

We managed to get an ETL trace of this problem. This trace shows this 22sec gap until the WebView2_FirstNavigationTime-Task is finished.

For me it looks like that the I/O of the process is very slow. Could it be related to the priority of the process? It seems that the process with "Very Low" priority has the highest IO Time:

I could provide the ETL trace in a PM if needed.

AB#45993244

[aluhrs13]

ETW trace would be useful - Can you send it to me? My email is my GitHub username without the 13 at microsoft.com.

[Urmeli0815]

@aluhrs13 I sent you a download link for the ETW trace.

A first guess from my side would be that it has something to do with the shader caching that slows down I/O for WV2.

[aluhrs13]

Thanks! I've filed a bug and attached the trace. We have a few people out of office, so it might be a bit before we can look deeply.

One possibly related question that I can't tell from the trace - Is the WV2's IsVisible property set to true or false?

[Urmeli0815]

Thanks @aluhrs13 !

Concerning your question about IsVisible: we wrap the WV2 control into an own container window (let's call it EdgeBrowserControl). When our app starts we first display a splash-screen and hide the EdgeBrowserControl until we get the "DOM content loaded" event from WV2. Then we show the EdgeBrowserControl. The code uses WM_SHOWWINDOW of EdgeBrowserControl to get notified when it is shown/hidden and then calls put_IsVisible on WV2 accordingly.

Could this cause the problem because WV2 slows down processing when it's not visible?

[aluhrs13]

WebView2's processes are set at a lower priority and QoS level so it's possible that's related.

[Urmeli0815]

I can add some more context.

When the customer experienced the problem with our app I saw a video where the loading of the page took ca. 2 minutes! In this case the WV2 is hidden until the DOMContentLoaded-Event is triggered.

To get an ETW-Trace I gave the customer a minimal WV2-TestApp which directly shows the WV2-Control and navigates to our company web-login, and there we "only" encountered the 22 sec delay as it can be seen in the trace.

According to the logs the customer has a Intel Iris Xe Graphics adapter.

[monica-ch]

@Urmeli0815 Can you check any of the solutions mentioned in thread #1818 fixing the issue for the customer? Additionally can we also get network trace

[Urmeli0815]

@monica-ch I'll try to get a network trace

[monica-ch]

@Urmeli0815 Did you get a chance to collect netlogs?

[Urmeli0815]

@monica-ch Yes, last week we got the logs. It can be seen that the delay is caused by the proxy detection mechanism, here the snippet with the timestamp:

t=   75 [st=   52]   -HOST_RESOLVER_MANAGER_REQUEST
t=   75 [st=   52]   +PAC_FILE_DECIDER_FETCH_PAC_SCRIPT  [dt=21129]
                      --> source = "WPAD DNS: http://wpad/wpad.dat"
t=21204 [st=21181]   -PAC_FILE_DECIDER_FETCH_PAC_SCRIPT
                      --> net_error = -118 (ERR_CONNECTION_TIMED_OUT)
t=21204 [st=21181] -PAC_FILE_DECIDER

NetworkCapture.zip

We will for now pass --winhttp-proxy-resolver to prevent these timeouts but I worry a little bit about this getting removed from Chromium in the future (https://bugs.chromium.org/p/chromium/issues/detail?id=644030).

What surprised me is that the delay doesn't happen when the customer navigates to the same page in the Edge browser. Do Edge and WebView2 behave differently concerning the default proxy settings?

[monica-ch]

@Urmeli0815 You can also use --use-system-proxy-resolver which also use WinHttp to resolve proxies instead of using Chromium's normal proxy.

There might be same issue for browser, but it isn't showing as it might has some cached content to show.

[ETPE]

I experienced the same issue with the browser having similar loading times, which was implemented in a game. It was due to the IPv6 address of the domain (AAAA Records) being used. Some servers and clients seem to have trouble handling it. As soon as only IPv4 was used, it worked without any issues. Alternatively, putting Cloudflare on top solves the problem too.

Somehow, the TTL settings were increased on the Domain even though they were set to be lower. So, you might need to wait longer after removing them if you're experiencing the same issue.

[emersonstori]

Facing the same problem with WebView2, on the local machine the performance is great but on a VM on the server it is very slow.