Partager via

Meilleures pratiques en matière de performances pour les applications WebView2

Utilisez les pratiques suivantes pour optimiser le temps de démarrage, la mémoire, le processeur et l’utilisation du réseau de WebView2. Utilisez ces outils et workflows pour résoudre les problèmes de performances.

L’incorporation de Microsoft Edge WebView2 dans les applications Windows permet d’activer des fonctionnalités web modernes. WebView2 utilise l’architecture multiprocesseur d’Edge. Chaque contrôle lance donc plusieurs processus de moteur de navigateur qui ajoutent de la mémoire et de la surcharge au démarrage.

Contenu détaillé :

Identifier le type de goulot d’étranglement des performances

Observez les symptômes de la lenteur des performances pour déterminer si le problème est :

Utiliser le runtime persistant

  • Dans la mesure du possible, déployez votre application avec le runtime Evergreen WebView2. Le runtime Evergreen se met automatiquement à jour pour obtenir les dernières améliorations des performances et les derniers correctifs de sécurité. Conservez le runtime WebView2 persistant (autrement dit, mis à jour) pour assurer la pérenne de votre application. L’utilisation d’une version fixe risque de manquer les optimisations récentes.

  • Si vous devez utiliser un runtime fixe pour des raisons de compatibilité ou hors connexion, mettez-le à jour régulièrement après avoir testé de nouvelles builds.

  • Testez votre application à l’aide des derniers canaux de préversion WebView2 (bêta, dev ou canary) pour vous préparer aux modifications à venir. De nombreux problèmes de performances passés, tels que les fuites de mémoire et l’utilisation élevée du processeur, ont été résolus dans les versions plus récentes du runtime WebView2.

Si les versions de Microsoft Edge et WebView2 correspondent et que Microsoft Edge est en cours d’exécution, les fichiers binaires WebView2 requis sont déjà en mémoire, ce qui améliore les performances de lancement.

Voir aussi :

Optimiser les performances de démarrage

Démarrage à froid (lancement à froid)

Un goulot d’étranglement des performances courant est le temps de créer un contrôle WebView2 et d’accéder à une page web pour la première fois. Lors d’un lancement à froid, WebView2 doit faire tourner ses processus et caches de disque, ce qui peut introduire un délai notable (qui peut varier en fonction de la complexité matérielle et du contenu).

Pour optimiser le démarrage, utilisez les meilleures pratiques suivantes.

N’utilisez pas WebView2 pour l’interface utilisateur initiale

  • Pour afficher des écrans de démarrage ou des boîtes de dialogue simples, utilisez des écrans XAML ou Win32 légers au lieu de WebView2.

  • Évitez le rendu des écrans de démarrage ou des boîtes de dialogue simples avec WebView2, en raison des coûts de démarrage et de la contention des ressources. Initialisez WebView2 uniquement lors de l’affichage du contenu web réel.

Voir aussi :

Optimiser l’emplacement du dossier de données utilisateur (UDF)

  • Conservez la fonction définie par l’utilisateur dans le dossier de données de l’application locale par défaut pour les performances. Consultez Gérer les dossiers de données utilisateur.

  • Évitez les lecteurs lents ou les partages réseau ; placer les données sur un disque physique plus rapide.

Éviter les instances WebView2 redondantes

Planifiez votre interface utilisateur afin de ne pas créer plus de contrôles WebView2 que nécessaire.

Par exemple, si vous naviguez entre plusieurs pages web, il peut être plus rapide de réutiliser un seul WebView2 et de le naviguer simplement vers une nouvelle URL, plutôt que de détruire et recréer un contrôle WebView2.

Voir aussi :

Utilisation de la mémoire et gestion des processus

Chaque contrôle WebView2 crée son propre ensemble de processus, tels que le navigateur, le renderer et le GPU. L’utilisation des ressources augmente généralement à mesure que de plus en plus d’instances WebView2 sont créées, chaque instance exécutant son propre ensemble de processus de navigateur.

Un instance WebView2 utilise la mémoire en fonction de la complexité du contenu web et des processus de navigateur qu’il crée. L’exécution de nombreuses instances du contrôle WebView2 peut épuiser la mémoire système.

Voici les meilleures pratiques pour gérer et réduire l’empreinte mémoire.

Partager des environnements WebView2

  • Pour économiser de la mémoire, utilisez-en un CoreWebView2Environment sur tous les contrôles WebView2 d’une application, ce qui garantit la cohérence des paramètres de partage.

  • Réutilisez le même environnement dans les interfaces à onglets plutôt que de créer plusieurs environnements.

Voir aussi :

Utiliser le partage de processus au niveau de l’application

  • Si possible, utilisez le partage de processus au niveau de l’application.

    Plusieurs applications peuvent partager un processus de navigateur à l’aide du dossier de données utilisateur et CoreWebView2EnvironmentOptionsde . Cela réduit l’utilisation de la mémoire, mais nécessite une gestion minutieuse des profils et des tests approfondis, en raison d’interférences entre applications possibles.

    Gardez à l’esprit que lors du partage d’un dossier de données utilisateur (UDF), les données sous-jacentes (telles que les cookies, les caches et les bases de données) sont partagées entre différentes applications.

Voir aussi :

Éviter les objets hôtes de grande étendue

Si vous utilisez AddHostObjectToScript pour exposer des objets .NET sur le web, gardez à l’esprit ce que ces objets contiennent en mémoire. L’objet entier est effectivement référencé tant que le contexte de script continue à vivre, ce qui peut empêcher le garbage collection de cet objet côté .NET.

N’exposez pas un graphe d’objets très volumineux, si seule une petite partie est nécessaire pour l’écriture de scripts. Préférez la création d’objets hôtes étroits et spécifiques à l’objectif, au lieu de passer des modèles d’application complets. Par exemple :

  • Exposez uniquement les opérations et les données dont la page a réellement besoin. Par exemple, exposez un FileService objet, au lieu de votre intégralité AppContext.

  • Encapsulez des objets complexes derrière de petites façades pour éviter d’exposer involontairement des hiérarchies d’objets profondes.

  • Pour les collections, fournissez des résultats filtrés ou paginés au lieu d’exposer la structure de données complète.

Lorsque la page qui avait besoin de l’objet a disparu, appelez CoreWebView2.RemoveHostObjectFromScript pour libérer le graphique d’objet. Par exemple, si vous quittez une page qui utilisait un objet hôte, supprimez cet objet pour éviter qu’il reste actif en arrière-plan.

Voir aussi :

Empêcher les fuites de mémoire

  • Supprimez les gestionnaires d’événements natifs avant de supprimer les objets WebView2 pour éviter les cycles de référence et les fuites.

  • Évitez les fermetures qui font fortement référence à WebView2 ; utilisez des références faibles si nécessaire.

  • Appelez WebView2.Dispose() pour libérer les objets WebView2 lorsqu’ils ne sont plus nécessaires.

Voir aussi :

Utiliser les API de gestion de la mémoire

  • Défini MemoryUsageTargetLevel = CoreWebView2MemoryUsageTargetLevel.Low sur les WebViews inactifs pour réduire l’utilisation de la mémoire. Cela peut inviter le moteur du navigateur à supprimer les données mises en cache ou à permuter la mémoire sur le disque. Lorsque le instance WebView2 est à nouveau actif, restaurez le niveau cible sur Normal, pour des performances optimales. Consultez Cible d’utilisation de la mémoire dans Vue d’ensemble des API WebView2.

  • Si le instance WebView2 ne sera pas utilisé pendant un certain temps, appelez CoreWebView2.TrySuspendAsync() pour suspendre le processus du renderer, ce qui interrompt les scripts et diminue encore l’utilisation des ressources. Reprenez avec si Resume() nécessaire. Ces Try opérations sont du meilleur effort. Consultez Performances et débogage dans Vue d’ensemble des API WebView2.

Optimiser le contenu web

Actualiser régulièrement webView2

Performances du processeur et du rendu

WebView2 décharge le rendu du contenu web vers le moteur de navigateur utilisé par Edge. Les caractéristiques de performances sont donc similaires à l’exécution d’un site dans Edge.

Les pratiques suivantes garantissent une utilisation efficace du processeur et un rendu fluide.

Activer l’accélération matérielle

  • Ne désactivez pas l’utilisation du GPU par WebView2 pour le rendu (via l’indicateur disable-gpu ), sauf lorsque vous résolvez des problèmes.

    Par défaut, WebView2 utilise le GPU pour le rendu. L’utilisation du GPU par WebView2 est essentielle pour les performances. Des pilotes GPU et des mémoires tampons supplémentaires doivent être alloués, ce qui nécessite de la mémoire supplémentaire.

Voir aussi

Simplifier le contenu web

Optimisez les pages à l’aide des techniques suivantes :

  • Limitez le code JavaScript lourd.

  • Débounce ou limiter les tâches.

  • Utilisez CSS (plutôt que JavaScript) pour les animations.

  • Fractionnez les scripts longs pour que l’interface utilisateur reste réactive.

  • Utilisez Microsoft Edge DevTools pour identifier les goulots d’étranglement.

  • Utilisez l’optimisation web classique : évitez les thrashings de disposition excessifs, où un script alterne entre la lecture et l’écriture de propriétés DOM, ce qui provoque plusieurs reflows.

Voir aussi :

Réduire les communications inutiles

  • Réduisez les communications inutiles entre l’application hôte et le contenu web hébergé dans WebView2. Cela permet d’éviter une communication interprocessus excessive, ainsi que la surcharge associée. Consultez Interopérabilité du code natif et du code web.

  • Traiter les messages par lot dans la mesure du possible, car le passage fréquent de messages peut augmenter l’utilisation du processeur.

Gérer la priorité du processus

  • Si l’application a une charge de travail native lourde, affectez soigneusement les priorités des threads pour éviter d’affamer les threads WebView2. WebView2 crée des processus de renderer distincts.

Voir aussi :

Tester des scénarios réels

  • Testez votre contenu réel sur le matériel cible, en utilisant Microsoft Edge DevTools pour rechercher et optimiser les problèmes de performances.

Voir aussi :

Performances du réseau et du chargement

La latence du réseau et la bande passante limitée peuvent entraîner des problèmes de performances perçus par l’utilisateur, en particulier lors du chargement de contenu web dans un contrôle WebView2.

Les bonnes pratiques suivantes se chevauchent avec le développement web général.

Utiliser la mise en cache et les workers de service

WebView2 prend en charge la mise en cache du navigateur.

  • Utilisez la mise en cache et les workers de service.

  • Servez les en-têtes de cache appropriés, afin que les demandes de ressources répétées utilisent des versions mises en cache.

  • Envisagez de pré-mettre en cache les fichiers statiques à l’aide d’un worker de service, pour l’accès hors connexion ; mais surveillez la taille du cache.

Voir aussi :

Vérifier les goulots d’étranglement réseau

Utilisez l’outil Réseau DevTools pour identifier les ressources lentes dans WebView2 ; Consultez Inspecter l’activité réseau.

Optimisez ou chargez de manière asynchrone des scripts ou des API tierces lents, selon les besoins.

Réduire les charges utiles initiales

Pour améliorer la vitesse perçue :

  • Gardez la charge utile initiale légère. Préférez d’abord envoyer du code HTML statique, car il charge, analyse et affiche généralement plus rapidement que JavaScript. Soyez prudent lors de l’utilisation initiale de JavaScript avec une infrastructure d’application monopage ; Une telle infrastructure charge généralement beaucoup de code au démarrage, ce qui peut retarder le rendu initial du contenu web.

    HTML charge, analyse et restitue très rapidement, plus rapidement que le temps nécessaire à JavaScript pour produire la même interface utilisateur. Avec certaines infrastructures JS d’application monopage, même si le code HTML initial de l’infrastructure est petit, l’ensemble du code de framework doit être téléchargé, analysé et exécuté avant que quoi que ce soit puisse être affiché.

  • Différer les composants lourds.

  • Images ou scripts à chargement différé après l’affichage de l’interface utilisateur initiale.

Voir aussi :

Communication entre le contrôle WebView2 et l’application hôte

Choisir le canal de communication approprié

WebView2 fournit diverses options de communication web-à-hôte et hôte à web.

  • Essayez d’utiliser des messages web plutôt que des objets hôtes. Les messages web ont tendance à être plus rapides que les objets hôtes, en raison de l’utilisation de la mémoire et du temps, en raison de la simplicité et de la fiabilité des messages web.

  • Utilisez des objets hôtes uniquement lorsque vous avez besoin de fonctionnalités que les messages web ne peuvent pas exprimer facilement, telles que :

    • API riches de type objet (méthodes, propriétés, événements) que vous souhaitez exposer directement à JavaScript.

    • Interactions avec état où la gestion du contexte côté hôte est plus simple que le passage de messages structurés d’un bout à l’autre.

    • Des flux de données volumineux ou binaires où la sérialisation répétée de charges utiles dans des messages web devient inefficace.

Les objets hôtes présentent les inconvénients suivants :

  • Les objets hôtes nécessitent le marshaling COM, qui peut introduire une instabilité si le graphique d’objets change ou n’est pas marshalé correctement.

  • Les objets hôtes sont généralement plus lents pour les appels bavards et fréquents par rapport à un seul lot WebMessage, car chaque méthode ou chaque accès à une propriété franchit la limite individuellement.

  • Les objets hôtes créent un couplage plus étroit entre le code web et le code hôte, ce qui réduit la portabilité.

Voir aussi :

Optimiser la communication

Implémentez la communication asynchrone par lots pour réduire la communication IPC et réduire la copie des données.

Voir aussi :

Outils de télémétrie et de profilage

La collecte de données est essentielle pour identifier et résoudre les problèmes de performances.

Voici des outils et des techniques de télémétrie pour WebView2.

Suivi ETW WebView2

Utilisez le WebView2.wprp profil Microsoft (Collecte d’une trace ETW) avec l’Enregistreur de performances Windows pour capturer et analyser des événements WebView2 détaillés, tels que les lancements de processus et les minutages de navigation.

Vous pouvez enregistrer les événements du fournisseur Edge/WebView2 à l’aide du suivi d’événements pour Windows (ETW) ; consultez Collecte d’une trace ETW.

Analysez les traces dans Windows Analyseur de performances pour les données de processeur, de disque et de mémoire.

Microsoft Edge DevTools

Utilisez Microsoft Edge DevTools pour surveiller le contenu et les processus WebView2, afin d’identifier les problèmes tels que les fuites élevées de processeur ou de mémoire.

Cliquez avec le bouton droit sur un contrôle WebView2 dans une application WebView2, puis sélectionnez Inspecter. Par exemple, cliquez avec le bouton droit sur l’exemple d’application win32 principal, puis cliquez sur Inspecter. DevTools s’ouvre dans une fenêtre de navigateur dédiée non attachée.

Dans DevTools, vous pouvez utiliser des outils tels que l’outil Mémoire et l’outil Performances :

Outil de performances dans Edge DevTools

Voir aussi :

Inspecter avec les outils de développement Edge

Utilisez edge://inspect, qui ouvre l’onglet Inspecter avec les outils de développement Edge , pour surveiller le contenu et les processus WebView2, afin d’identifier les problèmes tels que les fuites élevées de processeur ou de mémoire :

Inspecter avec les outils de développement Edge

Pour en savoir plus sur l’inspection d’un processus WebView2 à l’aide edge://inspectde , consultez Débogage à distance des applications WebView2 WinUI 2 (UWP).

Gestionnaire des tâches du navigateur

Utilisez le Gestionnaire des tâches du navigateur pour surveiller le contenu et les processus WebView2, afin d’identifier les problèmes tels que les fuites élevées de processeur ou de mémoire.

Consultez Surveiller l’utilisation de la mémoire en temps réel (Gestionnaire des tâches du navigateur).

Résolution des problèmes de performances des workflows

Lorsque des problèmes de performances surviennent dans une application WebView2, utilisez une approche structurée pour résoudre les problèmes, conformément aux stratégies suivantes.

Tester avec du contenu simple

Chargez une page HTML minimale.

  • Si les performances sont toujours lentes avec du contenu simple, examinez les facteurs d’initialisation du runtime ou d’application hôte.

  • Si les performances sont plus rapides avec du contenu simple, concentrez-vous sur l’optimisation de votre contenu web.

Voir aussi :

Vérifier la version du runtime WebView2

Vérifiez que vous exécutez la dernière version du runtime WebView2, et non une version obsolète ou une installation Edge de secours. Mettez à jour le runtime WebView2 en fonction des besoins.

Voir aussi :

Surveiller l’utilisation de la mémoire

Utilisez le Gestionnaire des tâches Windows pour case activée mémoire de processus WebView2.

Une croissance inhabituelle peut indiquer une fuite : utilisez des enregistrements WPR pour le déboguer davantage.

Voir aussi :

Comparer WebView2 avec Microsoft Edge

WebView2 utilise le même moteur de navigateur principal que Microsoft Edge. Validez le cas avec Microsoft Edge, ainsi qu’avec WebView2, pour isoler le problème.

Voir aussi

  • Last updated on