Freigeben über

Bewährte Methoden zur Leistung für WebView2-Apps

Verwenden Sie die folgenden Methoden, um die Startzeit, den Arbeitsspeicher, die CPU- und Netzwerknutzung von WebView2 zu optimieren. Verwenden Sie diese Tools und Workflows für die Problembehandlung bei der Leistung.

Das Einbetten von Microsoft Edge WebView2 in Windows-Apps ermöglicht moderne Webfeatures. WebView2 verwendet die Multiprozessarchitektur von Edge, sodass jedes Steuerelement mehrere Browser-Engine-Prozesse startet, die Arbeitsspeicher und Startaufwand erhöhen.

Ausführlicher Inhalt:

Identifizieren des Typs des Leistungsengpasses

Beobachten Sie die Symptome der langsamen Leistung, um zu ermitteln, ob das Problem:

Verwenden der Evergreen Runtime

  • Stellen Sie Ihre App nach Möglichkeit mit der Evergreen WebView2 Runtime bereit. Die Evergreen Runtime wird automatisch aktualisiert, um die neuesten Leistungsverbesserungen und Sicherheitskorrekturen zu erhalten. Halten Sie die WebView2 Runtime evergreen (d. h. aktualisiert), um Ihre App zukunftssicher zu machen. Die Verwendung einer festen Version riskiert, dass aktuelle Optimierungen fehlen.

  • Wenn Sie eine feste Runtime aus Offline- oder Kompatibilitätsgründen verwenden müssen, aktualisieren Sie sie nach dem Testen neuer Builds regelmäßig.

  • Testen Sie Ihre App mithilfe der neuesten WebView2-Vorschaukanäle (Beta, Dev oder Canary), um sich auf bevorstehende Änderungen vorzubereiten. Viele frühere Leistungsprobleme, z. B. Speicherverluste und hohe CPU-Auslastung, wurden in neueren Versionen der WebView2-Runtime behoben.

Wenn die Versionen von Microsoft Edge und WebView2 übereinstimmen und Microsoft Edge ausgeführt wird, befinden sich die erforderlichen WebView2-Binärdateien bereits im Arbeitsspeicher, wodurch die Startleistung verbessert wird.

Siehe auch:

Optimieren der Startleistung

Kaltstart (Kaltstart)

Ein häufiger Leistungsengpass ist die Zeit, ein WebView2-Steuerelement zu erstellen und zum ersten Mal zu einer Webseite zu navigieren. Bei einem Kaltstart muss WebView2 seine Prozesse und Datenträgercaches einrichten, was zu einer spürbaren Verzögerung führen kann (die je nach Hardware- und Inhaltskomplexität variieren kann).

Verwenden Sie die folgenden bewährten Methoden, um den Start zu optimieren.

Verwenden Sie WebView2 nicht für die erste Benutzeroberfläche.

  • Verwenden Sie einfache XAML- oder Win32-Bildschirme anstelle von WebView2, um Begrüßungsbildschirme oder einfache Dialogfelder zu rendern.

  • Vermeiden Sie das Rendern von Begrüßungsbildschirmen oder einfachen Dialogen mit WebView2 aufgrund von Startkosten und Ressourcenkonflikten. Initialisieren Sie WebView2 nur beim Anzeigen des tatsächlichen Webinhalts.

Siehe auch:

Optimieren des Speicherorts für Benutzerdatenordner (User Data Folder, UDF)

  • Behalten Sie die UDF aus Leistungsgründen im lokalen Standarddatenordner der App bei. Weitere Informationen finden Sie unter Verwalten von Benutzerdatenordnern.

  • Vermeiden Sie langsame Laufwerke oder Netzwerkfreigaben. Legen Sie die Daten auf einem schnelleren, physischen Datenträger ab.

Vermeiden redundanter WebView2-Instanzen

Planen Sie Ihre Benutzeroberfläche so, dass Sie nicht mehr WebView2-Steuerelemente als erforderlich erstellen.

Wenn Sie beispielsweise zwischen mehreren Webseiten navigieren, kann es schneller sein, eine einzelne WebView2 wiederzuverwenden und einfach zu einer neuen URL zu navigieren, anstatt ein WebView2-Steuerelement zu zerstören und neu zu erstellen.

Siehe auch:

Speicherauslastung und Prozessverwaltung

Jedes WebView2-Steuerelement erstellt einen eigenen Satz von Prozessen, z. B. Browser, Renderer und GPU. Die Ressourcennutzung nimmt im Allgemeinen zu, wenn mehr WebView2-Instanzen erstellt werden, wobei jede instance einen eigenen Satz von Browserprozessen ausführt.

Ein WebView2-instance verwendet Arbeitsspeicher basierend auf der Komplexität des Webinhalts und der Browserprozesse, die er erstellt. Das Ausführen vieler Instanzen des WebView2-Steuerelements kann den Systemspeicher belasten.

Im Folgenden finden Sie bewährte Methoden zum Verwalten und Reduzieren des Speicherbedarfs.

Freigeben von WebView2-Umgebungen

  • Um Arbeitsspeicher zu sparen, verwenden Sie eines CoreWebView2Environment für alle WebView2-Steuerelemente in einer App, um konsistente Parameter für die Freigabe zu gewährleisten.

  • Verwenden Sie dieselbe Umgebung in Schnittstellen im Registerkartenformat wieder, anstatt mehrere Umgebungen zu erstellen.

Siehe auch:

Verwenden der Prozessfreigabe auf App-Ebene

  • Verwenden Sie nach Möglichkeit die Prozessfreigabe auf App-Ebene.

    Mehrere Apps können einen Browserprozess gemeinsam nutzen, indem sie den identischen Benutzerdatenordner und verwenden CoreWebView2EnvironmentOptions. Dies reduziert die Speicherauslastung, erfordert jedoch eine sorgfältige Verwaltung von Profilen und gründliche Tests aufgrund möglicher App-übergreifender Störungen.

    Beachten Sie, dass beim Freigeben eines Benutzerdatenordners (User Data Folder, UDF) zugrunde liegende Daten (z. B. Cookies, Caches und Datenbanken) von verschiedenen Anwendungen gemeinsam genutzt werden.

Siehe auch:

Vermeiden von Hostobjekten mit großem Umfang

Wenn Sie verwenden AddHostObjectToScript , um .NET-Objekte im Web verfügbar zu machen, achten Sie darauf, was diese Objekte im Arbeitsspeicher enthalten. Auf das gesamte Objekt wird effektiv verwiesen, solange der Skriptkontext weiterhin aktiv ist, was die Garbage Collection dieses Objekts auf der .NET-Seite verhindern könnte.

Machen Sie kein sehr großes Objektdiagramm verfügbar, wenn nur ein kleiner Teil für die Skripterstellung benötigt wird. Bevorzugen Sie die Erstellung schmaler, zweckspezifischer Hostobjekte, anstatt vollständige Anwendungsmodelle zu übergeben. Zum Beispiel:

  • Machen Sie nur die Vorgänge und Daten verfügbar, die die Seite tatsächlich benötigt. Machen Sie beispielsweise ein FileService -Objekt anstelle des gesamten AppContextverfügbar.

  • Umschließen Sie komplexe Objekte hinter kleinen Fassaden, um unbeabsichtigt tiefe Objekthierarchien zu vermeiden.

  • Stellen Sie für Sammlungen gefilterte oder ausgelagerte Ergebnisse bereit, anstatt die vollständige Datenstruktur verfügbar zu machen.

Wenn die Seite, die das Objekt benötigt hat, nicht mehr vorhanden ist, rufen Sie auf CoreWebView2.RemoveHostObjectFromScript , um das Objektdiagramm freizugeben. Wenn Sie beispielsweise von einer Seite weg navigieren, die ein Hostobjekt verwendet hat, entfernen Sie dieses Objekt, um zu vermeiden, dass es im Hintergrund aktiv bleibt.

Siehe auch:

Verhindern von Speicherverlusten

  • Entfernen Sie systemeigene Ereignishandler vor dem Löschen von WebView2-Objekten, um Verweiszyklen und Verluste zu vermeiden.

  • Vermeiden Sie Schließungen, die stark auf WebView2 verweisen. verwenden Sie bei Bedarf schwache Verweise.

  • Rufen Sie WebView2.Dispose() auf, um WebView2-Objekte freizugeben, wenn sie nicht mehr benötigt werden.

Siehe auch:

Verwenden von Speicherverwaltungs-APIs

  • Legen Sie MemoryUsageTargetLevel = CoreWebView2MemoryUsageTargetLevel.Low für inaktive WebViews fest, um die Speicherauslastung zu reduzieren. Dadurch kann die Browser-Engine aufgefordert werden, zwischengespeicherte Daten zu löschen oder den Arbeitsspeicher auf den Datenträger zu tauschen. Wenn die WebView2-instance wieder aktiv ist, stellen Sie die Zielebene auf wieder her, um die volle Leistung zu Normalerzielen. Weitere Informationen finden Sie unter Speicherauslastungsziel in Der Übersicht über WebView2-APIs.

  • Wenn die WebView2-instance für eine Weile nicht verwendet wird, rufen Sie aufCoreWebView2.TrySuspendAsync(), um den Rendererprozess anzuhalten. Dadurch werden Skripts angehalten und die Ressourcennutzung weiter verringert. Setzen Sie bei Bedarf mit Resume() fort. Bei diesen Try Vorgängen handelt es sich um bestmögliche Leistung. Weitere Informationen finden Sie unter Leistung und Debuggen unter Übersicht über WebView2-APIs.

Optimieren von Webinhalten

Regelmäßiges Aktualisieren von WebView2

CPU- und Renderingleistung

WebView2 überlädt das Rendern von Webinhalten auf die Von Edge verwendete Browser-Engine, sodass die Leistungsmerkmale dem Ausführen einer Website in Edge ähneln.

Die folgenden Methoden stellen eine effiziente CPU-Auslastung und ein reibungsloses Rendering sicher.

Aktivieren der Hardwarebeschleunigung

  • Deaktivieren Sie die Verwendung der GPU durch WebView2 nicht zum Rendern (über das disable-gpu Flag), außer wenn Sie die Problembehandlung durchführen.

    Standardmäßig verwendet WebView2 die GPU zum Rendern. Die Verwendung der GPU durch WebView2 ist entscheidend für die Leistung. GPU-Treiber und zusätzliche Puffer müssen zugeordnet werden, was zusätzlichen Arbeitsspeicher erfordert.

Siehe auch

Optimieren von Webinhalten

Optimieren Sie Seiten mithilfe der folgenden Techniken:

  • Einschränken von javascript-intensiven Daten.

  • Debounce oder Drosselung von Aufgaben.

  • Verwenden Sie CSS (anstelle von JavaScript) für Animationen.

  • Teilen Sie lange Skripts auf, um die Reaktionsfähigkeit der Benutzeroberfläche zu erhalten.

  • Verwenden Sie Microsoft Edge DevTools, um Engpässe zu identifizieren.

  • Verwenden Sie die typische Weboptimierung: Vermeiden Sie übermäßige Layout-Thrashings, bei denen ein Skript zwischen Lesen und Schreiben von DOM-Eigenschaften wechselt, was zu mehreren Reflows führt.

Siehe auch:

Reduzieren unnötiger Kommunikation

  • Reduzieren Sie unnötige Kommunikation zwischen der Hostanwendung und Webinhalten, die in WebView2 gehostet werden. Dadurch wird eine übermäßige prozessübergreifende Kommunikation sowie der damit verbundene Mehraufwand vermieden. Weitere Informationen finden Sie unter Interop von nativem und Webcode.

  • Batchnachrichten, wo immer möglich, da häufige Nachrichtenübergaben die CPU-Auslastung erhöhen können.

Verwalten der Prozesspriorität

  • Wenn die App über eine hohe native Workload verfügt, weisen Sie Threadprioritäten sorgfältig zu, um zu vermeiden, dass WebView2-Threads ausgehungern. WebView2 erstellt separate Rendererprozesse.

Siehe auch:

Testen realer Szenarien

  • Testen Sie Ihre tatsächlichen Inhalte auf Der Zielhardware mithilfe von Microsoft Edge DevTools, um Leistungsprobleme zu finden und zu optimieren.

Siehe auch:

Netzwerk- und Ladeleistung

Netzwerklatenz und eingeschränkte Bandbreite können vom Benutzer wahrgenommene Leistungsprobleme verursachen, insbesondere beim Laden von Webinhalten in einem WebView2-Steuerelement.

Die folgenden bewährten Methoden überschneiden sich mit der allgemeinen Webentwicklung.

Verwenden von Zwischenspeicherung und Service Workern

WebView2 unterstützt die Browserzwischenspeicherung.

  • Verwenden Sie Zwischenspeicherung und Service Worker.

  • Stellen Sie die richtigen Cacheheader bereit, sodass wiederholte Ressourcenanforderungen zwischengespeicherte Versionen verwenden.

  • Erwägen Sie die Vorabzwischenspeicherung statischer Dateien mithilfe eines Service Workers für den Offlinezugriff. überwachen Sie jedoch die Cachegröße.

Siehe auch:

Überprüfen von Netzwerkengpässen

Verwenden Sie das DevTools Network-Tool , um langsame Ressourcen in WebView2 zu identifizieren. Weitere Informationen finden Sie unter Untersuchen der Netzwerkaktivität.

Optimieren oder laden Sie langsame Skripts oder APIs von Drittanbietern nach Bedarf.

Reduzieren der anfänglichen Nutzlasten

So verbessern Sie die wahrgenommene Geschwindigkeit:

  • Halten Sie die anfängliche Nutzlast leicht. Bevorzugen Sie das anfängliche Senden von statischem HTML, da es in der Regel schneller als JavaScript lädt, analysiert und gerendert wird. Seien Sie vorsichtig bei der anfänglichen Verwendung von JavaScript zusammen mit einem Single-Page-App-Framework. Ein solches Framework lädt in der Regel viel Code beim Start, was das anfängliche Rendern des Webinhalts verzögern kann.

    HTML lädt, analysiert und rendert sehr schnell – schneller als die Zeit, die JavaScript benötigt hätte, um die gleiche Benutzeroberfläche zu erzeugen. Bei einigen Single-Page-App-JS-Frameworks muss der gesamte Frameworkcode heruntergeladen, analysiert und ausgeführt werden, selbst wenn der anfängliche HTML-Code des Frameworks klein ist, bevor etwas angezeigt werden kann.

  • Zurückstellen von schweren Komponenten.

  • Verzögertes Laden von Bildern oder Skripts, nachdem die anfängliche Benutzeroberfläche angezeigt wird.

Siehe auch:

Kommunikation zwischen dem WebView2-Steuerelement und der Host-App

Auswählen des richtigen Kommunikationskanals

WebView2 bietet verschiedene Web-to-Host- und Host-to-Web-Kommunikationsoptionen.

  • Versuchen Sie, Webnachrichten anstelle von Hostobjekten zu verwenden. Webnachrichten sind aufgrund der Einfachheit und Zuverlässigkeit von Webnachrichten in der Regel schneller als Hostobjekte.

  • Verwenden Sie Hostobjekte nur, wenn Sie Funktionen benötigen, die webnachrichten nicht einfach ausdrücken können, z. B.:

    • Umfangreiche, objektähnliche APIs (Methoden, Eigenschaften, Ereignisse), die Sie direkt für JavaScript verfügbar machen möchten.

    • Zustandsbehaftete Interaktionen, bei denen die Aufrechterhaltung des hostseitigen Kontexts einfacher ist, als strukturierte Nachrichten hin und her zu übergeben.

    • Große oder binäre Datenflüsse, bei denen wiederholte Zeichenfolgenserialisierung von Nutzdaten in Webnachrichten ineffizient wird.

Hostobjekte haben die folgenden Nachteile:

  • Hostobjekte erfordern COM-Marshalling, was zu Instabilität führen kann, wenn sich das Objektdiagramm ändert oder nicht ordnungsgemäß gemarshallt wird.

  • Hostobjekte sind im Allgemeinen langsamer für chatzige, häufige Aufrufe WebMessageim Vergleich zu einem einzelnen Batch, da jeder Methoden- oder Eigenschaftszugriff die Grenze einzeln überschreitet.

  • Hostobjekte sorgen für eine engere Kopplung zwischen Web- und Hostcode und verringern so die Portabilität.

Siehe auch:

Optimieren der Kommunikation

Implementieren Sie asynchrone Batchkommunikation, um die IPC-Kommunikation zu minimieren und das Kopieren von Daten zu reduzieren.

Siehe auch:

Telemetrie- und Profilerstellungstools

Das Sammeln von Daten ist der Schlüssel zum Identifizieren und Beheben von Leistungsproblemen.

Im Folgenden finden Sie Tools und Telemetrietechniken für WebView2.

WebView2 ETW-Ablaufverfolgung

Verwenden Sie das WebView2.wprp Profil von Microsoft (Sammeln einer ETW-Ablaufverfolgung) mit Windows Performance Recorder, um detaillierte WebView2-Ereignisse wie Prozessstarts und Navigationszeitangaben zu erfassen und zu analysieren.

Sie können Edge-/WebView2-Anbieterereignisse aufzeichnen, indem Sie die Ereignisablaufverfolgung für Windows (ETW) verwenden. Weitere Informationen finden Sie unter Sammeln einer ETW-Ablaufverfolgung.

Analysieren Sie Ablaufverfolgungen in Windows Leistungsanalyse für CPU-, Datenträger- und Arbeitsspeicherdaten.

Microsoft Edge DevTools

Verwenden Sie Microsoft Edge DevTools, um WebView2-Inhalte und -Prozesse zu überwachen, um Probleme wie hohe CPU- oder Arbeitsspeicherverluste zu identifizieren.

Klicken Sie mit der rechten Maustaste auf ein WebView2-Steuerelement in einer WebView2-App, und wählen Sie dann Untersuchen aus. Klicken Sie beispielsweise mit der rechten Maustaste auf die Haupt-Win32-Beispiel-App, und klicken Sie dann auf Untersuchen. DevTools wird in einem nicht angedockten, dedizierten Browserfenster geöffnet.

In DevTools können Sie Tools wie das Speichertool und das Leistungstool verwenden:

Leistungstool in Edge DevTools

Siehe auch:

Untersuchen mit Edge-Entwicklertools

Verwenden Sie edge://inspect, wodurch die Registerkarte Mit Edge-Entwicklertools untersuchen geöffnet wird, um WebView2-Inhalte und -Prozesse zu überwachen, um Probleme wie hohe CPU- oder Arbeitsspeicherverluste zu identifizieren:

Untersuchen mit Edge-Entwicklertools

Weitere Informationen zum Untersuchen eines WebView2-Prozesses mithilfe edge://inspectvon finden Sie unter Remotedebuggen von WebView2 WinUI 2-Apps (UWP).

Browsertask-Manager

Verwenden Sie den Browsertask-Manager, um WebView2-Inhalte und -Prozesse zu überwachen, um Probleme wie hohe CPU- oder Arbeitsspeicherverluste zu identifizieren.

Weitere Informationen finden Sie unter Überwachen der Speichernutzung in Echtzeit (Browsertask-Manager).

Behandeln von Workflows für Leistungsprobleme

Wenn Leistungsprobleme in einer WebView2-App auftreten, verwenden Sie einen strukturierten Ansatz zur Problembehandlung gemäß den folgenden Strategien.

Testen mit einfachem Inhalt

Laden sie eine minimale HTML-Seite.

  • Wenn die Leistung bei einfachen Inhalten immer noch langsam ist, untersuchen Sie die Laufzeitinitialisierung oder Host-App-Faktoren.

  • Wenn die Leistung mit einfachen Inhalten schneller ist, konzentrieren Sie sich auf die Optimierung Ihrer Webinhalte.

Siehe auch:

Überprüfen der WebView2-Runtimeversion

Stellen Sie sicher, dass Sie die neueste WebView2-Runtime ausführen, keine veraltete Version oder Fallback-Edge-Installation. Aktualisieren Sie die WebView2-Runtime nach Bedarf.

Siehe auch:

Überwachen der Speicherauslastung

Verwenden Sie den Windows-Task-Manager, um den WebView2-Prozessspeicher zu überprüfen.

Ungewöhnliches Wachstum kann auf ein Leck hindeuten. Verwenden Sie WPR-Aufzeichnungen, um dies weiter zu debuggen.

Siehe auch:

Vergleichen von WebView2 mit Microsoft Edge

WebView2 verwendet die gleiche Kernbrowser-Engine wie Microsoft Edge. Überprüfen Sie den Fall sowohl mit Microsoft Edge als auch mit WebView2, um das Problem zu isolieren.

Siehe auch

  • Last updated on