In my current work we are hosting WebView2 EDGE browser inside WFP desktop application and we found out there is bunch of properties and command line switches you might consider switching on to have faster experience.
Worth to mention is that we are creating WebRTC application and some features are tied to the fact that out application triggered some warnings because it is using WebRTC features.
the --disable-features property
There is one property that you can just stuff with , separated values of features you want to turn off and this is our list :
- WebRtcHideLocalIpsWithMdns - Disables hiding of local IPs in WebRTC, this triggered UPD traffic on port 5353 and we don’t want it, but please read about this feature prior just enabling it here
- CalculateNativeWinOcclusion - will not throttle the browser window when it is not displayed, more on what happend here,
- AutofillServerCommunication - this will turn off communication to google servers where votes what user added to form is collected, local auto fill should still work. More on why and how,
- OptimizationHints - Chromium stops contacting the Optimization Guide servers entirely — no hint fetches, no model downloads, no telemetry uploads tied to it. A bit more on how here,
- MediaRouter - is the Chromium feature that powers the Media Router subsystem — the framework behind “Cast…”, screen sharing to external receivers, and tab/desktop mirroring to Chromecast / Miracast / smart TVs. In Edge it also drives the Cast/“Share to device” UI,
- EdgeFeedback - is a Microsoft Edge–specific Chromium feature that powers the “Send feedback / Report a problem” experience in Edge (and, by extension, in WebView2 since it shares the Edge codebase).
The whole command line switch to disable all mentioned features looks like this
--disable-features=WebRtcHideLocalIpsWithMdns,CalculateNativeWinOcclusion,AutofillServerCommunication,OptimizationHints,MediaRouter,EdgeFeedbackthe —autoplay-policy switch
—autoplay-policy=no-user-gesture-required configures Chromium’s autoplay policy — the rules that decide when a web page is allowed to start playing audio/video automatically without the user clicking, tapping, or otherwise interacting with the page first.
This is needed if you need to play something like notifications after loading of the page.
The command line switch for this setting is
--autoplay-policy=no-user-gesture-required—disable-background-timer-throttling
—disable-background-timer-throttling turns off Chromium’s background timer throttling mechanism — the optimization that slows down JavaScript timers in pages/tabs/windows that are considered “in the background”.
setTimeout / setInterval will not work as expected, all tied to how the browser want to save power of your device.
The command line switch for this setting is
--disable-background-timer-throttling—disable-renderer-backgrounding
—disable-renderer-backgrounding turns off Chromium’s renderer process backgrounding — the OS‑level priority/scheduling demotion that Chromium applies to renderer processes whose pages are no longer in the foreground.
In a nutshell, there will again be no slowdown but also nothing saved in terms of power on your machine.
The command line switch for this setting is
--disable-renderer-backgrounding—disable-component-update
—disable-component-update turns off Chromium’s Component Updater — the background subsystem that downloads and updates small, independently‑versioned modules (“components”) without updating the whole browser.
Side effects to be aware of
- Widevine DRM won’t self‑update. If the runtime shipped without it, or with an older version, protected video playback (Netflix/Spotify Web/etc.) may not work. For LOB content this is irrelevant.
- Safe Browsing local lists go stale. Combined with the fact that you’re also disabling related telemetry, this means SmartScreen/Safe Browsing protection becomes weaker over time. Acceptable for a controlled, single‑origin internal app; risky if you ever load arbitrary web content.
- CRLSet / CT log list go stale. Revoked certificates that get added after the runtime version you have installed won’t be flagged client‑side (TLS still validates normally; you just lose the extra revocation layer until the WebView2 runtime itself is updated).
- Origin trials / new web platform features that depend on a refreshed key list may stop working after a while.
- Subresource Filter rules don’t refresh — minor, you don’t rely on them in WebView2 anyway.
The command line switch for this setting is
--disable-component-update—disable-sync
—disable-sync turns off Chromium’s Sync subsystem — the service that synchronizes browser data (bookmarks, history, passwords, autofill, settings, open tabs, extensions, etc.) with a signed‑in account on Google’s servers (in Edge: a Microsoft account / Azure AD account against Microsoft’s sync endpoints).
This might not even kick in, if there is nothing like stored credentials that can be synced.
The command line switch for this setting is
--disable-sync—metrics-recording-only
—metrics-recording-only switches Chromium’s UMA (User Metrics Analysis) / metrics subsystem into a special mode where it continues to record metrics in‑memory locally, but never uploads them.
The command line switch for this setting is
--metrics-recording-only—disable-domain-reliability
Chromium ships with an embedded JSON config listing domains the browser should monitor — primarily Google properties in Chromium (*.google.com, *.youtube.com, .googleapis.com, etc.) and Microsoft properties in Edge (.microsoft.com, *.bing.com, *.office.com, *.live.com, etc.).
After turning off no beacon uploads ever happen — that whole class of background HTTPS POSTs disappears.
We switched this off just to be sure but after reading all the docs IMHO if your browser will never hit any of the mentioned pages then it will not have anything to upload.
The command line switch for this setting is
--disable-domain-reliabilityIf you happen to have more switches you use please share them with me by any means you pick, thank you 🫡☺️
Hope this helps.