Otimização do tempo de construção do projeto

Onde trabalho (na inicialização do Spot.IM , cujo tamanho está entre pequeno e médio), o Webpack é usado para criar vários projetos. Após 4 anos trabalhando em nosso produto principal, quando tantas pessoas contribuíram com seu código que ele não pode ser contado, o tempo de sua montagem inicial atingiu exorbitantes 90 segundos e o tempo de remontagem - 14.

Isso leva cerca de 14 segundos para esperar após cada clique no botão "Salvar".

Tendo recorrido a algumas otimizações simples, como qualquer pessoa pode aplicar em seu projeto, conseguimos reduzir os números acima para 20 segundos para montagem e 1 segundo para reconstruir o projeto.



Neste artigo, quero falar sobre algumas mudanças simples, fazendo com que o projeto possa melhorar significativamente seu tempo de montagem. Observe que, se você usar o CreateReactApp (ou algum outro gerador de aplicativos da moda), este artigo poderá não ser especialmente útil para você. Mas se você não usar nada disso, o que estamos falando aqui pode ser muito útil para você.

Medindo o tempo necessário para construir um projeto

Antes de fazer qualquer tipo de otimização, vamos configurar uma medida de indicadores pelos quais podemos julgar os resultados do trabalho. Para fazer isso, use o pacote speed-measure-webpack-plugin (SMP):

const webpackConfig = require('./webpack.config') const SpeedMeasurePlugin = require('speed-measure-webpack-plugin') const smp = new SpeedMeasurePlugin({   disable: !process.env.MEASURE, }) module.exports = smp.wrap(webpackConfig) 

Colocamos o arquivo de configuração do Webpack no wrapper SMP (iniciando o mecanismo para fazer medições de desempenho usando a variável de ambiente) e depois passamos o objeto de configuração do Webpack. Depois disso, temos à disposição um relatório de aparência agradável que nos permite descobrir quanto tempo é gasto em cada gerenciador de inicialização durante a montagem. Usando o SMP, obtemos benefícios duplos. Em primeiro lugar, depois de fazer uma certa melhoria, podemos descobrir imediatamente como isso afetou o tempo de construção do projeto. Em segundo lugar, temos imediatamente à disposição um relatório completo sobre quanto tempo cada carregador de inicialização leva (ou, mais precisamente, a “cadeia do carregador de inicialização”).


Relatório gerado com speed-measure-webpack-plugin

Melhorando o tempo de construção inicial de um projeto

Depois que começamos a usar o SMP, tivemos informações sobre como o tempo de criação do projeto muda ao fazer melhorias no processo de criação. A primeira coisa que começamos a otimizar foi o tempo de compilação inicial (ou seja, o tempo que o Webpack levou para compilar o pacote após a inicialização). Para acelerar o processo inicial de compilação, decidimos usar o cache-loader inicialização do cache-loader .

Cache-loader é um carregador que armazena em cache e salva no disco (ou banco de dados) os resultados do trabalho dos carregadores que o seguem. Isso significa que na próxima vez em que você iniciar o Webpack, poderá ver uma melhoria significativa na velocidade de compilação, ou pelo menos poderá esperar.

Aqui está um exemplo:

 {  rules: [    {      test: /\.jsx?$/,      use: [        'cache-loader',        'babel-loader',      ],    },    {      test: /\.scss$/,      use: [        'style-loader',        'cache-loader',        'css-loader',        'postcss-loader',        'sass-loader',      ],    },  ] } 

A adição do cache-loader antes do css-loader (para CSS) e antes do babel-loader (para JS) nos permitiu remover cerca de 75 segundos do tempo gasto na construção inicial do projeto.

Agora vamos trabalhar no tempo de remontagem. Vamos tentar melhorar esse tempo alterando a propriedade devtool .

Cartões de código Webpack

Nas configurações do Webpack, você encontra a propriedade devtool , que, de acordo com a documentação, “permite escolher o estilo de criação de cartões de código usados ​​para aprimorar os recursos de depuração. Os pontos de ajuste podem afetar bastante a velocidade de montagem e remontagem ".

Em outras palavras, modificar a propriedade devtool afeta qual cartão de código estará disponível para o desenvolvedor após a criação do projeto. E isso, por sua vez, depende de quanto tempo leva para criar um cartão de código.

Experimentos com essa propriedade são algo do campo que pode mudar permanentemente a vida de um programador. Isso tem um enorme impacto na velocidade de construção do projeto. Nomeadamente, alteramos o valor do devtool de source-map (provavelmente este é o modo mais lento) para eval-source-map e conseguimos reduzir o tempo de remontagem do projeto de 14 para 3,5 segundos:

 {  devtool: process.env.NODE_ENV === 'development'    ? 'eval-source-map'    : 'source-map' } 

A propriedade devtool capaz de aceitar 12 variantes de valor. O CreateReactApp, por exemplo, usa o mapa de origem do módulo barato . Portanto, se você estiver configurando essa propriedade, experimente e encontre o valor que é melhor para você.

Deve-se notar que, ao usar métodos rápidos de criação de cartões de código, a qualidade dos cartões resultantes se deteriora. Essas deteriorações podem ser sentidas iniciando a depuração. Felizmente, os navegadores modernos acompanham o TC39. Como resultado (pelo menos durante o desenvolvimento), não há necessidade real da transpilação de grandes quantidades de código. Se você configurar o Babel para que essa ferramenta transporta o JavaScript para um nível que a versão mais recente do navegador entenda (como feito no CRA ), com a depuração de código, tudo ficará bem, pois os mapas de código não serão muito diferentes do próprio código.

Aqui está a aparência de babel.config.js se você decidir transpor o código para um estado claro para as versões mais recentes de vários navegadores:

 module.exports = {  presets: [    [      '@babel/preset-env',      {        targets: [          'last 1 chrome version',          'last 1 safari version',          'last 1 firefox version',        ].join(', '),      },    ],  ],  // ... } 

Isso é tudo. Três etapas simples e o tempo de construção do nosso projeto foi bastante reduzido.

Gostaria de observar que alguém que começa a resolver um problema semelhante pode querer primeiro examinar a documentação do Webpack e lê-la corretamente. No entanto, essa não é a única fonte de conhecimento.

Encontrei outra abordagem para encontrar informações valiosas sobre projetos de construção. Essa abordagem se provou na prática. Consiste em analisar arquivos webpack.config de projetos de código aberto existentes. Em particular, o arquivo de projeto CreateReactApp . Ao ler cuidadosamente esse arquivo, você pode descobrir muitas coisas úteis.

Sumário

Um leitor atento percebeu que, no início, era uma questão de reduzir o tempo de remontagem para 1 segundo. E o melhor valor desse indicador mencionado no texto foi de 3,5 segundos. Obviamente, algo foi omitido ao descrever o progresso da otimização do processo de montagem. Assim é. Foi possível melhorar o tempo de remontagem do projeto para 1 segundo, ganhando outros 2,5 segundos graças a otimizações sutis, que dependem muito dos recursos de um projeto específico, o Spot.IM. Portanto, uma descrição dessas melhorias não é fornecida aqui.

Caros leitores! Você otimiza o tempo de construção de seus projetos?