Does the shared "evergreen" WebView2 runtime mode have a shared pool of "msedgewebview2.exe" processes?

[noseratio]

I've recently done some spelunking on the new Teams 2.0 architecture, and then participated in an interesting Twitter discussion about the benefits of WebView2 vs Electron.

So I thought I'd ask it here. In the shared "evergreen" mode, does WV2 still create a separate msedgewebview2.exe OS process (or a set of processes) per each instance of WV2 control in the hosting app? Or, perhaps, it's somehow pooled, like per web site domain or by any other metrics?

I think, if done right, the pool of msedgewebview2.exe processes may yield some substantial memory saving benefits systemwide. I could compare that to Cloudflare Workers, where they run multiple V8 isolates per single V8 host OS-level process.

[champnic]

@noseratio Hey Andrew - Broadly speaking yes, the WebView2 instances in a host app will share most of the runtime processes (Browser process, Network process, GPU process, etc.) but have separate Renderer processes per WebView2. In Task Manager if you go to the Details tab and look at the Command Line for the various msedgewebview2.exe processes you can see the Type=... and Subtype=... args to see what kind of runtime process it is.

To be more specific, the process sharing will occur per user data folder. In a given app if different user data folders are specified in the environment creation then it will use completely separate runtime processes.

We're also looking into whether we can give the app some control over when WebView2's should be sharing renderer process vs creating new ones - the default right now is separate for security/sandboxing reasons, but apps that have control over the content that's displayed may feel comfortable grouping those together and gain the perf benefits of fewer processes.

[champnic]

In regards to that Twitter thread, I would also expect a similar performance profile between Electron and WebView2 - they're both built on the same Chromium internals mostly. Electron currently has some things that enable faster cross-process calls from the renderer to the app, and WebView2 has disk-space savings when using the shared Evergreen runtime binaries.

[noseratio]

@champnic, thanks for taking time to answer my questions, very helpful.

It'd be great to have more control over the WV2 process pool. Most likely the VW2 use will grow significantly in the near future, as more people migrate from the legacy IE11 WebOC. This area is where it could have substantial advantages compared to Electron (which is typical never shared).

I also wonder if there are any plans for a universal WV2 host shell (similar to electron.exe). I think JavaScript community might appreciate it, as an alternative to PWAs. With carefully designed security model, this could resemble IE11's "HTML applications" (aka mshta).

[champnic]

I agree a process pool is an interesting idea that has some nice perf implications, but I can quickly imagine the large amount of complexity this would incur (having settings in the shared processes still be "per-webview", for example) and potential security/privacy issues of sharing processes with other untrusted apps.

We've thought about a "WebView2 Window" concept before to simplify hosting, but not really a JS shell yet. For that we believe the community is mostly well-served by Electron and PWAs for now. While there could be some potential benefit and efficiencies if an app does need these capabilities, our other asks on WebView2 are currently higher priority.