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

Verwenden Sie die folgenden Methoden, um die Startzeit, den Arbeitsspeicher, die CPU- und die Netzwerknutzung von WebView2 zu optimieren. Verwenden Sie diese Tools und Workflows zur 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 den Arbeitsspeicher- und Startaufwand erhöhen.

Detaillierter Inhalt:

Identifizieren des Typs des Leistungsengpasses

Beobachten Sie die Symptome der langsamen Leistung, um festzustellen, ob das Problem Folgendes ist:

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 stets aktuell (d. h. aktualisiert), um Ihre App zukunftssicher zu machen. Bei Verwendung einer Fixierten Version besteht das Risiko, dass die letzten Optimierungen verpasst werden.

  • Wenn Sie aus Offline- oder Kompatibilitätsgründen eine feste Laufzeit verwenden müssen, aktualisieren Sie sie regelmäßig, nachdem Sie neue Builds getestet haben.

  • Testen Sie Ihre App mit den neuesten WebView2-Vorschaukanälen (Beta, Dev oder Canary), um sich auf kommende Änderungen vorzubereiten. Viele frühere Leistungsprobleme, wie 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, um ein WebView2-Steuerelement zu erstellen und zum ersten Mal zu einer Webseite zu navigieren. Bei einem Kaltstart muss WebView2 seine Prozesse und Datenträger-Caches hochfahren, 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.

WebView2 nicht für die anfängliche Benutzeroberfläche verwenden

  • Zum Rendern von Begrüßungsbildschirmen oder einfachen Dialogfeldern verwenden Sie einfache XAML- oder Win32-Bildschirme anstelle von WebView2.

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

Siehe auch:

Optimieren des Speicherorts des Benutzerdatenordners (User Data Folder, UDF)

  • Behalten Sie die benutzerdefinierte Datenquelle aus Leistungsgründen im standardmäßigen lokalen App-Datenordner bei. Siehe Verwalten von Benutzerdatenordnern.

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

Vermeiden redundanter WebView2-Instanzen

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

Wenn Sie z. B. zwischen mehreren Webseiten navigieren, ist es möglicherweise schneller, ein einzelnes WebView2-Steuerelement wiederzuverwenden und einfach zu einer neuen URL zu navigieren, als 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.

Eine WebView2-Instance verwendet Arbeitsspeicher basierend auf der Komplexität des Webinhalts und der von ihr erstellten Browserprozesse. Das Ausführen vieler Instanzen des WebView2-Steuerelements kann den Systemspeicher belasten.

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

Freigeben von WebView2-Umgebungen

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

  • Verwenden Sie dieselbe Umgebung in Oberflächen mit Registerkarten wieder, anstatt mehrere Umgebungen zu erstellen.

Siehe auch:

Verwenden der Prozessfreigabe auf App-Ebene

  • Verwenden Sie, falls möglich, die Prozessfreigabe auf App-Ebene.

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

    Beachten Sie, dass bei der Freigabe eines Benutzerdatenordners (User Data Folder, UDF) die zugrunde liegenden Daten (z. B. Cookies, Caches und Datenbanken) von verschiedenen Anwendungen gemeinsam genutzt werden.

Siehe auch:

Hostobjekte mit großem Bereich vermeiden

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

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

  • Machen Sie nur die Vorgänge und Daten verfügbar, die die Seite tatsächlich benötigt. Machen Sie beispielsweise ein FileService Objekt verfügbar, anstatt Ihrer gesamten AppContext.

  • Wickeln Sie komplexe Objekte hinter kleine Fassaden, um zu vermeiden, dass ungewollt tiefe Objekthierarchien offengelegt werden.

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

Wenn die Seite, auf der das Objekt benötigt wurde, nicht mehr vorhanden ist, rufen Sie CoreWebView2.RemoveHostObjectFromScript auf, um das Objektdiagramm freizugeben. Wenn Sie z. B. von einer Seite wegnavigieren, die ein Hostobjekt verwendet hat, entfernen Sie dieses Objekt, um zu vermeiden, dass es hinter den Kulissen aktiv bleibt.

Siehe auch:

Verhindern von Speicherverlusten

  • Entfernen Sie systemeigene Ereignishandler, bevor Sie WebView2-Objekte verwerfen, um Verweiszyklen und Datenlecks zu vermeiden.

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

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

Siehe auch:

Verwenden von Speicherverwaltungs-APIs

  • Legen Sie inaktive WebViews fest MemoryUsageTargetLevel = CoreWebView2MemoryUsageTargetLevel.Low , um die Speicherauslastung zu reduzieren. Dies kann das Browsermodul dazu veranlassen, zwischengespeicherte Daten zu löschen oder Speicher auf dem Datenträger auszulegen. Wenn die WebView2-Instance wieder aktiv ist, stellen Sie die Zielebene auf wieder her, um Normaldie volle Leistung zu erzielen. Weitere Informationen finden Sie unter Speicherauslastungsziel in der Übersicht über WebView2-APIs.

  • Wenn die WebView2-Instance eine Weile nicht verwendet wird, rufen CoreWebView2.TrySuspendAsync() Sie auf, um den Rendererprozess anzuhalten, wodurch Skripts angehalten werden und die Ressourcennutzung weiter verringert wird. Fortsetzen mit Resume() , wenn nötig. Diese Try Vorgänge werden nach bestem Wissen und Gewissen durchgeführt. Weitere Informationen finden Sie unter "Leistung und Debugging " in der Übersicht über WebView2-APIs.

Optimieren von Webinhalten

Aktualisieren Sie WebView2 regelmäßig.

CPU- und Rendering-Leistung

WebView2 lagert das Rendering von Webinhalten an das von Edge verwendete Browser-Modul aus, sodass die Leistungsmerkmale denen entsprechen, die dem Ausführen einer Website in Edge entsprechen.

Die folgenden Methoden sorgen für eine effiziente CPU-Nutzung und ein reibungsloses Rendering.

Hardwarebeschleunigung aktivieren

  • Deaktivieren Sie nicht die Verwendung der GPU durch WebView2 für das Rendering (über das Flag), außer bei der disable-gpu Problembehandlung.

    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 belegt werden, wofür zusätzlicher Arbeitsspeicher erforderlich ist.

Siehe auch

Optimieren von Webinhalten

Optimieren Sie Seiten mithilfe der folgenden Techniken:

  • Begrenzen Sie starkes JavaScript.

  • Freigeben oder Drosseln von Aufgaben.

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

  • Teilen Sie lange Skripts auf, um die Benutzeroberfläche reaktionsfähig zu halten.

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

  • Verwenden Sie die typische Weboptimierung: Vermeiden Sie übermäßiges Layout-Thrashing, bei dem ein Skript zwischen dem Lesen und Schreiben von DOM-Eigenschaften wechselt, was mehrere Umwandlungen verursacht.

Siehe auch:

Reduzieren Sie unnötige Kommunikation

  • Reduzieren Sie unnötige Kommunikation zwischen der Hostanwendung und den in WebView2 gehosteten Webinhalten. Dadurch wird eine übermäßige Kommunikation zwischen Prozessen und der damit verbundene Overhead vermieden. Siehe Interoperabilität von systemeigenem und Webcode.

  • Batch-Nachrichten, wo immer dies möglich ist, da häufiges Übergeben von Nachrichten die CPU-Auslastung erhöhen kann.

Verwalten der Prozesspriorität

  • Wenn die App eine hohe systemeigene Arbeitsauslastung aufweist, weisen Sie Threadprioritäten sorgfältig zu, um zu vermeiden, dass WebView2-Threads verhungern. WebView2 erstellt separate Rendererprozesse.

Siehe auch:

Testen realer Szenarien

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

Siehe auch:

Netzwerk- und Ladeleistung

Netzwerklatenz und begrenzte 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.

Nutzen von Caching und Service Workern

WebView2 unterstützt Browserzwischenspeicherung.

  • Verwenden Sie Caching und Service Worker.

  • Bereitstellen geeigneter Cacheheader, sodass wiederholte Ressourcenanforderungen zwischengespeicherte Versionen verwenden.

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

Siehe auch:

Überprüfen von Netzwerkengpässen

Verwenden des DevTools-Netzwerktools zum Identifizieren langsamer Ressourcen in WebView2. siehe Überprüfen der Netzwerkaktivität.

Optimieren oder laden Sie bei Bedarf langsame Skripte oder APIs von Drittanbietern.

Anfängliche Nutzlasten reduzieren

So verbessern Sie die wahrgenommene Geschwindigkeit:

  • Halten Sie die anfängliche Nutzlast gering. Senden Sie lieber anfänglich statisches HTML, da es normalerweise schneller als JavaScript geladen, analysiert und gerendert wird. Seien Sie vorsichtig, wenn Sie JavaScript zunächst zusammen mit einem Single-Page-App-Framework verwenden. Ein solches Framework lädt normalerweise beim Start viel Code, was das anfängliche Rendern des Webinhalts verzögern kann.

    HTML wird sehr schnell geladen, analysiert und gerendert – schneller als die Zeit, die JavaScript für dieselbe Benutzeroberfläche benötigt hätte. Bei einigen Single-Page-App-JS-Frameworks muss der gesamte Framework-Code heruntergeladen, analysiert und ausgeführt werden, bevor etwas angezeigt werden kann, selbst wenn der anfängliche HTML-Code des Frameworks klein ist.

  • Verschieben Sie schwere Komponenten.

  • Lazy-Load-Bilder oder Skripts, nachdem die anfängliche Benutzeroberfläche angezeigt wird.

Siehe auch:

Kommunikation zwischen dem WebView2-Steuerelement und der Host-App

Wählen Sie den richtigen Kommunikationskanal

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, was sowohl auf die Speicherauslastung als auch auf die Zeit zurückzuführen ist.

  • 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 die Übergabe strukturierter Nachrichten hin und her.

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

Hostobjekte weisen die folgenden Nachteile auf:

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

  • Hostobjekte sind bei gesprächigen, häufigen Aufrufen im Allgemeinen langsamer als bei einem einzelnen Batch, WebMessageda jeder Methoden- oder Eigenschaftszugriff die Grenze einzeln überschreitet.

  • Hostobjekte schaffen eine engere Kopplung zwischen Web- und Hostcode, wodurch die Portabilität verringert wird.

Siehe auch:

Kommunikation optimieren

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 zur Identifizierung und Behebung von Leistungsproblemen.

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

WebView2 ETW-Ablaufverfolgung

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

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

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

Microsoft Edge DevTools

Verwenden Sie Microsoft Edge DevTools, um WebView2-Inhalte und -Prozesse zu überwachen und 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 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 den Edge-Entwicklungstools

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

Untersuchen mit den Edge-Entwicklungstools

Weitere Informationen zum Überprüfen eines WebView2-Prozesses mithilfe von edge://inspectfinden Sie unter Remotedebuggen von Desktop-WebView2 WinUI 2 (UWP)-Apps.

Task-Manager des Browsers

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

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

Problembehandlung bei Workflows für Leistungsprobleme

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

Mit einfachem Inhalt testen

Laden Sie eine minimal HTML-Seite.

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

  • Wenn die Leistung bei 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 Windows Task-Manager, um den WebView2-Prozessspeicher zu überprüfen.

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

Siehe auch:

Vergleich 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 einzugrenzen.

Siehe auch

  • Zuletzt aktualisiert um