WebView2 takes 2-3 seconds to load any webapp

[Boscop]

Description
WebView2 takes 2-3 seconds to load any webapp (~2s on i9)

Version
Runtime:
I installed the latest WebView2 via the Evergreen Bootstrapper from here:
https://developer.microsoft.com/en-us/microsoft-edge/webview2/#download-section
OS: Win10

Repro Steps
E.g. build this todomvc project (or any other webapp): https://github.com/tauri-apps/smoke-tests/tree/dev/rust/yew/todomvc
Start it on Windows. Notice: The window shows up as blank for 2-3 seconds until the webapp appears. Every time.
If you build it on linux or mac where Tauri uses WebKitGTK/Webkit, it loads instantly. (Tauri does not slow this down on Windows, so it must be due to WebView2.)

AB#33649981

[Beanow]

Screencast.2021-05-15.00.55.51.mp4

Indeed, while this is recorded from a VM. It's present in multiple configurations. And reported by multiple users of Tauri.
Strangely though, it seems to be affected a lot by whether you have network connectivity.

[lingamy]

Hi @Boscop @Beanow, is this a web page you can navigate to from the edge browser? If so, can you try browsing to the page from edge browser and share your experience regarding the speed?

[tensor-programming]

@lingamy I can tell you outright that the speed is almost instant in the edge-chromium browser with any content, local and remote including the built content shared in these videos. In my experience, using the Edge browser as a runtime vs the evergreen runtime does decrease the loading time but it still not that great (1-3 seconds vs 5-6 seconds). Here is a video I took with the dev branch of the edge browser vs version 90.0.818.62 of the evergreen runtime.

webview.mp4

[lingamy]

@tensor-programming, thank you for the info. To confirm I understand correctly, you are saying:

• When using WebView evergreen runtime version 90.0.818.62, the app launch time is 5-6 seconds
• When using browser dev channel which is version 92, the app launch time is 1-3 seconds
• When browsing to the same context from the browser (version number?), the page loads instantly

Am I understand this correctly? We need to analyze trace file in order to further trouble shoot and figure out where time is spend. Could you please correct the corresponding trace of your scenario with WPR and share the trace with us? It will be great if you can collect 3 traces, one for each of the above scenario.

[tensor-programming]

@tensor-programming, thank you for the info. To confirm I understand correctly, you are saying:

• When using WebView evergreen runtime version 90.0.818.62, the app launch time is 5-6 seconds
• When using browser dev channel which is version 92, the app launch time is 1-3 seconds
• When browsing to the same context from the browser (version number?), the page loads instantly

Am I understand this correctly? We need to analyze trace file in order to further trouble shoot and figure out where time is spend. Could you please correct the corresponding trace of your scenario with WPR and share the trace with us? It will be great if you can collect 3 traces, one for each of the above scenario.

Yes all of this is correct.

I will generate a trace and get back to you.

[wusyong]

@lingamy Here the trace I recorded with WPR:
https://drive.google.com/file/d/18FhRmSTYvB5kxfX2v6yHHawFxs_b1pPQ/view?usp=sharing

• edge uses Edge to browse https://tauri.studio only
• dev-win32 uses Edge dev channel's webview2 to run Webview's win32 getting started example and browse https://tauri.studio
• dev-tauri uses Edge dev channel's webview2 to run Tauri api example
• evergreen-win32 uses Evergreen webview2 to run Webview's win32 getting started example and browse https://tauri.studio
• evergreen-tauri uses Evergreen webview2 to run Tauri api example

Edge dev channel's version is 92.0.891.1
Evergreen's version is 91.0.864.37

My experience is

• instant showing https://tauri.studio on edge browser
• 1~2 seconds for browsing https://tauri.studio on both dev channel & evergreen
• 2~4 seconds for Tauri API example on both dev channel & evergreen

[wusyong]

Btw I believe this benchmark is also from Microsoft dev?
It has a video recording comparing electron and webview2 with various frameworks.
You can see massive delay on webview2:
https://github.com/crossplatform-dev/xplat-benchmark/blob/main/recordings/electron-wv2-startup-time.mp4

[lingamy]

@wusyong , thank you for collecting the trace! Will you be able to collect a trace with the attached browser/edge profile in additional to the first level triage profile you have used? You need to update the file extension from .log to .wprp, I have to rename the file to use an extension supported by github in order to attach the file.

Browser_ETWOnly.log

[wusyong]

@lingamy I've updated the trace with the profile you provided.
https://drive.google.com/file/d/10HY_dN76fZ880bG8iudYT5UDY6gBIOBF/view?usp=sharing

[wusyong]

I got some updates that might fix or progress this issue.
I was updating a custom url scheme example that use WebResourceRequest with some workaround (because webveiw2 doesn't support custom url scheme yet)
And if the first path of the url doesn't have a dot, it will cause startup longer.
Perhaps it results in more error handling under lying?
But frankly speaking, url like http://localhost/ should be valid too.

[nothingismagick]

Do you think that this change (using the dot) speeds up webview2 to the point that it sometimes isn't fast enough to keep up with tauri? Because now we are experiencing a heisenboot (circa 50% of the time the resource can't load).

See: tauri-apps/tauri#2124

[lingamy]

@wusyong , looking at your notes at tauri-apps/tauri#2124, you commented that he best thing to do is still wait for WebView2Feedback#172. For WebView2Feedback#172, we just had a dev started to investigation this week, once we make enough progress, we will update the github issue.
We looked at your previous etl files, based on the trace, perf for Evergreen win32 and Evergreen -tauri are comparable.

• WebView2 creation time (Evergreen win32): 371.72ms
• WebView2 creation time (Evergreen tauri): 321.371ms
• Navigation time (Evergreen win32): 1220.17ms
• Navigation time (Evergreen tauri): 1165.39ms
  The other observation with the trace is navigation time is faster (512.35ms) in the browser than the app. However it's not clear that the endpoints used in the app and the browser are exactly the same one. Did you use the exact same URL when browsing from the edge browser and in the app?
  Also noticed in the trace is MsMpEng.exe (virus scan program) is very active during the trace and takes lots of CPU. But it impacts all traces.
  In order to do further analysis, we do need you to collect more etl files with more etl provider turned on. Please let me know whether you still want to do that now you seems to address the issue from your side. If so, I'll share the instruction. Thank you.

[wusyong]

@lingamy Thanks for the response! I do believe we should focus on #172. The need for custom URL/protocol is the root cause of all of these. This is a pretty common feature on other webview libraries like android, ios, and macOS etc. Putting more effort into that issue is more worth it imho.

[lingamy]

@wusyong , thanks for the confirmation! I'll go ahead to close this issue and use #172 to track the ask.

[nothingismagick]

By the way, this is still happening.

[imjamesb]

By the way, this has still not been fixed. Refreshing takes 2-3 seconds.

[ItsAtomTech]

I am using v108.0.1462.54 Webview2 runtime, and this issue are still occuring, only if connected to a network, and it also applies on loading iframes. It takes about 1 - 3 seconds to complete to show up the local html pages.

[mikewalker74]

I have the same behaviour in the Outlook desktop client with an Office Addin, Microsoft Insights or our own addin. I have pinned this down to the Windows Insider build as the same versions for everything on different base OS has indeed highlighted the performance bottleneck with a spinning loading icon before any comms to the web service.

For additional clarity the local environments on both when using Outlook Web Access are instant in both cases, this is pinned to WebView2 and the OS IMO

[Jimex]

I'm experiencing the same issue. I've tried loading the page multiple times, and in the first seven attempts, it worked well. However, after that, it started to slow down considerably. Please find the log below for further reference.

11:12:59.3123 [INFO] ===========================================================
11:12:59.3385 [INFO] ResourceRequest:http://localhost/index.html started
11:12:59.6685 [INFO] ResourceRequest:ended
11:12:59.8382 [INFO] ResourceRequest:http://localhost/668.jpeg started
11:12:59.8750 [INFO] ResourceRequest:ended
11:13:02.4084 [INFO] ===========================================================
11:13:02.4144 [INFO] ResourceRequest:http://localhost/index_1.html started
11:13:02.4144 [INFO] ResourceRequest:ended
11:13:02.4630 [INFO] ResourceRequest:http://localhost/646.jpeg started
11:13:02.4630 [INFO] ResourceRequest:ended
11:13:03.4293 [INFO] ===========================================================
11:13:03.4293 [INFO] ResourceRequest:http://localhost/index.html started
11:13:03.4487 [INFO] ResourceRequest:ended
11:13:03.4864 [INFO] ResourceRequest:http://localhost/668.jpeg started
11:13:03.4982 [INFO] ResourceRequest:ended
11:13:04.6223 [INFO] ===========================================================
11:13:04.6223 [INFO] ResourceRequest:http://localhost/index_1.html started
11:13:04.6316 [INFO] ResourceRequest:ended
11:13:04.6981 [INFO] ResourceRequest:http://localhost/646.jpeg started
11:13:04.7097 [INFO] ResourceRequest:ended
11:13:05.4472 [INFO] ===========================================================
11:13:05.4472 [INFO] ResourceRequest:http://localhost/index.html started
11:13:05.4615 [INFO] ResourceRequest:ended
11:13:05.4994 [INFO] ResourceRequest:http://localhost/668.jpeg started
11:13:05.5077 [INFO] ResourceRequest:ended
11:13:06.3185 [INFO] ===========================================================
11:13:06.3185 [INFO] ResourceRequest:http://localhost/index_1.html started
11:13:06.3364 [INFO] ResourceRequest:ended
11:13:06.3692 [INFO] ResourceRequest:http://localhost/646.jpeg started
11:13:06.3832 [INFO] ResourceRequest:ended
11:13:07.0535 [INFO] ===========================================================
11:13:07.0535 [INFO] ResourceRequest:http://localhost/index.html started
11:13:07.0717 [INFO] ResourceRequest:ended
11:13:07.1004 [INFO] ResourceRequest:http://localhost/668.jpeg started
11:13:07.1004 [INFO] ResourceRequest:ended
11:13:07.9199 [INFO] ===========================================================
11:13:07.9199 [INFO] ResourceRequest:http://localhost/index_1.html started
11:13:07.9282 [INFO] ResourceRequest:ended
11:13:07.9687 [INFO] ResourceRequest:http://localhost/646.jpeg started
11:13:07.9776 [INFO] ResourceRequest:ended
11:13:08.7546 [INFO] ===========================================================
11:13:08.7633 [INFO] ResourceRequest:http://localhost/index.html started
11:13:08.7730 [INFO] ResourceRequest:ended
11:13:10.7799 [INFO] ResourceRequest:http://localhost/668.jpeg started
11:13:10.7890 [INFO] ResourceRequest:ended
11:13:11.6610 [INFO] ===========================================================
11:13:11.6711 [INFO] ResourceRequest:http://localhost/index_1.html started
11:13:11.6853 [INFO] ResourceRequest:ended
11:13:13.6879 [INFO] ResourceRequest:http://localhost/646.jpeg started
11:13:13.6978 [INFO] ResourceRequest:ended

[ghord]

There is workaround for this 2s loading issue mentioned in #2381 (comment)