次の方法で共有

WebView2 アプリのパフォーマンスのベスト プラクティス

WebView2 の起動時間、メモリ、CPU、およびネットワークの使用を最適化するには、次のプラクティスを使用します。 パフォーマンスのトラブルシューティングには、これらのツールとワークフローを使用します。

Windows アプリに Microsoft Edge WebView2 を埋め込むと、最新の Web 機能が有効になります。 WebView2 は Edge のマルチプロセス アーキテクチャを使用するため、各コントロールはメモリと起動オーバーヘッドを追加する複数のブラウザー エンジン プロセスを起動します。

詳細な内容:

パフォーマンスのボトルネックの種類を特定する

パフォーマンスの低下の症状を観察して、問題が次の問題であるかどうかを判断します。

エバーグリーン ランタイムを使用する

  • 可能な限り、エバーグリーン WebView2 ランタイムを使用してアプリをデプロイします。 最新のパフォーマンスの向上とセキュリティ修正を取得するために、エバーグリーン ランタイムが自動的に更新されます。 WebView2 ランタイムを常緑 (つまり更新済み) のままにして、アプリの将来性を高めます。 固定バージョンを使用すると、最近の最適化を見逃すリスクがあります。

  • オフラインまたは互換性の理由で固定ランタイムを使用する必要がある場合は、新しいビルドをテストした後に定期的に更新してください。

  • 最新の WebView2 プレビュー チャネル (ベータ、開発、またはカナリア) を使用してアプリをテストし、今後の変更に備えます。 メモリ リークや CPU 使用率の高いなど、過去の多くのパフォーマンスの問題は、新しいバージョンの WebView2 ランタイムで対処されています。

Microsoft Edge と WebView2 のバージョンが一致し、Microsoft Edge が実行されている場合、必要な WebView2 バイナリは既にメモリ内にあり、起動パフォーマンスが向上します。

関連項目:

スタートアップ パフォーマンスを最適化する

コールド スタート (コールド ローンチ)

一般的なパフォーマンスのボトルネックは、WebView2 コントロールを作成し、初めて Web ページに移動する時間です。 コールド 起動時に、WebView2 はプロセスとディスク キャッシュを起動する必要があります。これにより、顕著な遅延が発生する可能性があります (ハードウェアとコンテンツの複雑さによって異なる場合があります)。

スタートアップを最適化するには、次のベスト プラクティスを使用します。

初期 UI に WebView2 を使用しない

  • スプラッシュ画面または単純なダイアログをレンダリングするには、WebView2 ではなく軽量の XAML または Win32 画面を使用します。

  • 起動コストとリソースの競合により、WebView2 でスプラッシュ画面や単純なダイアログをレンダリングしないようにします。 WebView2 を初期化するのは、実際の Web コンテンツを表示する場合のみです。

関連項目:

ユーザー データ フォルダー (UDF) の場所を最適化する

  • UDF は、パフォーマンスを向上させるために、既定のローカル アプリ データ フォルダーに保持します。 「 ユーザー データ フォルダーの管理」を参照してください。

  • 低速ドライブやネットワーク共有を避ける。より高速な物理ディスクにデータを配置します。

冗長な WebView2 インスタンスを回避する

必要以上に多くの WebView2 コントロールを作成しないように UI を計画します。

たとえば、複数の Web ページ間を移動する場合、WebView2 コントロールを破棄して再作成するのではなく、単一の WebView2 を再利用して新しい URL に移動する方が高速になる場合があります。

関連項目:

メモリ使用量とプロセス管理

各 WebView2 コントロールは、ブラウザー、レンダラー、GPU などの独自のプロセス セットを作成します。 一般に、WebView2 インスタンスの作成数が増え、各インスタンスが独自のブラウザー プロセスのセットを実行するにつれて、リソース使用量が増加します。

WebView2 インスタンスは、Web コンテンツの複雑さに基づいてメモリを使用し、ブラウザーが作成する処理を行います。 WebView2 コントロールの多くのインスタンスを実行すると、システム メモリが不足する可能性があります。

メモリ 占有領域を管理および削減するためのベスト プラクティスを次に示します。

WebView2 環境を共有する

  • メモリを節約するには、アプリ内のすべての WebView2 コントロールで 1 つの CoreWebView2Environment を使用し、共有のための一貫性のあるパラメーターを確保します。

  • 複数の環境を作成するのではなく、タブ付きインターフェイスで同じ環境を再利用します。

関連項目:

アプリ レベルのプロセス共有を使用する

  • 可能な場合は、アプリ レベルのプロセス共有を使用します。

    同一のユーザー データ フォルダーと CoreWebView2EnvironmentOptionsを使用して、複数のアプリでブラウザー プロセスを共有できます。 これによりメモリ使用量が削減されますが、アプリ間の干渉が発生する可能性があるため、プロファイルの慎重な管理と徹底的なテストが必要です。

    ユーザー データ フォルダー (UDF) を共有する場合、基になるデータ (Cookie、キャッシュ、データベースなど) が異なるアプリケーション間で共有されることに注意してください。

関連項目:

大きなスコープのホスト オブジェクトを避ける

AddHostObjectToScriptを使用して .NET オブジェクトを Web に公開する場合は、それらのオブジェクトがメモリに保持するものに注意してください。 スクリプト コンテキストが存続している限り、オブジェクト全体が効果的に参照されます。これにより、.NET 側でそのオブジェクトのガベージ コレクションが妨げられる可能性があります。

スクリプト作成に小さな部分のみが必要な場合は、非常に大きなオブジェクト グラフを公開しないでください。 アプリケーション モデル全体を渡す代わりに、目的固有の狭いホスト オブジェクトを作成することをお勧めします。 例:

  • ページが実際に必要とする操作とデータのみを公開します。 たとえば、AppContext全体ではなく、FileService オブジェクトを公開します。

  • 複雑なオブジェクトを小さなファサードの後ろにラップして、意図せずに深いオブジェクト階層を公開しないようにします。

  • コレクションの場合は、完全なデータ構造を公開するのではなく、フィルター処理またはページングされた結果を指定します。

オブジェクトを必要とするページがなくなったら、 CoreWebView2.RemoveHostObjectFromScript を呼び出してオブジェクト グラフを解放します。 たとえば、ホスト オブジェクトを使用していたページから離れた場所に移動する場合は、そのオブジェクトを削除して、バックグラウンドで維持されないようにします。

関連項目:

メモリ リークの防止

  • 参照サイクルとリークを回避するために、WebView2 オブジェクトを破棄する前にネイティブ イベント ハンドラーを削除します。

  • WebView2 を強く参照するクロージャは避けてください。必要に応じて弱参照を使用します。

  • WebView2.Dispose()を呼び出して、WebView2 オブジェクトが不要になったときに解放します。

関連項目:

メモリ管理 API を使用する

  • 非アクティブな WebView に MemoryUsageTargetLevel = CoreWebView2MemoryUsageTargetLevel.Low を設定してメモリ使用量を削減します。これにより、キャッシュされたデータを削除したり、メモリをディスクにスワップしたりするようにブラウザー エンジンに求められる場合があります。 WebView2 インスタンスが再びアクティブになったら、ターゲット レベルを Normalに復元して、完全なパフォーマンスを実現します。 「WebView2 API の概要」の「メモリ使用量ターゲット」を参照してください。

  • WebView2 インスタンスがしばらく使用されない場合は、 CoreWebView2.TrySuspendAsync() を呼び出してレンダラー プロセスを中断します。これにより、スクリプトが一時停止され、リソースの使用量がさらに減少します。 必要に応じ、 Resume() で再開します。 これらの Try 操作はベスト エフォートです。 「WebView2 API の概要」の「パフォーマンスとデバッグ」を参照してください。

Web コンテンツを最適化する

WebView2 を定期的に更新する

CPU とレンダリングのパフォーマンス

WebView2 は、Edge が使用するブラウザー エンジンに Web コンテンツレンダリングをオフロードするため、パフォーマンス特性は Edge でサイトを実行するようなものです。

次のプラクティスは、効率的な CPU 使用率とスムーズなレンダリングを保証します。

ハードウェア アクセラレーションを有効にする

  • トラブルシューティングを行う場合を除き、( disable-gpu フラグを使用して) レンダリングするための GPU by WebView2 の使用を無効にしないでください。

    既定では、WebView2 はレンダリングに GPU を使用します。 パフォーマンスのためには、WebView2 による GPU の使用が重要です。 GPU ドライバーと追加のバッファーを割り当てる必要があります。これには追加のメモリが必要です。

関連項目

Web コンテンツを合理化する

次の手法を使用してページを最適化します。

  • 重い JavaScript を制限します。

  • タスクをデバウンスまたはスロットルします。

  • アニメーションには (JavaScript ではなく) CSS を使用します。

  • 長いスクリプトを分割して UI の応答性を維持します。

  • Microsoft Edge DevTools を使用してボトルネックを特定します。

  • 一般的な Web 最適化を使用する: レイアウトのスラッシングが過剰にならないようにします。この場合、スクリプトによって DOM プロパティの読み取りと書き込みが交互に行われ、複数のリフローが発生します。

関連項目:

不要な通信を減らす

  • WebView2 でホストされているホスト アプリケーションと Web コンテンツ間の不要な通信を減らします。 これにより、プロセス間の過剰な通信とそれに伴うオーバーヘッドが回避されます。 「ネイティブ コードと Web コードの相互運用」を参照してください。

  • メッセージの受け渡しが頻繁に行われると CPU 使用率が増加する可能性があるため、可能な限りメッセージをバッチ処理します。

プロセスの優先順位を管理する

  • アプリに大量のネイティブ ワークロードがある場合は、WebView2 スレッドが不足しないように、スレッドの優先順位を慎重に割り当てます。 WebView2 では、個別のレンダラー プロセスが作成されます。

関連項目:

実際のシナリオをテストする

  • Microsoft Edge DevTools を使用して、ターゲット ハードウェア上の実際のコンテンツをテストして、パフォーマンスの問題を見つけて最適化します。

関連項目:

ネットワークと読み込みのパフォーマンス

特に WebView2 コントロールに Web コンテンツを読み込む場合、ネットワーク待機時間と帯域幅が限られていると、ユーザーが認識するパフォーマンスの問題が発生する可能性があります。

次のベスト プラクティスは、一般的な Web 開発と重複しています。

キャッシュとサービス ワーカーを利用する

WebView2 では、ブラウザーキャッシュがサポートされています。

  • キャッシュとサービス ワーカーを使用します。

  • リソース要求の繰り返しでキャッシュされたバージョンが使用されるように、適切なキャッシュ ヘッダーを提供します。

  • オフライン アクセスのために、サービス ワーカーを使用して静的ファイルを事前にキャッシュすることを検討してください。キャッシュ サイズを監視します。

関連項目:

ネットワークのボトルネックを確認する

DevTools Network ツールを使用して、WebView2 の低速リソースを特定します。 「ネットワーク アクティビティを検査する」を参照してください。

必要に応じて、低速のサード パーティ製スクリプトまたは API を最適化または非同期的に読み込みます。

初期ペイロードを減らす

認識される速度を向上させるには:

  • 初期ペイロードライトを保持します。 通常は JavaScript よりも高速に読み込み、解析、レンダリングされるため、静的 HTML を最初に送信することをお勧めします。 JavaScript と単一ページ アプリ フレームワークを最初に使用する場合は注意が必要です。このようなフレームワークは通常、起動時に多くのコードを読み込みます。これにより、Web コンテンツの初期レンダリングが遅れる可能性があります。

    HTML の読み込み、解析、レンダリングは、JavaScript が同じ UI を生成するのにかかった時間よりも高速です。 一部のシングルページ アプリ JS フレームワークでは、フレームワークの初期 HTML が小さい場合でも、フレームワーク コード全体をダウンロード、解析、実行してから、何かを表示する必要があります。

  • 重いコンポーネントを延期します。

  • 初期 UI が表示された後の遅延読み込みイメージまたはスクリプト。

関連項目:

WebView2 コントロールとホスト アプリ間の通信

適切な通信チャネルを選択する

WebView2 には、さまざまな Web 間通信オプションとホスト間通信オプションが用意されています。

  • ホスト オブジェクトではなく、Web メッセージを使用してみてください。 Web メッセージは、Web メッセージのシンプルさと信頼性のために、メモリ使用量と時間の両方のために、ホスト オブジェクトよりも高速になる傾向があります。

  • ホスト オブジェクトは、次のような Web メッセージが簡単に表現できない機能が必要な場合にのみ使用します。

    • JavaScript に直接公開する豊富なオブジェクトに似た API (メソッド、プロパティ、イベント)。

    • ホスト側のコンテキストを維持する方が、構造化されたメッセージを前後に渡すよりも簡単なステートフルな対話。

    • ペイロードを Web メッセージに繰り返しシリアル化すると非効率的になる大きなデータ フローまたはバイナリ データ フロー。

ホスト オブジェクトには、次の欠点があります。

  • ホスト オブジェクトには COM マーシャリングが必要です。これにより、オブジェクト グラフが変更されたり、正しくマーシャリングされなかったりすると不安定になる可能性があります。

  • 一般に、ホスト オブジェクトは、各メソッドまたはプロパティ アクセスが境界を個別に越えるため、1 つのバッチ処理された WebMessageと比較して、頻繁な呼び出しの方が遅くなります。

  • ホスト オブジェクトは、Web とホスト コード間の緊密な結合を作成し、移植性を低下させます。

関連項目:

コミュニケーションを最適化する

IPC 通信を最小限に抑え、データのコピーを減らすために、非同期のバッチ通信を実装します。

関連項目:

テレメトリとプロファイリング ツール

データの収集は、パフォーマンスの問題を特定して修正するための鍵です。

WebView2 のツールとテレメトリ手法を次に示します。

WebView2 ETW トレース

Windows パフォーマンス レコーダーで Microsoft の WebView2.wprp (ETW トレースの収集) プロファイルを使用して、プロセスの起動やナビゲーションのタイミングなど、詳細な WebView2 イベントをキャプチャして分析します。

Edge/WebView2 プロバイダー イベントは、Windows イベント トレース (ETW) を使用して記録できます。ETW トレースの収集に関するページを参照してください。

CPU、ディスク、メモリ データの Windows パフォーマンス アナライザーのトレースを分析します。

Microsoft Edge DevTools

Microsoft Edge DevTools を使用して WebView2 のコンテンツとプロセスを監視し、CPU 使用率やメモリ リークなどの問題を特定します。

WebView2 アプリで WebView2 コントロールを右クリックし、[ 検査] を選択します。 たとえば、メインの Win32 サンプル アプリを右クリックし、[ 検査] をクリックします。 DevTools は、ドッキングされていない専用ブラウザー ウィンドウで開きます。

DevTools では、 メモリ ツールや パフォーマンス ツールなどのツールを使用できます。

Edge DevTools のパフォーマンス ツール

関連項目:

Edge 開発者ツールを使用した検査

[Edge Developer Tools で検査] タブを開く edge://inspectを使用して、WebView2 のコンテンツとプロセスを監視し、CPU 使用率やメモリ リークなどの問題を特定します。

Edge 開発者ツールを使用した検査

edge://inspectを使用して WebView2 プロセスを検査する方法の詳細については、「リモート デバッグ デスクトップ WebView2 WinUI 2 (UWP) アプリ」を参照してください。

ブラウザー タスク マネージャー

ブラウザー タスク マネージャーを使用して WebView2 のコンテンツとプロセスを監視し、CPU 使用率やメモリ リークなどの問題を特定します。

「 メモリ使用量をリアルタイムで監視する (ブラウザー タスク マネージャー)」を参照してください。

パフォーマンスの問題に関するワークフローのトラブルシューティング

WebView2 アプリでパフォーマンスの問題が発生した場合は、次の方法に従って構造化された方法を使用してトラブルシューティングを行います。

単純なコンテンツでテストする

最小限の HTML ページを読み込みます。

  • 単純なコンテンツでパフォーマンスが依然として遅い場合は、ランタイムの初期化またはホスト アプリの要因を調査します。

  • 単純なコンテンツでパフォーマンスが速い場合は、Web コンテンツの最適化に重点を置きます。

関連項目:

WebView2 ランタイムのバージョンを確認する

古いバージョンまたはフォールバック Edge インストールではなく、最新の WebView2 ランタイムを実行していることを確認します。 必要に応じて WebView2 ランタイムを更新します。

関連項目:

メモリ使用量の監視

Windows タスク マネージャーを使用して、WebView2 プロセス メモリをチェックします。

異常な増加はリークを示している可能性があります。WPR 録音を使用してこれをさらにデバッグします。

関連項目:

WebView2 と Microsoft Edge の比較

WebView2 では、Microsoft Edge と同じコア ブラウザー エンジンが使用されます。 問題を特定するために、Microsoft Edge と WebView2 でケースを検証します。

関連項目

  • Last updated on