Otimização de bundle com webpack

[mikaelhadler]

Fala pessoal, tudo bem ?
Hoje vim humildemente pedir umas dicas de otimização de bundles com webpack.

O que vocês fazem para melhorar a compressão dos vendors ?
Vocês constumam separar o seu vendors em diversos chunks ?

O que já estou fazendo ?

• Remoção de libs unused com análise do depcheck.
• Lodash com uso do 'lodash-webpack-plugin'
• Importações feature por lib
  Ex: import { Card } from 'antd'

O que ainda não consegui ?

• Redução do vendors - 8.28 mb :'(

To lendo um pouco sobre a separação destes vendors, mas ainda não ta muito claro se terei um tanto ganho.

[wkrueger]

É angular né? Eu tenho a impressão que o vendor de produção do angular um tanto menor, o de dev que é exagerado.

Além do feijão-com-arroz (montar o gráfico de tamanho e analizar caso a caso), uma idéia seria fuçar no que pacotes de build (como o CRA ou o TSDX) estão fazendo, às vezes se acha algo. O TSDX, por exemplo tinha uma parada de marcar as funções como imutáveis pra aumentar a quantidade de libs afetadas pelo tree-shaking...

[felipefialho]

@mikaelhadler Indico demais que use a lib webpack-bundle-analyzer para analisar quais coisas estão pesando.

Se estiver usando Angular recomendo que faça lazy loading das suas coisas, deixando apenas as coisas necessárias para carregamento inicial no bundle principal. Faz toda diferença com relação a performance.

[mikaelhadler]

É angular né? Eu tenho a impressão que o vendor de produção do angular um tanto menor, o de dev que é exagerado.

Além do feijão-com-arroz (montar o gráfico de tamanho e analizar caso a caso), uma idéia seria fuçar no que pacotes de build (como o CRA ou o TSDX) estão fazendo, às vezes se acha algo. O TSDX, por exemplo tinha uma parada de marcar as funções como imutáveis pra aumentar a quantidade de libs afetadas pelo tree-shaking...

Pior que não, é react :|, vou dar uma sacada nesses repositórios para entender mais esta parte do tree-shaking, talvez seja por isso que ta dando tanto impacto.

[mikaelhadler]

@mikaelhadler Indico demais que use a lib webpack-bundle-analyzer para analisar quais coisas estão pesando.

Se estiver usando Angular recomendo que faça lazy loading das suas coisas, deixando apenas as coisas necessárias para carregamento inicial no bundle principal. Faz toda diferença com relação a performance.

@felipefialho foi exatamente ele que utilizei pra analisar o que estava pesando, valeu a dica = )

[ninetails]

Tentou usar o que a documentação fala sobre sideEffects e usedExports com o terser?

Como uma dica pessoal eu sempre tento evitar agregar módulos em named exports, sempre tento chamar direto arquivos com export default, ou se há named exports, fazer dum jeito que ao pedir banana não venha macaco e a floresta toda. O tree-shaking/dead code elimination não é coisa nativa do webpack e não confio muito no mangler do uglify/terser. Mas entendo que agora o projeto já deve ter crescido desorganizadamente (pra ultrapassar 8mb de prod).

Creio que uma otimização que sugeriria seria tentar criar dynamic imports e dividir o teu código em módulos "code
-splittáveis", mas tb requer uma boa reescrita da base.

[eliseumds]

Seta mode: 'production' e vê qual é o tamanho.

"antd" é bem grande também. Você pode consultar o peso das bibliotecas e se elas são tree-shakeable usando o BundlePhobia.

Se você estiver usando alguma lib de internacionalização como Moment, é possível que ela tenha incluído as data files de todas as linguagens disponíveis.

Os source maps estão inline no arquivo? Compartilha a configuração do Babel também, apesar de que, em 90%+ dos casos, não é necessário transformar vendor files com Babel.

8.2MB é realmente muita coisa. Eu trabalho num projeto gigante e a vendor file pesa 4.8MB em desenvolvimento e 896KB em produção. Com GZIP, caem para 925KB e 218KB, respectivamente.

Roda o webpack-bundle-analyzer e compartilha o JSON com a gente.

[mikaelhadler]

@ninetails Desculpe se não fui claro, essas métricas obtidas foram do tamanho em desenvolvimento pessoal.

Alguns dados referentes a este estudo:

Reduce bundle size:
9.1 MB -> 6.97 MB
Initial - File sizes after gzip:

445.04 KB (-22.17 KB) build/static/js/2.39a9eafe.chunk.js
58.8 KB build/static/css/2.0f87f62a.chunk.css
19.43 KB (-237 B) build/static/js/main.8796b945.chunk.js
1 KB build/static/css/main.1d21faef.chunk.css
782 B build/static/js/runtime~main.74d11e89.js

Final bundle - File sizes after gzip:

467.21 KB build/static/js/2.9bada5e1.chunk.js
58.8 KB build/static/css/2.0f87f62a.chunk.css
19.66 KB build/static/js/main.c7334513.chunk.js
1 KB build/static/css/main.1d21faef.chunk.css
782 B build/static/js/runtime~main.74d11e89.js 

[eliseumds]

@mikaelhadler aí você tem que ajudar a gente. Que estudo? Quais configurações você alterou? Os resultados parecem razoáveis agora pra você?

[ninetails]

@mikaelhadler de acordo, explica melhor pra podermos ajudar mais pontualmente.

O que eu falaria é que o code-splitting é uma otimização que ajuda em relação a evitar baixar código desnecessário:

• code-splitting por página vc chama apenas aquilo que tem na rota que bateu
• separar vendor ajuda em relação a ter um código que só muda quando há mudança de dependências (seja adição/remoção ou mudanças no tree-shaking), e nisso vc ganha em relação ao cache, se o servidor estiver sido configurado corretamente