Optimiser les builds de SharePoint Framework pour la production
Lorsque vous déployez SharePoint Framework solutions de production, vous devez toujours utiliser une version release de votre projet optimisée pour les performances. Cet article indique les principales différences entre les builds de débogage et de version. Il explique comment optimiser votre fichier groupé en vue de son utilisation dans des environnements de production.
Utiliser les builds de version en production
Lorsque vous créez un projet SharePoint Framework, vous pouvez décider de le générer en mode débogage ou en mode publication. Par défaut, les projets SharePoint Framework sont générés en mode débogage, ce qui facilite le débogage de code. Mais lorsque le code est terminé et qu’il fonctionne comme prévu, vous devez le générer en mode publication afin de l’optimiser pour l’exécuter dans l’environnement de production.
Pour plus d’informations sur la création de votre projet en mode publication, reportez-vous à l’article Chaîne d’outils SharePoint Framework.
La principale différence entre la sortie d’un build de débogage et de publication est que la version de publication de l’offre groupée générée est réduite et plus petite en taille que son équivalent de débogage. Pour illustrer la différence, comparez la taille de la version de débogage et de publication d’un projet SharePoint Framework avec un composant WebPart à l’aide d’Angular.

La version de débogage du fichier groupé est de 1 255 Ko tandis que la version de publication correspondante est de seulement 177 Ko. La différence de taille entre les versions de débogage et de publication du fichier groupé généré varie en fonction des bibliothèques utilisées dans votre projet. Toutefois, la version de publication est toujours plus petite qu’une version de débogage, c’est pourquoi vous devez toujours déployer la sortie des builds de publication en production.
Ne pas inclure de bibliothèques tierces dans le fichier groupé
Lorsque vous créez des solutions SharePoint Framework, vous pouvez exploiter de nombreuses bibliothèques JavaScript existantes afin de résoudre les problèmes courants. Utiliser des bibliothèques existantes vous permet d’être plus productif et de vous concentrer sur la valeur ajoutée pour votre organisation, plutôt que sur le développement de fonctionnalités génériques.
Par défaut, lorsque vous référencez des bibliothèques tierces dans votre projet, SharePoint Framework les inclut dans le fichier groupé généré. Par conséquent, les utilisateurs de votre solution finissent par télécharger la même bibliothèque plusieurs fois, à savoir un téléchargement par composant. La taille de page totale augmente grandement, prend plus de temps à charger et entraîne une expérience utilisateur médiocre, en particulier sur les réseaux les plus lents.

Lorsque vous utilisez des bibliothèques tierces, vous devez toujours envisager de les charger à partir d’un emplacement externe : un CDN public ou un emplacement d’hébergement appartenant à votre organisation. Cela vous permet d’exclure la bibliothèque de votre fichier groupé, réduisant ainsi considérablement sa taille.
En outre, si l’emplacement d’hébergement à partir duquel vous chargez la bibliothèque est optimisé pour le service des biens statiques, les utilisateurs qui utilisent votre solution ne doivent charger la bibliothèque qu’une seule fois. Sur les demandes ultérieures, ou même lors de l’utilisation ultérieure de votre solution, le navigateur web réutilise la copie précédemment mise en cache de la bibliothèque au lieu de la télécharger à nouveau. Par conséquent, la page avec votre solution se charge plus rapidement.
Vérifier le contenu de votre fichier groupé
Pour mieux comprendre la taille des fichiers groupés générés, vous pouvez étendre la configuration Webpack dans votre projet et demander à SharePoint Framework de générer des statistiques de fichiers groupés.
Tout d’abord, installez le package webpack-bundle-analyzer dans votre projet en exécutant ce qui suit dans la ligne de commande :
npm install webpack-bundle-analyzer --save-dev
Ensuite, modifiez le contenu du fichier gulpfile.js dans votre projet avec :
'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);
La prochaine fois que vous regrouperez votre projet à l’aide de la tâche d’offre groupée Gulp, vous verrez les fichiers de statistiques d’offre groupée générés dans le dossier temp/stats de votre projet. L’un des fichiers de statistiques générés est un graphique de compartimentage indiquant les différents scripts inclus dans le fichier groupé généré. Cette visualisation est disponible dans le fichier ./temp/stats/[solution-name].stats.html.

Utiliser le graphique de compartimentage de l’analyseur du fichier groupé Webpack est un bon moyen de vérifier que le fichier groupé généré ne contient pas de scripts inutiles et de déterminer l’incidence des scripts inclus sur la taille totale du fichier groupé. N’oubliez pas que la taille affichée reflète la version de débogage et est plus petite pour une version release.
Des informations plus détaillées permettant de générer la visualisation sont disponibles dans le fichier ./dist/[solution-name].stats.json. À l’aide de ce fichier, vous pouvez déterminer pourquoi un script spécifique a été inclus dans le fichier groupé, ou si un script particulier est utilisé dans plusieurs fichiers groupés. Grâce à ces informations, vous pouvez optimiser vos fichiers groupés, améliorant ainsi le temps de chargement de votre solution.
Choisir la bibliothèque côté client principale
S’il existe plusieurs composants sur la même page ou sur différentes pages du portail, et qu’ils utilisent tous la même bibliothèque chargée à partir de la même URL, le navigateur web réutilise également la copie mise en cache au préalable, ce qui permet d’accélérer le chargement du portail.
C’est la raison pour laquelle les organisations doivent absolument rationaliser quelles bibliothèques et quelles versions elles utilisent, et à partir de quel emplacement elles sont chargées, pas seulement pour un projet spécifique, mais pour l’ensemble de l’organisation. Cette stratégie permet aux utilisateurs d’être plus productifs lors de l’utilisation des différentes applications grâce à la rapidité de chargement des applications. En réutilisant les composants téléchargés précédemment, le temps de chargement sur le réseau est limité, ce qui libère de la bande passante à d’autres fins.
Pour plus d’informations sur l’utilisation de bibliothèques externes, reportez-vous à l’article Utiliser des bibliothèques JavaScript existantes dans les composants WebPart côté client pour SharePoint Framework.
Référencer uniquement les composants nécessaires
Parfois, lorsque vous travaillez avec des bibliothèques externes, vous n’avez peut-être pas besoin de la bibliothèque entière, mais seulement d’une petite partie. Inclure la bibliothèque entière augmente inutilement la taille de votre fichier groupé, ainsi que son temps de chargement. À la place, vous devez toujours envisager de charger uniquement les parties spécifiques de la bibliothèque dont vous avez réellement besoin.
Pour illustrer cela, prenons l’exemple de la bibliothèque Lodash. Lodash est une collection d’utilitaires qui vous aident à faire certaines opérations dans votre code. Lorsque vous utilisez Lodash, il y a de grandes chances pour que vous ayez besoin de quelques méthodes spécifiques plutôt que de la bibliothèque entière.
Toutefois, si vous avez référencé l’intégralité de la bibliothèque à l’aide du code suivant, cela ajoute 527 Ko à votre fichier groupé non optimisé :
import * as _ from 'lodash';

À la place, si vous avez référencé uniquement la méthode Lodash spécifique à l’aide du code suivant, cela ajoute 45 Ko à votre fichier groupé non optimisé :
const at: any = require('lodash/at');

Plus précisément en ce qui concerne Lodash, mais cela peut également être le cas avec d’autres bibliothèques, le référencement de méthodes spécifiques au lieu de la bibliothèque entière a un prix.
Actuellement, Lodash ne prend pas en charge le chargement de méthodes spécifiques dans SharePoint Framework projets à l’aide de la import notation. Au lieu de cela, vous devez utiliser une instruction, qui ne vous offre pas les fonctionnalités de sécurité de type que fait require import l’instruction. Finalement, c’est à vous de décider si le chargement de davantage de code dans vos offres groupées vaut la peine de préserver les fonctionnalités de sécurité des types.
Notes
Certaines des méthodes Lodash sont fournies avec le SharePoint Framework dans la bibliothèque @ microsoft/sp-lodash-subset. Avant d’utiliser Lodash, vérifiez si la méthode que vous souhaitez utiliser n’est pas déjà disponible dans la bibliothèque @ microsoft/sp-lodash-subset, qui est déjà disponible dans le cadre du SharePoint Framework et qui n’a pas besoin d’être incluse dans votre offre groupée. Ce package est automatiquement chargé sur chaque SharePoint page.