Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified docs/images/external-scripts-browser-loading-angular.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified docs/images/external-scripts-bundle-size.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified docs/images/external-scripts-external-angular-bundle-size.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified docs/images/external-scripts-two-bundles-size.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
@@ -1,16 +1,14 @@
---
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
---

# Use existing JavaScript libraries in SharePoint Framework client-side web parts

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.
Expand Down Expand Up @@ -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)

Expand All @@ -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)

Expand Down Expand Up @@ -161,11 +159,11 @@ export default class HelloWorldWebPart extends BaseClientSideWebPart<IHelloWorld
}
```

If you build your project now and take a look at the size of the generated bundle file, you notice that it's only 6 KB.
If you build your project now and take a look at the size of the generated bundle file, you notice that it's only 40 KB.

![Screenshot of File Explorer showing the deploy folder with the Hello Word JavaScript file being highlighted.](../../../images/external-scripts-external-angular-bundle-size.png)

If you add another web part to your project that also uses Angular, and you build the project again, both bundles would be 6 KB each.
If you add another web part to your project that also uses Angular, and you build the project again, both bundles would be 40 KB each.

![Screenshot of File Explorer showing the deploy folder with two Hello Word JavaScript files being highlighted.](../../../images/external-scripts-external-angular-two-bundles-size.png)

Expand Down