共用方式為

WebView2 應用程式的效能最佳實務

請採用以下做法來優化 WebView2 的啟動時間、記憶體、CPU 與網路使用。 使用這些工具和工作流程來排除效能問題。

將 Microsoft Edge WebView2 嵌入 Windows 應用程式，能實現現代化的網頁功能。 WebView2 採用 Edge 的多程序架構，因此每個控制項會啟動多個瀏覽器引擎程序，增加記憶體與啟動負擔。

詳細內容：

辨識效能瓶頸的類型

觀察表現緩慢的症狀，以判斷問題是否包括：

使用 Evergreen Runtime

  • 盡可能將應用程式部署為 Evergreen WebView2 執行環境。 Evergreen 執行環境會自動更新，以獲取最新的效能改進與安全修補。 保持 WebView2 執行環境的常青 (，也就是) 更新，讓你的應用程式具備未來防護。 使用固定版本可能會錯過近期的優化。

  • 如果你必須使用固定執行環境以維持離線或相容性，測試新建置後請定期更新。

  • 使用最新的 WebView2 預覽頻道 (Beta、Dev 或 Canary) 測試你的應用程式，以準備即將到來的變更。 許多過去的效能問題，如記憶體洩漏和高 CPU 使用率，在較新的 WebView2 執行時版本中已被解決。

如果 Microsoft Edge 和 WebView2 版本相符，且 Microsoft Edge 正在執行，所需的 WebView2 二進位檔已經在記憶體中，提升啟動效能。

另請參閱:

優化啟動效能

冷啟動 (冷啟動)

常見的效能瓶頸是建立 WebView2 控制項並首次導覽網頁的時間。 在冷啟動時，WebView2 必須啟動其程序和磁碟快取，這會帶來明顯的延遲 (，且會依硬體和內容複雜度) 而有所變化。

要優化啟動，請遵循以下最佳實務。

不要用 WebView2 來做初始介面

  • 若要渲染啟動畫面或簡單對話框，請使用輕量級的 XAML 或 Win32 螢幕，而非 WebView2。

  • 避免在 WebView2 上渲染啟動畫面或簡單對話，因為啟動成本高且資源爭用。 僅在顯示實際網頁內容時初始化 WebView2。

另請參閱:

優化使用者資料資料夾 (UDF) 位置

  • 為了效能，UDF 會放在預設的本地應用程式資料資料夾裡。 請參閱 管理使用者資料資料夾。

  • 避免使用慢速硬碟或網路共享;把資料放到更快的實體磁碟上。

避免重複的 WebView2 實例

規劃你的 UI 時，不要建立過多的 WebView2 控制項。

例如，若在多個網頁間切換，可能比刪除並重建 WebView2 控制項更快，重用單一 WebView2 並直接導向新網址。

另請參閱:

記憶體使用與程序管理

每個 WebView2 控制項會建立自己的程序集合，例如瀏覽器、渲染器和 GPU。 隨著更多 WebView2 實例的建立，資源使用量通常會增加，每個實例會執行自己的瀏覽器程序集合。

WebView2 實例會根據網頁內容的複雜度及其所建立的瀏覽器處理來使用記憶體。 執行多個 WebView2 控制項會增加系統記憶體負擔。

以下是管理並減少記憶體佔用的最佳實務。

分享 WebView2 環境

  • 為了節省記憶體，可以在應用程式中所有 WebView2 控制項共用一個 CoreWebView2Environment ，確保共享參數一致。

  • 在分頁介面中重複使用同一環境，而不是建立多個環境。

另請參閱:

使用應用程式層級的流程共享

  • 如果可行，使用應用程式層級的流程共享。

    多個應用程式可以透過使用相同的使用者資料資料夾和 CoreWebView2EnvironmentOptions來共享瀏覽器程序。 這減少了記憶體使用，但因可能存在跨應用程式干擾，需謹慎管理設定檔並進行全面測試。

    請記住，當 UDF) 共享使用者資料資料夾 (，底層資料 (如 cookie、快取和資料庫) 會在不同應用程式間共享。

另請參閱:

避免使用大型宿主物件

如果你用 AddHostObjectToScript 來將 .NET 物件暴露給網頁，要注意這些物件在記憶體中所保留的內容。 只要腳本上下文持續存在，整個物件就有效被引用，這可以防止 .NET 端對該物件的垃圾回收。

如果只需要一小部分來寫腳本，不要暴露一個很大的物件圖。 偏好建立狹義且特定用途的主機物件，而非通過完整的應用程式模型。 例如：

  • 只公開頁面真正需要的操作和資料。 例如，曝光一個 FileService 物件，而不是整個 AppContext。

  • 將複雜物件包裹在小型外牆後面，以避免無意中暴露出深層物件階層。

  • 對於集合，提供篩選或分頁結果，而非公開完整資料結構。

當需要該物件的頁面消失時，呼叫 CoreWebView2.RemoveHostObjectFromScript 釋放物件圖。 例如，如果你離開使用主機物件的頁面，請移除該物件，以避免它在幕後持續存在。

另請參閱:

防止記憶體洩漏

  • 在丟棄 WebView2 物件前，請移除原生事件處理器，以避免參考週期與洩漏。

  • 避免強烈引用 WebView2 的關閉;必要時使用弱參考。

  • 當 WebView2 物件不再需要時，呼叫 WebView2.Dispose() 釋放它們。

另請參閱:

使用記憶體管理 API

  • 在非啟用的 WebViews 上設定 MemoryUsageTargetLevel = CoreWebView2MemoryUsageTargetLevel.Low 以減少記憶體使用——這可能會促使瀏覽器引擎丟棄快取資料或將記憶體交換到磁碟。 當 WebView2 實例再次啟用時，將目標層級還原為 Normal，以達到完整效能。 請參閱 WebView2 API 概述中的記憶體使用目標。

  • 如果 WebView2 實例一段時間內不會被使用，請呼叫 CoreWebView2.TrySuspendAsync() 暫停渲染程序，這會暫停腳本並進一步降低資源使用。 需要時再繼續。Resume() 這些 Try 行動是盡力而為。 請參閱 WebView2 API 概述中的效能與除錯。

優化網頁內容

定期刷新 WebView2

CPU 與渲染效能

WebView2 將網頁內容渲染卸載給 Edge 使用的瀏覽器引擎，因此效能特性就像在 Edge 裡運行網站一樣。

以下做法確保 CPU 使用效率與渲染流暢。

啟用硬體加速

  • 除非你在排除問題時，否則不要停用 WebView2 用 GPU 來用旗標) 渲染 (disable-gpu 。

    預設情況下，WebView2 使用 GPU 來渲染。 WebView2 對 GPU 的使用對效能至關重要。 必須分配 GPU 驅動程式和額外的緩衝區，這會需要額外的記憶體。

另請參閱

簡化網頁內容

透過以下技術優化頁面：

  • 限制大量 JavaScript。

  • 讓任務減速或減速。

  • 動畫用 CSS (而不是 JavaScript) 。

  • 拆分長腳本以保持介面反應靈敏。

  • 使用 Microsoft Edge DevTools 來識別瓶頸。

  • 採用典型的網頁優化：避免過度的版面混亂，也就是腳本交替讀取和寫入 DOM 屬性，導致多次重排。

另請參閱:

減少不必要的溝通

  • 減少主機應用程式與 WebView2 中託管的網頁內容之間不必要的通訊。 這樣可以避免過度的進程間通訊，以及隨之而來的開銷。 參見 原生與網頁程式碼的互通性。

  • 盡可能使用批次訊息，因為頻繁傳遞訊息會增加 CPU 使用率。

管理程序優先權

  • 如果應用程式本身工作負載很重，請謹慎分配執行緒優先順序，避免導致 WebView2 執行緒無法使用。 WebView2 會建立獨立的渲染程序。

另請參閱:

測試真實情境

  • 在目標硬體上測試你的實際內容，使用 Microsoft Edge DevTools 來發現並優化效能問題。

另請參閱:

網路與載入效能

網路延遲與頻寬有限可能導致使用者感知的效能問題，尤其是在以 WebView2 控制項載入網頁內容時。

以下最佳實務與一般網頁開發有重疊。

利用快取與服務人員

WebView2 支援瀏覽器快取。

  • 使用快取和服務人員。

  • 提供適當的快取標頭，使重複的資源請求使用快取版本。

  • 考慮使用服務工作者（service worker）來預先快取靜態檔案，以便離線存取;但要監控快取大小。

另請參閱:

檢查網路瓶頸

使用 DevTools Network 工具來識別 WebView2 中較慢的資源;請參閱 檢查網路活動。

根據需要，優化或非同步載入較慢的第三方腳本或 API。

減少初始有效載荷

提升感知速度：

  • 保持初始有效載荷輕量。 一開始偏好傳送靜態 HTML，因為它通常載入、解析和渲染速度比 JavaScript 快。 一開始使用 JavaScript 搭配單頁應用程式框架時要小心;此類框架通常在啟動時載入大量程式碼，可能會延遲網頁內容的初始渲染。

    HTML 載入、解析和渲染速度非常快——比 JavaScript 產生相同 UI 所需的時間還快。 有些單頁應用程式的 JS 框架，即使框架初始 HTML 很小，整個框架程式碼都必須先下載、解析並執行，才能顯示任何內容。

  • 延後重度零件。

  • 在初始介面出現後，懶散地載入圖片或腳本。

另請參閱:

WebView2 控制項與主機應用程式之間的通訊

選擇合適的溝通管道

WebView2 提供多種網頁對主機及主機對網頁的通訊選項。

  • 盡量用網頁訊息，而不是主機物件。 網頁訊息通常比主機物件更快，這既是記憶體使用量也是時間，且網頁訊息的簡單且可靠。

  • 只有在需要網頁訊息難以表達的功能時才使用主機物件，例如：

    • 豐富且類物件的 API， (方法、屬性、事件) 你想直接暴露給 JavaScript 的 API。

    • 有狀態互動，維護主機端上下文比來回傳遞結構化訊息更簡單。

    • 大型或二進位資料流，反覆將字串序列化的有效載荷成網頁訊息會變得效率低下。

主機物件有以下缺點：

  • 主機物件需要 COM 封組，若物件圖改變或編組不正確，可能會造成不穩定。

  • 主機物件對於頻繁且頻繁的通話通常比單一批次 WebMessage的呼叫慢，因為每個方法或屬性存取會分別跨越邊界。

  • 主機物件會讓網頁與主機程式碼之間產生更緊密的耦合，降低了可攜性。

另請參閱:

優化溝通

實施非同步、批次通訊，以減少 IPC 通訊並減少資料複製。

另請參閱:

遙測與剖析工具

收集數據是識別並修復效能問題的關鍵。

以下是 WebView2 的工具與遙測技術。

WebView2 ETW 追蹤

使用 Microsoft WebView2.wprp 的 (Gathering an ETW Trace) profile with Windows Performance Recorder，擷取並分析詳細的 WebView2 事件，例如程序啟動與導航時序。

你可以透過 Windows 事件追蹤 (ETW) 來記錄 Edge/WebView2 提供者事件;參見 「收集 ETW 追蹤」。

在 Windows 效能分析器中分析 CPU、磁碟和記憶體資料的痕跡。

Microsoft Edge DevTools

使用 Microsoft Edge DevTools 監控 WebView2 的內容與程序，以識別如高 CPU 或記憶體洩漏等問題。

在 WebView2 應用程式中右鍵點擊 WebView2 控制項，然後選擇 檢查。 例如，右鍵點擊主 版 Win32 範例應用程式，然後點 選檢查。 DevTools 會從一個非底座、專用的瀏覽器視窗開啟。

在 DevTools 中，你可以使用像 是記憶體 工具和 效能 工具：

Edge DevTools 中的效能工具

另請參閱:

使用 Edge 開發工具檢查

使用 edge://inspect，該功能會開啟 「使用邊緣開發者工具檢查 」標籤，以監控 WebView2 的內容與程序，以識別如高 CPU 或記憶體洩漏等問題：

使用 Edge 開發工具檢查

欲了解如何 edge://inspect使用 ，請參閱遠端 除錯桌面 WebView2 WinUI 2 (UWP) 應用程式。

瀏覽器工作管理員

使用瀏覽器工作管理員監控 WebView2 的內容與程序，以識別如高 CPU 或記憶體洩漏等問題。

請參閱 瀏覽器工作管理員 (即時監控記憶體使用) 。

效能問題的工作流程故障排除

當 WebView2 應用程式出現效能問題時，請依照以下策略採取結構化方法進行故障排除。

簡單內容的測試

載入一個簡約的 HTML 頁面。

  • 如果簡單內容的效能仍然緩慢，請調查執行時初始化或主機應用程式因素。

  • 如果簡單內容的效能更快，就專注於優化你的網頁內容。

另請參閱:

驗證 WebView2 執行版本

請確保你使用的是最新的 WebView2 執行環境，而不是舊版或備用 Edge 安裝。 根據需要更新 WebView2 執行環境。

另請參閱:

監控記憶體使用情況

使用 Windows 工作管理員檢查 WebView2 的程序記憶體。

異常生長可能表示洩漏——利用WPR錄音進一步除錯。

另請參閱:

比較 WebView2 與 Microsoft Edge

WebView2 使用與 Microsoft Edge 相同的核心瀏覽器引擎。 請用 Microsoft Edge 以及 WebView2 驗證此案例，以找出問題所在。

另請參閱

  • Last updated on