No mês passado, você deve ter notado que alguns recursos do Edge se tornaram mais rápidos e responsivos. Isso ocorre porque o Edge está em uma jornada para tornar todas as interações do usuário no navegador extremamente rápidas, começando com alguns de nossos recursos mais recentes e principais.
A partir do Edge 122, a IU do Browser Necessities agora é muito mais responsiva. A IU agora está 42% mais rápido para usuários do Edge e um enorme 76% mais rápido para aqueles que usam um dispositivo sem SSD ou com menos de 8 GB de RAM!
Favoritos é outro recurso do Edge que está obtendo melhorias na capacidade de resposta da interface do usuário no Edge 124. Quer os favoritos sejam expandidos ou recolhidos, a experiência deve ser 40% mais rápido.
E isso é só o topo do iceberg. Nos próximos meses, continuaremos a enviar melhorias de capacidade de resposta para muitos outros recursos do Edge, incluindo histórico, downloads, carteira e muito mais.
Adoraríamos que você experimentasse o Microsoft Edge e nos contasse o que você pensa. Conte-nos sobre sua experiência usando a ferramenta de suggestions no Edge: clique Configurações e mais (…) > Ajuda e comentários> Enviar comentários.
Proceed lendo para obter mais detalhes sobre como tornamos tudo isso possível.
Monitorando a capacidade de resposta da IU
As melhorias na capacidade de resposta da UI do Edge começaram com a compreensão do que vocês, nossos usuários, estavam vivenciando. O Edge monitora a capacidade de resposta da UI por meio de telemetria coletada das máquinas dos usuários finais. Fizemos essa coleção intencionalmente para todas as partes da UI do Edge, não apenas para as páginas da net que renderizamos. O que aprendemos com esses dados?
- A pesquisa indica que existem certas metas absolutas de capacidade de resposta que devem ser atendidas para que um usuário perceba a IU como rápida, e os dados mostraram que nossa IU poderia ser mais responsiva.
- Tivemos a oportunidade de melhorar a capacidade de resposta para dispositivos com menos recursos.
Estamos constantemente aprendendo mais sobre como podemos melhorar o desempenho da Edge UI e, ao usar esses dados, descobrimos algumas áreas de melhoria. Por exemplo, observamos que os pacotes de código usados por muitos de nossos componentes eram muito grandes. Percebemos que isso se devia a dois motivos principais:
- A forma como organizamos o código da UI no Edge não period modular o suficiente. As equipes que trabalharam em componentes diferentes compartilharam pacotes comuns mesmo quando isso não period estritamente necessário. Isso resultou em uma parte do código da IU tornando outra parte mais lenta, compartilhando coisas desnecessariamente.
- Muito do nosso código usava uma estrutura que dependia de JavaScript para renderizar a IU. Isso é conhecido como renderização do lado do cliente, que tem sido uma tendência well-liked entre os desenvolvedores net na última década porque ajudou os desenvolvedores net a serem mais produtivos e possibilitou experiências de UI mais dinâmicas.
Renderizando a UI da net como deveria ser
Por que estamos compartilhando esta notícia antiga? Afinal, muitas páginas da net são renderizadas no lado do cliente há anos. Bem, acontece que o JavaScript deve ser baixado, executado por meio de um compilador JIT (mesmo que você não o use) e, em seguida, executado, e tudo isso deve ser feito antes que qualquer JavaScript possa começar a renderizar a UI. Isso introduz muito atraso antes que os usuários possam ver a IU, especialmente em dispositivos de baixo custo.
Se você voltar na máquina do tempo antes da period da Internet 2.0, a forma como o conteúdo da net period renderizado period usando HTML e CSS. Isso geralmente é chamado de renderização no lado do servidor, pois o cliente obtém o conteúdo em um formato pronto para renderização. Os mecanismos de navegador modernos são muito rápidos na renderização desse conteúdo, desde que você não deixe o JavaScript atrapalhar.
Com base nessa constatação, nossas perguntas passaram a ser:
- Poderíamos manter a produtividade do desenvolvedor que as estruturas JavaScript nos proporcionaram enquanto geramos código que renderiza a interface do usuário rapidamente?
- O navegador poderia ser seu melhor cliente?
- Quão rápido poderíamos fazer as coisas se removêssemos essa estrutura e construíssemos nossa UI apenas usando a plataforma net?
As respostas a estas perguntas são Sim,SimeMuito rápido.
Apresentando WebUI 2.0
O resultado deste exercício é um projeto interno do Edge que chamamos de WebUI 2.0.
Neste projeto, construímos uma arquitetura de marcação totalmente nova que minimiza o tamanho de nossos pacotes de código e a quantidade de código JavaScript executado durante o caminho de inicialização da IU. Essa nova arquitetura de UI interna é mais modular e agora contamos com um repositório de componentes net ajustados para desempenho em mecanismos net modernos. Também criamos um conjunto de padrões de plataforma net que nos permitem fornecer novos recursos de navegador que permanecem dentro de nossa arquitetura de marcação inicial e que usam recursos ideais da plataforma net.
Browser Necessities é o primeiro recurso Edge que convertemos para testar a nova arquitetura e provar que o conceito funcionou, especialmente em todos os tipos de dispositivos. Estamos no processo de atualização de componentes da interface de usuário do Edge para WebUI 2.0 e você pode esperar ver mais recursos do navegador ficando muito mais responsivos ao longo do tempo.
Esperamos que mais websites comecem a se mover nessa direção de marcação inicial, pequenos pacotes e menos código JavaScript de renderização de UI. Com o tempo, planejamos tornar alguns de nossos pacotes de código aberto, para que todos os desenvolvedores possam se beneficiar. Finalmente, à medida que continuamos a melhorar o WebUI 2.0, estamos empenhados em encontrar oportunidades para melhorar ainda mais a própria plataforma net.
Esperamos que você aproveite esta experiência Edge atualizada!
