Otimizar as compilações da Estrutura do SharePoint para produção

Ao implantar Estrutura do SharePoint soluções para produção, você sempre deve usar um build de versão do seu projeto otimizado para desempenho. Este artigo ilustra as principais diferenças entre compilações de depuração e lançamento, além de mostrar como você pode otimizar seu pacote para uso em ambientes de produção.

Usar compilações de lançamento em produção

Ao construir um projeto do SharePoint Framework, você pode escolher se deseja compilá-lo no modo de depuração ou lançamento. Por padrão, os projetos do SharePoint Framework são construídos no modo de depuração, o que facilita a depuração do código. Porém, quando seu código estiver finalizado e funcionando conforme esperado, você deverá compilá-lo no modo de lançamento, para otimizá-lo para execução no ambiente de produção.

Para saber mais sobre como compilar seu projeto no modo de versão, leia Cadeia de ferramentas da Estrutura do SharePoint.

A principal diferença entre a saída de um build de depuração e de versão é que a versão de versão do pacote gerado é minificada e menor em tamanho do que seu equivalente de depuração. Para ilustrar a diferença, compare o tamanho da versão de depuração e de lançamento de um projeto da Estrutura do SharePoint com uma web part usando o Angular.

A versão de depuração do pacote tem 1255 KB, enquanto seu equivalente de lançamento tem apenas 177 KB. A diferença de tamanho entre a versão de lançamento e de depuração do pacote gerado pode variar dependendo das bibliotecas usadas no seu projeto. Ainda assim, o build de versão é sempre menor do que um build de depuração, razão pela qual você deve sempre implantar a saída de builds de lançamento em produção.

Não inclua bibliotecas de terceiros no pacote

Ao compilar soluções da Estrutura do SharePoint, você pode se beneficiar das várias bibliotecas JavaScript existentes para resolver problemas comuns. O uso de bibliotecas existentes aumenta a produtividade e permite que você se concentre no valor agregado para a sua organização, em vez de no desenvolvimento da funcionalidade genérica exigida.

Por padrão, ao fazer referência a bibliotecas de terceiros no seu projeto, a Estrutura do SharePoint as inclui no pacote gerado. Como resultado, os usuários que trabalham com a sua solução acabam baixando a mesma biblioteca várias vezes, uma com cada componente. O tamanho total da página aumenta significativamente, aumentando o tempo para carregamento e resultando em uma experiência do usuário ruim, especialmente em redes mais lentas.

Ao trabalhar com bibliotecas de terceiros, você sempre deve considerar carregá-las de um local externa: uma CDN pública ou um local de hospedagem que pertence à sua organização. Isso permite que você exclua a biblioteca do seu pacote, diminuindo significativamente seu tamanho.

Além disso, se o local de hospedagem do qual você está carregando a biblioteca for otimizado para atender ativos estáticos, os usuários que trabalham com sua solução precisarão carregar a biblioteca apenas uma vez. Em solicitações posteriores ou mesmo ao usar sua solução no futuro, o navegador da Web reutiliza a cópia armazenada em cache anteriormente da biblioteca em vez de baixá-la novamente. Como resultado, a página com sua solução é carregada mais rapidamente.

Verificar o conteúdo do seu pacote

Para entender melhor o tamanho dos pacotes gerados, você pode estender a configuração do Webpack no projeto e fazer com que a Estrutura do SharePoint gere estatísticas do pacote.

Primeiro, instale o pacote webpack-bundle-analyzer em seu projeto executando o seguinte na linha de comando:

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

Em seguida, altere o conteúdo do arquivo gulpfile.js em seu projeto para:

'use strict';

const gulp = require('gulp');
const path = require('path');
const build = require('@microsoft/sp-build-web');
const bundleAnalyzer = require('webpack-bundle-analyzer');

build.configureWebpack.mergeConfig({
  additionalConfiguration: (generatedConfiguration) => {
    const lastDirName = path.basename(__dirname);
    const dropPath = path.join(__dirname, 'temp', 'stats');
    generatedConfiguration.plugins.push(new bundleAnalyzer.BundleAnalyzerPlugin({
      openAnalyzer: false,
      analyzerMode: 'static',
      reportFilename: path.join(dropPath, `${lastDirName}.stats.html`),
      generateStatsFile: true,
      statsFilename: path.join(dropPath, `${lastDirName}.stats.json`),
      logLevel: 'error'
    }));

    return generatedConfiguration;
  }
});

build.initialize(gulp);

Na próxima vez que você empacotar seu projeto usando a tarefa do pacote gulp , você verá os arquivos de estatísticas de pacote gerados na pasta temp/stats em seu projeto. Um dos arquivos de estatísticas gerados é um mapa de árvore que mostra os scripts diferentes incluídos no pacote gerado. Você pode encontrar essa visualização no arquivo ./temp/stats/[solution-name].stats.html.

O uso do mapa de árvore do analisador de pacotes do Webpack é uma forma conveniente de verificar se o pacote gerado não contém scripts desnecessários e entender como os scripts incluídos afetam o tamanho total do pacote. Lembre-se de que o tamanho exibido reflete o build de depuração e é menor para um build de versão.

Informações mais detalhadas, usadas para gerar a visualização, estão incluídas no arquivo ./dist/[solution-name].stats.json. Ao usar esse arquivo, você pode descobrir por que um script específico foi incluído no pacote ou se um script em particular é usado em vários pacotes. Com essas informações, é possível otimizar seus pacotes, melhorando o tempo de carregamento da solução.

Escolher sua biblioteca primária do lado do cliente

Se houver vários componentes na mesma página, ou até mesmo em páginas diferentes pelo portal, e todos eles usarem a mesma biblioteca carregada da mesma URL, o navegador da Web também reutilizará a cópia anteriormente armazenada em cache, fazendo com que o portal seja carregado com mais rapidez.

Exatamente por isso é essencial que as organizações racionalizem quais bibliotecas e versões elas usam, bem como de onde elas são carregadas, não só para um projeto específico, mas para toda a organização. Essa política permite que os usuários que trabalham com os diferentes aplicativos sejam mais produtivos ao carregar os aplicativos com mais rapidez. Com a reutilização dos ativos baixados anteriormente, a carga na rede é limitada, liberando sua largura de banda para outras finalidades.

Para saber mais sobre como trabalhar com bibliotecas externas, confira Usar bibliotecas JavaScript existentes em web parts da Estrutura do SharePoint do lado do cliente.

Fazer referência apenas dos componentes necessários

Às vezes, ao trabalhar com bibliotecas externas, talvez você não precise de toda a biblioteca, mas apenas uma pequena parte dela. Incluir a biblioteca inteira aumenta desnecessariamente o tamanho do seu pacote, aumentando seu tempo de carregamento. Em vez disso, você deve sempre considerar apenas carregar as partes específicas da biblioteca realmente necessária.

Para ilustrar isso, use a biblioteca Lodash como exemplo. Lodash é uma coleção de utilitários que ajudam você a fazer determinadas operações em seu código. São grandes as chances de que, ao trabalhar com Lodash, você precise apenas de alguns métodos específicos, e não da biblioteca inteira.

No entanto, se você referenciou a biblioteca inteira usando o código a seguir, ela adicionará 527 KB ao seu pacote não otimizado:

import * as _ from 'lodash';

Mas, se você referenciou apenas o método específico do Lodash usando o código a seguir, ele adicionará 45 KB ao seu pacote não otimizado:

const at: any = require('lodash/at');

Especificamente no que diz respeito ao Lodash, mas isso também pode ser o caso de outras bibliotecas, referenciar métodos específicos em vez de toda a biblioteca vem com um preço.

Atualmente, o Lodash não dá suporte ao carregamento de métodos específicos dentro de projetos Estrutura do SharePoint usando a import notação. Em vez disso, você precisa usar uma require instrução, que não oferece os recursos de segurança de tipo que o uso da import instrução faz. Eventualmente, cabe a você decidir se o carregamento de mais código em seus pacotes vale a pena preservar as funcionalidades de segurança do tipo.

Observação

Alguns dos métodos Lodash são fornecidos com a Estrutura do SharePoint na biblioteca @microsoft/sp-lodash-subset. Antes de usar o Lodash, verifique se o método que você deseja usar já está na biblioteca @microsoft/sp-lodash-subset, que faz parte da Estrutura do SharePoint e não precisa ser incluída no seu pacote. Esse pacote é carregado automaticamente em cada página do SharePoint.

Confira também

• Visão geral da Estrutura do SharePoint