优化 SharePoint 框架内部版本以用于生产

2023-03-21

将SharePoint 框架解决方案部署到生产环境时，应始终使用针对性能进行优化的项目的发布版本。本文演示了调试版和发布版之间的主要区别，并介绍了如何在生产环境中优化捆绑包。

在生产中使用发布版

构建 SharePoint Framework 项目时，可以选择是希望在调试模式下构建还是在发布模式下构建。默认情况下，SharePoint Framework 项目在调试模式下构建，这更易于调试代码。但是，当你的代码完成且按预期运行时，应在发布模式下对其进行构建，并优化以在生产环境中运行。

有关在发布模式下构建项目的详细信息，请参阅 SharePoint 框架工具链。

调试版本和发布版本的输出之间的主要区别在于，生成的捆绑包的发布版本缩小，其大小小于其调试等效版本。若要说明其区别，可以通过使用 Angular 的 Web 部件比较 SharePoint 框架项目的调试版本和发布版本的大小。

两个资源管理器窗口的图像并排显示，突出显示生成的捆绑包的调试和发布版本

捆绑包的调试版本大小为 1255 KB，其等效发布版的大小仅为 177 KB。生成的捆绑包的调试版和发布版之间的大小的差别取决于项目中使用的库。不过，发布版本始终小于调试版本，因此应始终将发布版本的输出部署到生产环境。

不要在捆绑包中添加第三方库

构建 SharePoint 框架解决方案时，可以借助许多现有的 JavaScript 库来解决常见的问题。使用现有库可以提高工作效率并使你关注组织的附加价值，而不是专注于开发通用功能。

默认情况下，在项目中引用第三方库时，SharePoint 框架自动将其加入到生成的捆绑包中。因此，使用你的解决方案的用户最终多次下载同一个库，每个组件下载一次。页面总大小显著增加，加载时间更长，从而导致较差的用户体验，在网络较慢的情况下尤其如此。

Microsoft Edge 开发人员工具在网络选项卡上显示正被加载的两个 Web 部件捆绑包

使用第三方库时，应始终考虑从外部位置（公用 CDN 或你的组织拥有的托管位置）加载。这可以从捆绑包中排除库，从而大大减少其大小。

此外，如果要从中加载库的托管位置针对提供静态资产进行优化，则使用你的解决方案的用户只需加载库一次。在以后的请求中，甚至在将来使用解决方案时，Web 浏览器会重复使用以前缓存的库副本，而不是再次下载它。因此，包含解决方案的页面加载速度更快。

验证捆绑包的内容

为了更好地理解生成的捆绑包的大小，可以扩展项目中的 Webpack 配置，并让 SharePoint 框架生成捆绑包统计信息。

首先，在命令行中执行以下命令，在项目中安装 webpack-bundle-analyzer 程序包：

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

接下来，将项目中 gulpfile.js 文件的内容更改为：

'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);

下次使用 gulp 捆绑 任务捆绑项目时，会看到项目中 的临时/ 统计信息文件夹中生成的捆绑包统计信息文件。其中一个生成的统计信息文件是一个树状图，显示生成的捆绑包中包含的不同脚本。可以在 ./temp/stats/[solution-name].stats.html 文件中找到此可视化效果。

Webpack 捆绑分析器树状图，说明示例SharePoint 框架捆绑包的内容

使用 Webpack 捆绑包分析器树状图可以方便地确认所生成的捆绑包不包含任何不必要的脚本，并了解所包含的脚本对捆绑包总大小有怎样的影响。请记住，显示的大小反映了调试版本，并且对于发布版本而言较小。

./dist/[solution-name].stats.json 文件中包含了生成可视化效果所需的更多详细信息。使用此文件可以确定将特定脚本加入到捆绑包的原因，或在多个捆绑包中是否使用了某个特殊脚本。有了这些信息，就可以优化你的捆绑包，从而改进解决方案的加载时间。

选择主客户端库

如果在同一页上有多个组件，或在跨门户的不同页上有多个组件，并且它们都使用从同一 URL 加载的同一个库，则 Web 浏览器也会重用之前缓存的副本，这可以使门户加载速度更快。

这就是为什么组织对其所使用的库、所使用的版本以及加载库的位置进行合理化分配对于项目和组织来说都很重要。对于使用不同应用程序的用户而言，此策略通过更快速地加载应用程序使其工作更有效率。通过重用以前下载的资产，网络上的加载受到限制，从而为其他用途释放其带宽。

有关使用外部库的详细信息，请参阅在 SharePoint 框架客户端 Web 部件中使用现有 JavaScript 库。

仅引用所需的组件

有时在使用外部库时，可能不需要整个库，而只需要其中的一小部分。包含不必要的整个库会增加你的捆绑包的大小，导致加载时间更长。相反，应始终考虑仅加载实际所需的特定库的特定部分。

为了说明这一点，以 Lodash 库为例。 Lodash 是一系列实用工具，可帮助你在代码中执行某些操作。在使用 Lodash 时，很有可能只需要几种特定的方法，而并不需要整个库。

但是，如果使用以下代码引用了整个库，则会向未优化的捆绑包增加 527 KB：

import * as _ from 'lodash';

捆绑包中包含的完整 Lodash 库，在 Webpack 捆绑包分析器树状图中突出显示

相反，如果使用以下代码仅引用了特定的 Lodash 方法，则会向未优化的捆绑包增加 45 KB：

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

捆绑包中所包含的特定 Lodash 方法在 Webpack 捆绑包分析器树状图中突出显示

特别是关于 Lodash，但其他库的情况也是如此，引用特定方法而不是整个库附带一个价格。

目前，Lodash 不支持使用 import 表示法在SharePoint 框架项目中加载特定方法。相反，必须使用 require 语句，该语句不会提供使用语句 import 提供的类型安全功能。最终，由你决定是否将更多代码加载到捆绑包中是否值得保留类型安全功能。

注意

某些 Lodash 方法由 @microsoft/sp-lodash-subset 库中的 SharePoint Framework 提供。在使用 Lodash 前，请先确认想要使用的方法未在 @microsoft/sp-lodash-subset 库中提供，但已作为 SharePoint Framework 的一部分提供，且无需包含到你的捆绑包中。此包会自动加载到每个 SharePoint 页面上。

另请参阅

SharePoint 框架概述

通过