Projeto Angular - Lazy loading e code splitting

[magnolemos]

Galera, vou iniciar um projeto grande que ainda não está definido se será React ou Angular.
Conheço razoável o React e estou estudando o Angular.

Hoje aprendi um pouco sobre o lazy loading do Angular, achei sensacional, porém, um pouco trabalhoso separar as rotas para faze-lo. Nos projetos que atuei em React era apenas um arquivo de rota. Nenhum projeto grande, logo, nunca foi um problema.

Sendo assim, gostaria de saber sobre as experiências de vocês. Os projetos em Angular geram bundles muito grande? ( no meu estudo o main está com 380kb, gzip deve dá uns 80kb. Fazer o lazy load para carregar 70kb ao invés de 80kb não me parece válido).

Caso queria contar sua experiência em projeto Angular, pontos positivos negativos, ficaria muito grato também.

Obs: rxjs é lindo

[GustavoCostaW]

Como você mesmo já sabe que o projeto vai ser grande por que não usar? Além dos beneficios de performance você irá ser forçado a criar features modules criando um projeto mais desacoplado e testável, recomendo fazer lazy loading sim! Eu só tive um problema absurdo com essa issue aqui angular/angular#14324 por isso tive que abortar no projeto que trabalhei, se isso não pode te afetar, go ahead.

[magnolemos]

Cara, sendo honesto, é receio de fazer a equipe seguir um caminho mais trabalhoso e que o resultado seja ínfimo. Por isso gostaria de saber sobre a experiencia de alguém.

Muito obrigado por compartilhar o problema que você teve, vou analisar ele aqui. Valeu demais mano :D

[synga]

Cara, meu bundle é grande, quase 1mb com build --prod --aot e é o Angular 5.2, segue ai o console

chunk {0} 0.6ee92feb132406541e2f.chunk.js (common) 136 kB  [rendered]
chunk {1} 1.03ed7ca8fea960cb073b.chunk.js () 528 kB  [rendered]
chunk {2} 2.db13d6931790cce41e71.chunk.js () 44.4 kB  [rendered]
chunk {3} 3.5e68644a2ab04196a0c7.chunk.js () 10.5 kB  [rendered]
chunk {4} 4.87eb5063a667d3b060fd.chunk.js () 36.8 kB  [rendered]
chunk {5} 5.bb1874cdb0b27b6d6c55.chunk.js () 47.4 kB  [rendered]
chunk {6} 6.81dc52d9f8677689b92a.chunk.js () 44.1 kB  [rendered]
chunk {7} 7.13e914f29395eb7ee3db.chunk.js () 59.5 kB  [rendered]
chunk {8} 8.22d1bee2a3aa93cc26a3.chunk.js () 32 kB  [rendered]
chunk {9} 9.7db3049cd15535be9f96.chunk.js () 16.4 kB  [rendered]
chunk {10} 10.89cfaa7f5d9ef300e85d.chunk.js () 52.2 kB  [rendered]
chunk {11} 11.50e8f901a3086ae83e41.chunk.js () 40.1 kB  [rendered]
chunk {12} 12.46ffc8cae3352acdb349.chunk.js () 48.5 kB  [rendered]
chunk {13} 13.2287e61dbb2a3349c9a3.chunk.js () 48.9 kB  [rendered]
chunk {14} 14.0bb2e48ea74402c06d5f.chunk.js () 44 kB  [rendered]
chunk {15} 15.7e1d356f1c05ff867fa4.chunk.js () 23.9 kB  [rendered]
chunk {16} 16.0b3407ce933b6c9d650f.chunk.js () 82.9 kB  [rendered]
chunk {17} 17.4097cd9b0776eea6df88.chunk.js () 98.3 kB  [rendered]
chunk {18} 18.7aa2ff2f99cc84815353.chunk.js () 24.7 kB  [rendered]
chunk {19} 19.02a6778cdb9ec91e97d7.chunk.js () 30.7 kB  [rendered]
chunk {20} 20.33a4698d58785137a959.chunk.js () 20.4 kB  [rendered]
chunk {21} 21.834f8ad29999a7009e65.chunk.js () 54.6 kB  [rendered]
chunk {22} main.1b67c29f93af9e502d30.bundle.js (main) 904 kB [initial] [rendered]
chunk {23} polyfills.0455bd23e9c49f8dca9a.bundle.js (polyfills) 59.8 kB [initial] [rendered]
chunk {24} styles.0060010032547bd86f82.bundle.css (styles) 10.6 kB [initial] [rendered]
chunk {25} inline.665d2e1002ed400f8582.bundle.js (inline) 1.93 kB [entry] [rendered]

Da pra ver que o main ta grande, mas se não me engano o projeto puxa umas coisas que precisam ser inicializadas nesse main e também é um projeto grande, uma baita dashboard. Inicializa rápido, precisava fazer um teste aqui passar num lighthouse ou algo do tipo pra te informar números exatos, mas os clientes gostam.

Agora comparar com o react já não sei dizer por que nunca trampei com o ele

[felipefialho]

@magnolemos Fala Magno, beleza?

Estou usando Angular desde a versão 2 beta, e de fato as melhorias são absurdas desde então. A performance foi muito o foco da equipe de desenvolvimento do Angular e acho que estão fazendo um ótimo trabalho.

O Angular, por ser um framework, de fato tem um tamanho maior que libs como React, mas claro, sendo modularizado você pode ou não carregar as coisas.

É super válido fazer lazyload, indicado inclusive. Você vai deixar a main mais leve e carregar o resto sob demanda, a diferença no carregamendo das coisas é perceptível.

Vou aproveitar para chamar o @willgm e a @loiane na conversa, eles são com certeza das maiores referencias do mundo no assunto e podem ajudar por aqui 😄

[loiane]

Oi pessoal, vlw pela tag @lfeh!

Num projeto grande, é normal ter o bundle main com até 2Mb. Mais que isso é preocupante. Então se o seu está com 1Mb até agora, excelente!

O @synga deu a dica de usar build --prod --aot, eu curto adicionar build --prod --aot --build-optimizer. Esse build é mais demorado (esse é o ponto ruim, demora mais pra gerar o build de prod), mas faz uma análise do código e remove as coisas que você não tá usando (faz o famoso tree shaking). O AOT é importante, pq gera código pronto pra ser executado pelo browser, então já ajuda um pouco também.

Quanto aos módulos do angular, o fato de ser separado é por conta de segurança. Não teria como vc descobrir todas as rotas da aplicação, teria que ter acesso ou obter a informação de alguma forma. Tudo bem que front-end é apenas casca, mas ter um pouquinho de segurança ajuda também. Então você pode usar as guardas de rotas (route guards) e validar se o usuário pode acessar a rota ou até mesmo se o usuário vai conseguir carregar o bundle na memória.

Isso também facilita na questão de projetos grandes, pois você pode quebrar um módulo em sub-módulos e assim vai. Uma funcionalidade que curto bastante (Angular v6+) é o CLI bundle budget do angular.json - esse é um exemplo do vendor bundle (arquivos de terceiros):

{
  "configurations": {
    "production": {
      "budgets": [
        {
          "type": "bundle",
          "name": "vendor",
          "baseline": "1Mb",
          "warning": "2Mb",
          "error": "3Mb"
        }
      ]
    }
  }
}

Essa config é um array e você pode definir por bundle (main, vendor - que serão os maiores), e um genérico pros outros (meu error nesse caso vai até 250Kb dependendo do tamanho do módulo).

Todos esses passos, além de outros (o @GustavoCostaW tem uma palestra bem legal sobre isso) ajuda bastante na performance.

Dá um trabalhinho pra fazer tudo isso, mas até hoje não tive problemas de performance nas apps (aprox 80 módulos e crescendo). E depois que vc se acostuma a criar vários módulos, vai por osmose rs. A pior parte pra mim é o build ser mais demorado - mas aí deixa tudo num CI que fica tranquilo.

Claro que o design do back-end também conta, se existir algum gargalo no back, não adianta ter o front mais performático que vai ter problemas do mesmo jeito.

Numa versão futura vai entrar o projeto Ivy no Angular, que vai diminuir o bundle. No hello world tem resultado significativo, mas em apps normais, diminui, mas não é nenhum milagre (como no hello world). Porém, vai ser de grande ajuda no futuro para ajudar a diminuir o tamanho do bundle um pouco mais.

[GustavoCostaW]

Muito obrigado @loiane pela menção! Ótima dica essa do bundle budget, essa minha palestra foi gravada e está aqui:

Video:
Angular Extreme performance - Gustavo Costa
https://www.youtube.com/watch?v=4A3h7OipEUQ

Slides:
https://www.slideshare.net/gustavocostaw/angular-extreme-performance

[magnolemos]

Galera, muito obrigado por tanta informação bacana e tão rápido. Vocês são demais!
@synga, muito obrigado por compartilhar o console. Estou mais tranquilo agora, estava com medo de crescer demais.
Também não conhecia o --aot, valeu mesmo!

@lfeh, valeu demais cara! Vou conversar com a equipe aqui para gente fazer. Da uma segurança bacana com a opinião de alguém que pegou o framework desde o inicio e com a experiencia que você tem.

@loiane, muito obrigado por todo conhecimento compartilhado por você. Na época da faculdade aprendi java com você. Há alguns anos fiz um app com cordova, com ajuda do seu curso. Hoje estou aprendendo Angular com sua ajuda também. Você é essencial para minha carreira. Obrigado mesmo!

"Quanto aos módulos do angular, o fato de ser separado é por conta de segurança." Não tinha pensado por esse lado, faz todo sentido mesmo.

" Uma funcionalidade que curto bastante (Angular v6+) é o CLI bundle budget do angular.json - esse é um exemplo do vendor bundle (arquivos de terceiros)" Não fazia ideai dessa funcionalidade, bem legal!

Dá um trabalhinho pra fazer tudo isso, mas até hoje não tive problemas de performance nas apps (aprox 80 módulos e crescendo). Bacana demais, é um case massa, que mostra que vale o trabalho.

Vou vê o vídeo aqui agora. Valeu mesmo Loiane = ).

@GustavoCostaW , muito obrigado pela palestra e por disponibilizar, verei agora!

[felipefialho]

@loiane Impressionante como aprendo MUITO cada vez que vejo qualquer interação sua pela internet, você é incrivel!

Desconhecia essa possibilidade de definir budgets e acabei de implementar aqui, fantástico para controle do projeto.

Aproveitando, uma boa dica para verificar o tamanho dos módulos (isso no Angular ou não) é usar o webpack-bundle-analyzer e tomar as medidas de resolução a partir disso.

[lucashfreitas]

Tive que tomar essa decisão a pouco tempo atras pra um projeto de grande porte na empresa em que trabalho. Foi o primeiro projeto que eu peguei pra fazer em Angular, as outras aplicações SPA que desenvolvi fiz em React. Estou utilizando bastante modularização, lazy loading e tambèm fazendo a build da como a @loiane mencionou e a aplicação està bastante ràpida.

Estou utilizando bastante a separação de mòdulos, a aplicacao jà esta enorme e tem 91 mòdulos no momento (È um sistema com bastante telas e funcionalidades, e basicamente agrupei cada funcionalidade/conjunto de telas em modulos diferente, e todos esses mòdulos estāo sendo carregados utilizando lazy loading. (E todos possuem guards associados pra reforçar a segurança no front-end.

Ainda tem algumas otimizaçōes para serem feitas, principalmente nos imports, mas o que posso falar è que apesar de o sistema estar relativamente grande, a perfomance està boa e por enquanto ta bem tranquilo de dar manutenção e adicionar funcionalidade.

Nao tenho taaaaaanta experiencia com React, mas a primeira experiencia que estou tendo com o Angular 6/7 està sendo fantàstica e a produtividade tambèm. Imaginando a mesma aplicacao sendo feita em React, penso que seria um pouco mais demorado pra desenvolver. Mas isso è uma opiniao pessoal!

Enfim, deu bastante certo pra esse projeto e pretendo continuar seguindo e estudando angular por um bom tempo! =)

[magnolemos]

@lucashfreitas , muito obrigado por compartilhar sua experiência, é um case bem massa.

Com a experiencia que tenho tenho em React e o conhecimento que estou adquirindo em Angular, eu só usaria o React para Projetos pequeno/médio também.

[rubenmarcus]

@magnolemos

aqui no modulo principal da minha aplicação coloquei esse código tambem:

@NgModule({
  imports: [RouterModule.forRoot(appRoutes, {
    preloadingStrategy: PreloadAllModules,
    onSameUrlNavigation: 'reload',
  })],

Porque o PreloadAllModules?

o primeiro load da aplicação demora mais, mas depois fica tudo instantaneo.

algumas referências:

https://coryrylan.com/blog/custom-preloading-and-lazy-loading-strategies-with-angular
https://angular.io/api/router/PreloadAllModules

[felipefialho]

@rubenmarcus não conhecia essa técnica, vou dar uma olhada

[rubenmarcus]

Mais um sobre o assunto:
https://medium.com/@adrianfaciu/custom-preloading-strategy-for-angular-modules-b3b5c873681a

[magnolemos]

@rubenmarcus , que sensacional cara. Muito útil e bem simples de aplicar. Valeu demais pela dica!!!

[rubenmarcus]

Falando mais sobre performance no Angular..

https://medium.com/@spp020/44-quick-tips-to-fine-tune-angular-performance-9f5768f5d945

Eu tenho um problema bem grande porque usamos o angular 5.2 na nossa aplicação, e já está na versão 7. Mudou bastante coisa, inclusive o tamanho dos bundles e minificação, só que por ter muito script RxJS na aplicação, o que muda bastante a estrutura, ainda não tive tempo de fazer essa refatoração.

Uma refatoração que fiz e deu certo foi usar resolves pra chamadas de api

eu tenho o serviço http, e ai eu chamava ele em cada componente do meu modulo, mas ai com o resolve vc faz a chamada uma vez só ,e ai da um load no data nos componentes q precisa
https://angular.io/api/router/Resolve
https://alligator.io/angular/route-resolvers/

[rubenmarcus]

https://github.com/mgechev/angular-performance-checklist

[magnolemos]

Legal demais @rubenmarcus.
Você usa o ngrx para gerenciar os estados?

[rubenmarcus]

na real a gente só usa o rxjs/Rx , com o subscription e o observable

[magnolemos]

Bacana. Eu to querendo usar no projeto aqui. Vim do React e o Redux ajudava muito. Mas antes vou procurar algum projeto open pra saber como a galera faz.

[brunodesde1987]

Eu tenho um problema bem grande porque usamos o angular 5.2 na nossa aplicação, e já está na versão 7. Mudou bastante coisa, inclusive o tamanho dos bundles e minificação, só que por ter muito script RxJS na aplicação, o que muda bastante a estrutura, ainda não tive tempo de fazer essa refatoração.

@rubenmarcus
Você conhece essa página? https://update.angular.io/

Lá tem uma etapa que é indicado uma ferramenta para fazer a migração automatizada do rxjs:
https://github.com/ReactiveX/rxjs-tslint

Fiz a migração da 5 pra 6 e precisei fazer algumas atualizações manuais mas no geral foi tranquilo. O que tive problema foram outros pacotes que eram incompatíveis com a versão do Angular mas no final deu tudo certo.

Edit: Um detalhe que havia esquecido é que as configurações de environment / build mudaram e apanhei um pouco para colocar tudo em ordem.

---

Aproveitando, gostaria de agradecer a todos que contribuíram nessa issue pois ela está bem interessante com bastante conteúdo e com certeza vai ajudar todos nós.

[rubenmarcus]

@solutweb eu vi , vou tentar fazer essa semana , mas tem muito serviço / componente que to usando o rx js e tb tem coisas depreciadas, eu tava meio assustado pq meu modulo web estava com 3.5mb mas é em dev, em prod, está com 1.2mb o modulo main, a aplicação apesar de ter 110 componentes e uns 20 modulos, nao está tao grande assim.

Mas eu quero atualizar pra ultima versao do Angular e ver como fica mais rapido

outra coisa que estou tentando usar é o compudoc, pra documentar meus componentes e todo frontend.