diff --git a/docs/images/external-scripts-browser-loading-angular-two-web-parts.png b/docs/images/external-scripts-browser-loading-angular-two-web-parts.png index 33f592d18..e78e3cb2b 100644 Binary files a/docs/images/external-scripts-browser-loading-angular-two-web-parts.png and b/docs/images/external-scripts-browser-loading-angular-two-web-parts.png differ diff --git a/docs/images/external-scripts-browser-loading-angular.png b/docs/images/external-scripts-browser-loading-angular.png index 9224423ac..438241c86 100644 Binary files a/docs/images/external-scripts-browser-loading-angular.png and b/docs/images/external-scripts-browser-loading-angular.png differ diff --git a/docs/images/external-scripts-bundle-size.png b/docs/images/external-scripts-bundle-size.png index 384a41872..8cf3ee251 100644 Binary files a/docs/images/external-scripts-bundle-size.png and b/docs/images/external-scripts-bundle-size.png differ diff --git a/docs/images/external-scripts-external-angular-bundle-size.png b/docs/images/external-scripts-external-angular-bundle-size.png index 589c01172..e8cb54785 100644 Binary files a/docs/images/external-scripts-external-angular-bundle-size.png and b/docs/images/external-scripts-external-angular-bundle-size.png differ diff --git a/docs/images/external-scripts-external-angular-two-bundles-size.png b/docs/images/external-scripts-external-angular-two-bundles-size.png index 4b3c3b279..1cf648bb7 100644 Binary files a/docs/images/external-scripts-external-angular-two-bundles-size.png and b/docs/images/external-scripts-external-angular-two-bundles-size.png differ diff --git a/docs/images/external-scripts-two-bundles-size.png b/docs/images/external-scripts-two-bundles-size.png index b7ef05c29..5a9c62d67 100644 Binary files a/docs/images/external-scripts-two-bundles-size.png and b/docs/images/external-scripts-two-bundles-size.png differ diff --git a/docs/spfx/web-parts/guidance/use-existing-javascript-libraries.md b/docs/spfx/web-parts/guidance/use-existing-javascript-libraries.md index 01acb7db8..cbaef1cf5 100644 --- a/docs/spfx/web-parts/guidance/use-existing-javascript-libraries.md +++ b/docs/spfx/web-parts/guidance/use-existing-javascript-libraries.md @@ -1,7 +1,7 @@ --- title: Use existing JavaScript libraries in SharePoint Framework client-side web parts description: Ensure that your web parts won't negatively impact the performance of SharePoint pages that they're being used on. -ms.date: 06/13/2022 +ms.date: 02/05/2026 ms.localizationpriority: high --- @@ -9,8 +9,6 @@ ms.localizationpriority: high When building client-side web parts on the SharePoint Framework, you can benefit from using existing JavaScript libraries to build powerful solutions. There are, however, some considerations that you should take into account to ensure that your web parts won't negatively impact the performance of SharePoint pages that they're being used on. -[!INCLUDE [spfx-gulp-heft-migration-wip](../../../../includes/snippets/spfx-gulp-heft-migration-wip.md)] - ## Reference existing libraries as packages The most common way of referencing existing JavaScript libraries in SharePoint Framework client-side web parts is by installing them as a package in the project. @@ -62,7 +60,7 @@ The most common way of referencing existing JavaScript libraries in SharePoint F ## Bundle web part resources -SharePoint Framework uses a build toolchain based on open-source tooling such as gulp and Webpack. When building SharePoint Framework projects, these build tools automatically combine all referenced resources into a single JavaScript file in a process called bundling. +SharePoint Framework uses a build toolchain based on open-source tooling such as heft and Webpack. When building SharePoint Framework projects, these build tools automatically combine all referenced resources into a single JavaScript file in a process called bundling. ![Command window with the gulp bundle task visible next to the SharePoint Framework dist folder containing the output files](../../../images/external-scripts-gulp-bundle.png) @@ -74,11 +72,11 @@ Bundling web parts also has benefits for end-users: generally speaking, it's fas However, bundling existing JavaScript libraries with SharePoint Framework client-side web parts isn't without drawbacks. -When bundling existing JavaScript frameworks in the SharePoint Framework, all referenced scripts are included in the generated bundle file. Following the Angular example, an optimized web part bundle including Angular is over 170 KB. +When bundling existing JavaScript frameworks in the SharePoint Framework, all referenced scripts are included in the generated bundle file. Following the Angular example, an optimized web part bundle including Angular is over 1385 KB. ![Screenshot of the File Explorer screen's deploy folder showing the Hello World bundle JavaScript file being highlighted.](../../../images/external-scripts-bundle-size.png) -If you add another web part to your project that also uses Angular and you build the project, you get two bundle files, one for each web part, each of them being over 170 KB. +If you add another web part to your project that also uses Angular and you build the project, you get two bundle files, one for each web part, each of them being over 1385 KB. ![Screenshot of the File Explorer screen's deploy folder showing two Hello World bundle JavaScript files being highlighted.](../../../images/external-scripts-two-bundles-size.png) @@ -161,11 +159,11 @@ export default class HelloWorldWebPart extends BaseClientSideWebPart