Práticas recomendadas de desempenho para aplicativos WebView2

Use as práticas a seguir para otimizar o tempo de inicialização, a memória, a CPU e o uso da rede do WebView2. Use essas ferramentas e fluxos de trabalho para solucionar problemas de desempenho.

A inserção do Microsoft Edge WebView2 em aplicativos do Windows habilita recursos modernos da Web. O WebView2 usa a arquitetura de vários processos do Edge, portanto, cada controle inicia vários processos do mecanismo do navegador que adicionam memória e sobrecarga de inicialização.

Conteúdo detalhado:

Identificar o tipo de gargalo de desempenho

Observe os sintomas da lentidão do desempenho para determinar se o problema é:

Usar o Evergreen Runtime

  • Sempre que possível, implante seu aplicativo com o Evergreen WebView2 Runtime. O Evergreen Runtime é atualizado automaticamente para obter as melhorias de desempenho e correções de segurança mais recentes. Mantenha o WebView2 Runtime perene (ou seja, atualizado), para preparar seu aplicativo para o futuro. Usar uma versão fixa corre o risco de perder otimizações recentes.

  • Se você precisar usar um tempo de execução fixo por motivos offline ou de compatibilidade, atualize-o regularmente depois de testar novos builds.

  • Teste seu aplicativo usando os canais de visualização mais recentes do WebView2 (Beta, Dev ou Canary) para se preparar para as próximas alterações. Muitos problemas de desempenho anteriores, como vazamentos de memória e alto uso de CPU, foram resolvidos em versões mais recentes do WebView2 Runtime.

Se as versões do Microsoft Edge e do WebView2 forem correspondentes, e o Microsoft Edge estiver em execução, os binários necessários do WebView2 já estarão na memória, melhorando o desempenho da inicialização.

Veja também:

Otimizar o desempenho da inicialização

Partida a frio (inicialização a frio)

Um gargalo de desempenho comum é o momento de criar um controle WebView2 e navegar até uma página da Web pela primeira vez. Em uma inicialização fria, o WebView2 deve ativar seus processos e caches de disco, o que pode introduzir um atraso perceptível (que pode variar de acordo com a complexidade do hardware e do conteúdo).

Para otimizar a inicialização, use as seguintes práticas recomendadas.

Não use o WebView2 para a interface inicial do usuário

  • Para renderizar telas iniciais ou caixas de diálogo simples, use telas XAML ou Win32 leves em vez de WebView2.

  • Evite renderizar telas iniciais ou caixas de diálogo simples com o WebView2, devido aos custos de inicialização e à contenção de recursos. Inicialize o WebView2 somente ao exibir conteúdo real da Web.

Veja também:

Otimizar a localização da Pasta de Dados do Usuário (UDF)

  • Mantenha a UDF na pasta de dados do aplicativo local padrão, para desempenho. Consulte Gerenciar pastas de dados do usuário.

  • Evite unidades lentas ou compartilhamentos de rede; Coloque os dados em um disco físico mais rápido.

Evitar instâncias redundantes do WebView2

Planeje sua interface do usuário para que você não crie mais controles WebView2 do que o necessário.

Por exemplo, se estiver navegando entre várias páginas da Web, talvez seja mais rápido reutilizar um único WebView2 e simplesmente navegar até uma nova URL, em vez de destruir e recriar um controle WebView2.

Veja também:

Uso de memória e gerenciamento de processos

Cada controle WebView2 cria seu próprio conjunto de processos, como navegador, renderizador e GPU. O uso de recursos geralmente cresce à medida que mais instâncias do WebView2 são criadas, com cada instância executando seu próprio conjunto de processos do navegador.

Uma instância do WebView2 usa memória com base na complexidade do conteúdo da Web e nos processos do navegador que ela cria. A execução de muitas instâncias do controle WebView2 pode sobrecarregar a memória do sistema.

Abaixo estão as práticas recomendadas para gerenciar e reduzir o volume de memória.

Compartilhar ambientes WebView2

  • Para economizar memória, use um CoreWebView2Environment em todos os controles WebView2 em um aplicativo, garantindo parâmetros consistentes para compartilhamento.

  • Reutilize o mesmo ambiente em interfaces com guias, em vez de criar vários ambientes.

Veja também:

Usar o compartilhamento de processo no nível do aplicativo

  • Se possível, use o compartilhamento de processos no nível do aplicativo.

    Vários aplicativos podem compartilhar um processo do navegador usando a mesma pasta de dados do usuário e CoreWebView2EnvironmentOptions. Isso reduz o uso de memória, mas requer um gerenciamento cuidadoso dos perfis e testes completos, devido à possível interferência entre aplicativos.

    Lembre-se de que, ao compartilhar uma pasta de dados do usuário (UDF), os dados subjacentes (como cookies, caches e bancos de dados) estão sendo compartilhados entre diferentes aplicativos.

Veja também:

Evitar objetos host de escopo grande

Se você usa AddHostObjectToScript para expor objetos .NET à Web, lembre-se do que esses objetos contêm na memória. Todo o objeto é efetivamente referenciado enquanto o contexto do script continuar a viver, o que pode impedir a coleta de lixo desse objeto no lado do .NET.

Não exponha um gráfico de objeto muito grande, se apenas uma pequena parte for necessária para scripts. Prefira criar objetos host estreitos e específicos para a finalidade, em vez de passar modelos de aplicativos completos. Por exemplo:

  • Exponha apenas as operações e os dados de que a página realmente precisa. Por exemplo, exponha um FileService objeto, em vez de todo AppContexto seu .

  • Envolva objetos complexos por trás de pequenas fachadas para evitar a exposição involuntária de hierarquias de objetos profundos.

  • Para coleções, forneça resultados filtrados ou paginados em vez de expor a estrutura de dados completa.

Quando a página que precisava do objeto desaparecer, chame CoreWebView2.RemoveHostObjectFromScript para liberar o grafo de objetos. Por exemplo, se você sair de uma página que estava usando um objeto host, remova esse objeto para evitar mantê-lo ativo nos bastidores.

Veja também:

Evitar vazamentos de memória

  • Remova os manipuladores de eventos nativos antes de descartar objetos WebView2, para evitar ciclos de referência e vazamentos.

  • Evite fechamentos que façam referência forte ao WebView2; Use referências fracas quando necessário.

  • Chamada WebView2.Dispose() para liberar objetos WebView2 quando eles não forem mais necessários.

Veja também:

Usar APIs de gerenciamento de memória

  • Defina MemoryUsageTargetLevel = CoreWebView2MemoryUsageTargetLevel.Low em exibições da Web inativas para reduzir o uso de memória - isso pode fazer com que o mecanismo do navegador descarte dados armazenados em cache ou troque memória para o disco. Quando a instância do WebView2 estiver ativa novamente, restaure o nível de destino para Normal, para obter desempenho total. Consulte Meta de uso de memória em Visão geral das APIs do WebView2.

  • Se a instância do WebView2 não for usada por um tempo, chame CoreWebView2.TrySuspendAsync() para suspender o processo de renderização, o que pausa os scripts e diminui ainda mais o uso de recursos. Retomar com Resume() quando necessário. Essas Try operações são de melhor esforço. Consulte Desempenho e depuração em Visão geral das APIs do WebView2.

Otimizar o conteúdo da Web

Atualizar periodicamente o WebView2

Desempenho de renderização e CPU

O WebView2 descarrega a renderização de conteúdo da Web para o mecanismo do navegador que o Edge usa, portanto, as características de desempenho são como executar um site no Edge.

As práticas a seguir garantem o uso eficiente da CPU e renderização suave.

Habilitar a aceleração de hardware

  • Não desabilite o uso da GPU pelo WebView2, para renderização (por meio do disable-gpu sinalizador), exceto quando você estiver solucionando problemas.

    Por padrão, o WebView2 usa a GPU para renderização. O uso da GPU pelo WebView2 é fundamental para o desempenho. Drivers de GPU e buffers adicionais devem ser alocados, o que requer memória adicional.

Confira também

Simplificar o conteúdo da Web

Otimize páginas usando as seguintes técnicas:

  • Limite o JavaScript pesado.

  • Debounce ou limitação de tarefas.

  • Use CSS (em vez de JavaScript) para animações.

  • Divida scripts longos para manter a interface do usuário responsiva.

  • Use o DevTools do Microsoft Edge para identificar gargalos.

  • Use a otimização típica da Web: evite a sobrecarga excessiva de layout, em que um script alterna entre a leitura e a gravação de propriedades DOM, causando vários refluxos.

Veja também:

Reduzir a comunicação desnecessária

  • Reduza a comunicação desnecessária entre o aplicativo host e o conteúdo da Web hospedado no WebView2. Isso evita a comunicação excessiva entre processos, juntamente com a sobrecarga que a acompanha. Consulte Interoperabilidade de código nativo e da Web.

  • Envie mensagens em lote sempre que possível, pois a passagem frequente de mensagens pode aumentar o uso da CPU.

Gerenciar prioridade do processo

  • Se o aplicativo tiver uma carga de trabalho nativa pesada, atribua prioridades de thread com cuidado, para evitar a falta de threads do WebView2. O WebView2 cria processos de renderização separados.

Veja também:

Testar cenários reais

  • Teste seu conteúdo real no hardware de destino, usando o DevTools do Microsoft Edge para localizar e otimizar problemas de desempenho.

Veja também:

Desempenho de rede e carregamento

A latência de rede e a largura de banda limitada podem causar problemas de desempenho percebidos pelo usuário, especialmente ao carregar conteúdo da Web em um controle WebView2.

As práticas recomendadas a seguir se sobrepõem ao desenvolvimento geral da Web.

Utilizar trabalho de serviço e cache

O WebView2 é compatível com o cache do navegador.

  • Use o cache e os trabalhadores de serviço.

  • Forneça cabeçalhos de cache adequados, para que solicitações repetidas de recursos usem versões armazenadas em cache.

  • Considere o pré-cache de arquivos estáticos usando um trabalho de serviço, para acesso offline; mas monitore o tamanho do cache.

Veja também:

Verificar gargalos de rede

Use a ferramenta DevTools Network para identificar recursos lentos no WebView2; consulte Inspecionar atividade de rede.

Otimize ou carregue de forma assíncrona scripts ou APIs lentos de terceiros, conforme necessário.

Reduzir os payloads iniciais

Para melhorar a velocidade percebida:

  • Mantenha a carga inicial leve. Prefiro enviar HTML estático inicialmente, pois ele geralmente carrega, analisa e renderiza mais rápido que o JavaScript. Seja cauteloso ao usar inicialmente o JavaScript junto com uma estrutura de aplicativo de página única; Essa estrutura normalmente carrega muito código na inicialização, o que pode atrasar a renderização inicial do conteúdo da Web.

    O HTML carrega, analisa e renderiza muito rápido - mais rápido do que o tempo que o JavaScript levaria para produzir a mesma interface do usuário. Com algumas estruturas JS de aplicativo de página única, mesmo que o HTML inicial da estrutura seja pequeno, todo o código da estrutura deve ser baixado, analisado e executado, antes que qualquer coisa possa ser exibida.

  • Adiar componentes pesados.

  • Carregue lentamente imagens ou scripts depois que a interface do usuário inicial for exibida.

Veja também:

Comunicação entre o controle WebView2 e o aplicativo host

Escolha o canal de comunicação certo

O WebView2 fornece várias opções de comunicação web-a-host e host-to-web.

  • Tente usar mensagens da Web, em vez de objetos host. As mensagens da Web tendem a ser mais rápidas do que os objetos host, devido ao uso de memória e ao tempo, devido à simplicidade e confiabilidade das mensagens da web.

  • Use objetos host somente quando precisar de recursos que as mensagens da Web não possam expressar com facilidade, como:

    • APIs avançadas e semelhantes a objetos (métodos, propriedades, eventos) que você deseja expor diretamente ao JavaScript.

    • Interações com estado em que manter o contexto do lado do host é mais simples do que passar mensagens estruturadas para frente e para trás.

    • Fluxos de dados grandes ou binários em que serializar repetidamente cargas úteis em mensagens da Web se torna ineficiente.

Os objetos host têm as seguintes desvantagens:

  • Os objetos host exigem marshalling COM, que pode introduzir instabilidade se o grafo do objeto for alterado ou não for empacotado corretamente.

  • Os objetos host geralmente são mais lentos para chamadas frequentes e tagarelas em comparação com um único lote WebMessage, porque cada método ou acesso de propriedade cruza o limite individualmente.

  • Os objetos host criam um acoplamento mais estreito entre o código da Web e o código do host, reduzindo a portabilidade.

Veja também:

Otimizar a comunicação

Implemente a comunicação assíncrona e em lote para minimizar a comunicação IPC e reduzir a cópia de dados.

Veja também:

Ferramentas de telemetria e criação de perfil

A coleta de dados é fundamental para identificar e corrigir problemas de desempenho.

A seguir estão ferramentas e técnicas de telemetria para o WebView2.

Rastreamento ETW do WebView2

Use o perfil da Microsoft (coletando um rastreamento ETW) com o Gravador de Desempenho do Windows para capturar e analisar eventos detalhados do WebView2.wprp WebView2, como inicializações de processos e tempos de navegação.

Você pode registrar eventos do provedor Edge/WebView2 usando o ETW (Rastreamento de Eventos para Windows); consulte Reunindo um Rastreamento ETW.

Analise rastreamentos no Windows Performance Analyzer para dados de CPU, disco e memória.

Microsoft Edge DevTools

Use o DevTools do Microsoft Edge para monitorar o conteúdo e os processos do WebView2, a fim de identificar problemas como altos vazamentos de CPU ou memória.

Clique com o botão direito em um controle WebView2 em um aplicativo WebView2 e selecione Inspecionar. Por exemplo, clique com o botão direito do mouse no aplicativo de exemplo principal Win32 e clique em Inspecionar. O DevTools é aberto em uma janela de navegador dedicada e desencaixada.

No DevTools, você pode usar ferramentas como a ferramenta Memória e a ferramenta Desempenho :

Ferramenta Desempenho no Edge DevTools

Veja também:

Inspecionar com as Ferramentas de Desenvolvedor do Edge

Use edge://inspecto , que abre a guia Inspecionar com Ferramentas de Desenvolvedor do Edge , para monitorar o conteúdo e os processos do WebView2 e identificar problemas como altos vazamentos de CPU ou memória:

Inspecionar com as Ferramentas de Desenvolvedor do Edge

Para saber mais sobre como inspecionar um processo WebView2 usando edge://inspect, consulte Área de trabalho remota WebView2 WinUI 2 (UWP) aplicativos.

Gerenciador de tarefas do navegador

Use o Gerenciador de Tarefas do Navegador para monitorar o conteúdo e os processos do WebView2, para identificar problemas como altos vazamentos de CPU ou memória.

Consulte Monitorar o uso de memória em tempo real (Gerenciador de Tarefas do Navegador).

Solução de problemas de fluxos de trabalho para problemas de desempenho

Quando surgirem problemas de desempenho em um aplicativo WebView2, use uma abordagem estruturada para solucionar problemas, de acordo com as estratégias a seguir.

Teste com conteúdo simples

Carregue uma página HTML mínima.

  • Se o desempenho ainda estiver lento com conteúdo simples, investigue fatores de inicialização de tempo de execução ou de aplicativo host.

  • Se o desempenho for mais rápido com conteúdo simples, concentre-se em otimizar o conteúdo da Web.

Veja também:

Verificar a versão do WebView2 Runtime

Verifique se você está executando o WebView2 Runtime mais recente, não uma versão desatualizada ou instalação alternativa do Edge. Atualize o WebView2 Runtime conforme necessário.

Veja também:

Monitorar o uso da memória

Use o Gerenciador de Tarefas do Windows para marcar a memória de processo do WebView2.

Um crescimento incomum pode indicar um vazamento - use gravações WPR para depurar isso ainda mais.

Veja também:

Compare o WebView2 com o Microsoft Edge

O WebView2 usa o mesmo mecanismo de navegador principal do Microsoft Edge. Valide o caso com o Microsoft Edge, bem como com o WebView2, para isolar o problema.

Confira também

  • Last updated on