Otimização de aplicações angulares

Angular é a estrutura de desenvolvimento de aplicativos da Web de página única mais popular, embora isso não signifique que os aplicativos Angular possam conter apenas uma página. Usando essa estrutura, você pode criar sites que consistem em dezenas de páginas. A versão mais recente do Angular, graças aos esforços da equipe de desenvolvimento e da comunidade de entusiastas, está bem otimizada. No entanto, quando se trata de um aplicativo específico, não se deve esquecer algumas coisas que afetam seu desempenho.



O material, cuja tradução publicamos hoje, revelará seis áreas de otimização de aplicativos Angular.

1. Carregamento lento e otimização do pacote principal

Se o carregamento lento não for usado ao preparar a versão de produção do aplicativo, provavelmente na pasta dist você verá os seguintes arquivos.

 polyfills.js scripts.js runtime.js styles.css main.js 

O arquivo polyfills.js permite garantir que um aplicativo gravado usando os recursos mais recentes da tecnologia da Web seja compatível com vários navegadores.

O arquivo script.js contém os scripts descritos na seção scripts do arquivo angular.json . Aqui está um exemplo simples dessa seção.

 "scripts": [  "myScript.js", ] 

O arquivo runtime.js é o carregador do Webpack. Ele contém as ferramentas Webpack necessárias para baixar outros arquivos.

O arquivo styles.css contém os estilos declarados na seção angular.json arquivo angular.json . Aqui está um exemplo desta seção.

 "styles": [ "src/styles.css", "src/my-custom.css" ], 

O arquivo main.js armazena todo o código do aplicativo, incluindo componentes (código TS, HTML e CSS), pipelines, diretivas, serviços e módulos importados (incluindo módulos de terceiros).

À medida que o aplicativo cresce e se main.j tamanho do arquivo main.j s main.j . Isso pode se transformar em um problema, porque, para formar uma página, o navegador, além de resolver outras tarefas na visualização de dados, precisa baixar e analisar o arquivo main.js Se esse arquivo for grande o suficiente, seu processamento será uma tarefa assustadora, não apenas para dispositivos móveis, mas também para navegadores de desktop.

A maneira mais fácil de resolver esse problema é dividindo o aplicativo em vários módulos, que usam a técnica de carregamento lento. Com essa abordagem, o Angular gera um arquivo separado para cada módulo, que não será baixado até que seja necessário (geralmente ao ativar uma determinada rota).

Para demonstrar a aplicação da técnica de carregamento lento, dois componentes foram criados - app.component e second.component . Ambos estão no módulo app.module , o carregamento lento não é aplicado ao trabalhar com eles.

O componente app.component extremamente simples. Ele exibe dois botões, um dos quais é responsável por mudar para o second.component e o segundo leva de volta ao app.component .


Component App

O modelo do Second componente contém um pedaço muito grande de texto com um volume de aproximadamente 1 MB.


Segundo componente

Como a técnica de carregamento lento não é aplicada aqui, nosso aplicativo terá um grande arquivo main.js contendo o código app.component e second.component .

Se você abrir as ferramentas de desenvolvedor do Chrome e olhar para a guia Rede, poderá estimar o tamanho do arquivo main.js Ou seja, é 1,3 Mb.


Analisando tamanhos de arquivo com as Ferramentas do desenvolvedor do Chrome

O problema aqui é que, na maioria das vezes, ao trabalhar com o nosso projeto, o usuário está na página principal e não em outra página; portanto, o download de todo o código como um único arquivo não é uma boa ideia. O código do segundo componente pode ser retirado em um módulo separado, que será carregado apenas se o usuário for para a página correspondente. Isso se traduz em uma redução significativa no arquivo main.js , que fornece uma primeira carga muito rápida na página principal do site.

Ao usar a técnica de carregamento lento, após a conclusão do processo de criação do projeto, um arquivo como 4.386205799sfghe4.js será criado. É aqui que o código será armazenado e não será carregado quando você carregar o site pela primeira vez. Como resultado, se você agora abrir o site e analisá-lo, os tamanhos do main.js serão de apenas 266 Kb.


Downsizing main.js

Um arquivo adicional grande de 1 MB é baixado somente depois de ir para a página correspondente.


Baixar arquivo adicional

Aplicamos carregamento lento, mas não podemos dizer que essa solução nos convém completamente. O fato é que essa abordagem reduz a velocidade da primeira transição do usuário para a página, o que requer um arquivo grande separado para saída. Felizmente, o Angular fornece um meio para resolver esse problema. Ou seja, estamos falando sobre a tecnologia PreloadingStrategy .

Usando-o, podemos dizer à estrutura que, depois que o módulo principal (arquivo main.js ) é carregado e processado, ele main.js em segundo plano outros módulos. Como resultado, quando o usuário acessa uma página que anteriormente exigia a exibição de um arquivo grande, verifica-se que o arquivo já foi baixado. Aqui está um código de exemplo que pré-carrega todos os módulos.

 import { PreloadAllModules, RouterModule } from '@angular/router'; RouterModule.forRoot( [ {   path: 'second',   loadChildren: './second/second.module#SecondModule' } ], {preloadingStrategy: PreloadAllModules}) 

Aplicando carregamento lento ao otimizar aplicativos Angular, é recomendável esforçar-se para dividir o projeto em tantos módulos quanto possível. Além disso, você precisa prestar atenção ao pré-carregamento. Isso tornará possível que o arquivo main.js seja pequeno, o que significa carregar e exibir mais rapidamente a página principal do projeto.

2. Análise de pacote configurável usando o Webpack Bundle Analyzer

Se mesmo depois de dividir a lógica do projeto em vários módulos, o main.js ainda é muito grande (para aplicativos pequenos e médios, o autor deste material sugere que o arquivo tenha 1 MB de tamanho), você pode continuar otimizando o aplicativo usando o Webpack Bundle Analyzer. Este pacote npm permite visualizar os resultados do Webpack em uma estrutura em árvore que suporta zoom. Para usar o Webpack Bundle Analyzer, instale-o em um projeto Angular como uma dependência de desenvolvimento.

 npm install --save-dev webpack-bundle-analyzer 

Em seguida, modificamos a seção de script do arquivo package.json adicionando o texto a seguir.

 "bundle-report": "ng build --prod --stats-json && webpack-bundle-analyzer dist/stats.json" 

Observe que o endereço do arquivo dist/stats.json pode ser diferente no seu projeto. Por exemplo, se você concluiu os arquivos de pacote configurável na pasta dist/browser , será necessário reescrever a linha acima desta forma: dist/browser/stats.json .

Agora execute o analisador.

 npm run bundle-report 

Após a execução deste comando, o conjunto de produção do aplicativo será gerado e as estatísticas de cada pacote configurável serão exibidas. Veja como é o resultado da visualização desses dados.


Análise de projeto usando o Webpack Bundle Analyzer

Agora você pode analisar a composição de cada pacote. Esta é uma ferramenta muito útil que permite identificar dependências que você pode prescindir.

3. Criando vários módulos pequenos para compartilhamento

Módulos que compartilham partes diferentes do aplicativo contribuem para a implementação do princípio DRY , mas às vezes até esses módulos, à medida que o aplicativo se desenvolve, se tornam cada vez mais. Por exemplo, se tivermos um determinado módulo SharedModule que contém muitos outros módulos, componentes, pipelines, a importação de um módulo para app.module aumentará o tamanho do pacote main.js pois essa mudança não levará apenas à importação do que o main.js precisa, mas também tudo o que está no SharedModule . Para evitar essa situação, você pode criar outro módulo, algo como HomeSharedModule , projetado para ser compartilhado pelo módulo principal e seus componentes.

A presença no projeto de vários módulos destinados ao compartilhamento é melhor do que a presença de apenas um desses módulos, geralmente com tamanhos grandes.

4. Usando a técnica de carregamento lento para imagens que não são visíveis na página

Quando você carrega a página principal do aplicativo pela primeira vez, pode ser que ele contenha imagens que não são visíveis para o usuário (estão fora da área de visualização). Para vê-los, você precisa rolar a página. Mas essas imagens invisíveis são carregadas quando a página é carregada. Se houver muitos deles, isso afetará a velocidade de carregamento da página. Para lidar com esse problema, você pode aplicar a técnica de carregamento lento às imagens, carregando somente quando o usuário as alcançar. Existe uma ferramenta JS útil, o Intersection Observer , que facilita a implementação do carregamento lento de imagens. Além disso, para reutilizar, com base nisso, você pode criar uma diretiva apropriada. Detalhes sobre isso podem ser encontrados aqui .

5. Usando rolagem virtual para listas longas

A sétima versão do Angular tem a capacidade de usar a rolagem virtual . Essa tecnologia carrega elementos no DOM e os descarrega com base em quanto da lista é visível para o usuário. Isso acelera bastante o trabalho de aplicativos que usam listas longas.


Somente itens de lista visíveis são exibidos na página.

6. Usando a estratégia FOUT para trabalhar com fontes em vez da estratégia FOIT

Muitos sites usam fontes personalizadas. Eles geralmente parecem muito atraentes, mas seu aplicativo cria uma carga adicional no navegador, pois ele precisa baixar essas fontes e prepará-las para o trabalho. Ao usar fontes não padrão, digamos, baixadas de um serviço de terceiros como o Google Fonts, os dois cenários a seguir são possíveis:

1. O navegador baixa a fonte, processa-a e só então exibe o texto. Até que a fonte esteja pronta para uso, o texto digitado nessa fonte ficará invisível. Isso é chamado de FOIT (Flash de texto invisível).
2. O navegador exibe inicialmente o texto usando uma fonte padrão, enquanto carrega uma fonte externa. Quando essa fonte está pronta para uso, a fonte padrão muda para essa fonte específica. Como resultado, verifica-se que o texto na página será exibido em uma fonte padrão até que uma fonte especial seja carregada, após o que o texto será exibido novamente, mas com uma nova fonte. Isso é chamado de FOUT (Flash de texto sem estilo).

A maioria dos navegadores usa fontes não padrão usando a estratégia FOIT; a estratégia FOUT é usada apenas no Internet Explorer. Para usar FOUT em vez de FOIT, você pode usar o descritor de font-display de @font-face para @font-face e informar ao navegador se queremos que o texto seja exibido primeiro em uma fonte padrão e depois na nossa, ou ficaremos satisfeitos com um certo período de invisibilidade do texto. . Se você está interessado no assunto das fontes, dê uma olhada neste material. Em particular, aqui você pode encontrar informações sobre os recursos das fontes e recomendações sobre a escolha das estratégias FOIT ou FOUT.

Sumário

Aqui vimos várias técnicas para otimizar aplicações angulares. De fato, existem muitos mais. Em particular, estamos falando sobre renderização de servidor, uso de trabalhadores de serviço e páginas AMP. A conveniência da otimização e a escolha de seus métodos dependem de um projeto específico - de suas características e objetivos.

Caros leitores! Quais abordagens você usa para otimizar aplicativos Angular?