SPFx | Failed to load component.

This post was most recently updated on March 28th, 2023.

This post describes the typical reasons why one might encounter the following error, and the ways I’ve found to fix them: “Failed to load component. Original error: ***Failed to load path dependency ContosoSPFxWebPartLocalization from component [guid] (ContosoSPFxWebPart)“.

The error typically looks something like this in the screenshot below:

Problem

This error can be thrown for a lot of different reasons. I’m trying to describe the variants I’ve run into and their fixes below. But first, let’s take a closer look into the error in question!

So looking at this, what’re the actual errors we’re getting? Where are they stemming from?

From the first line (“SPLoaderError.loadComponentError“) we already know that it’s about the SPFx failing to load your component for whatever reason. Now all that’s left is figuring out what the reason is!

I’ve seen a few different variations of this error. Sometimes you have the sick-looking “https://component-id.invalid…” -URL, and sometimes you see an absolute URL- let’s take a closer look at the stack below!

[SPLoaderError.loadComponentError]:

***Failed to load component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart).

Original error: ***Failed to load path dependency "ContosoSPFxWebPartLocalization" from component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart).

Original error: Error loading https://component-id.invalid/9951b316-c8f2-4e27-887a-b7a46b3e94a0_1.3.1/ContosoSPFxWebPartLocalization

 Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js



***INNERERROR:

***Failed to load path dependency "ContosoSPFxWebPartLocalization" from component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart).

Original error: Error loading https://component-id.invalid/9951b316-c8f2-4e27-887a-b7a46b3e94a0_1.3.1/ContosoSPFxWebPartLocalization

 Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js

***CALLSTACK:

Error

 at t [as constructor] (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:889:16049)

 at new t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:21125)

 at Function.e.buildErrorWithVerboseLog (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:16214)

 at Function.e.buildLoadComponentError (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:12245)

 at https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:60385

You’ll be interested in a couple of things here. The first line we’re already familiar with (SPLoaderError.loadComponentError), so now we’ll take a look at 2 different interesting things.

First of all, we can identify the faulting components by investigating the component IDs – probably, the most interesting line is the INNERERROR:

***Failed to load path dependency “ContosoSPFxWebPartLocalization” from component “9951b316-c8f2-4e27-887a-b7a46b3e94a0” (ContosoSPFxWebPart).

The name of the dependency tells you, which component, bundle or file the Loader is failing to load. This will of course help you identify which of your imports fails if you’re the one developing the solution.

Another interesting part is the URL where the Loader is trying to load the dependencies. Take a look at the example below:

Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js

Take another look at that URL and make a mental note of it – you’ll need it soon.

Reasons and solutions

Okay, so after a bit of digging, there are a couple of different reasons and different solutions. The first thing we need to figure out is to find the deployment path for your solution. It’s likely either the SharePoint CDN, or a path under the App Catalog in SharePoint Online. However, it’s also possible to host the files your .sppkg or .app file then requests in pretty much any location!

Anyway – let’s verify if you’re using CDN or not. Take a look at the error to find the url the script is being loaded from – does it begin with something like this:

• publiccdn.sharepointonline.com

If it does, you likely have an SPFx webpart that’s deployed to the public Office 365 CDN.

While you might have additional resources loaded from CDN, these domains are typically not hosting your components:

• *.sharepointonline.com
• cdn.sharepointonline.com
• static.sharepointonline.com
• privatecdn.sharepointonline.com
• spoprod-a.akamaihd.net

These are additional resources or core components being loaded from different CDN services. Yes, Microsoft has quite a few of them :)

If you’re not using CDN, skip the next subchapter and jump right to “Error in dependencies or packaging“.

Errors with CDN

This solution only applies if you’re using Office 365 CDN.

Does the error apply to just one SPFx package or to multiple? If it applies to all of the SPFx packages that are deployed to CDN on that tenant, it’s somewhat safe to assume that the CDN is to blame.

While using Office 365 is definitely the suggested course of action most of the time, it’s worth realizing that the CDN is not the most stable piece of tech ever existed. The built-in CDN has had its fair share of issues – see the ones below for examples:

• https://github.com/SharePoint/sp-dev-docs/issues/1731
• https://github.com/SharePoint/sp-dev-docs/issues/2015
• https://github.com/SharePoint/sp-dev-fx-webparts/issues/491
• https://github.com/SharePoint/sp-dev-docs/issues/864
• https://github.com/SharePoint/sp-dev-docs/issues/3079

A lot of times, these issues are fixed by one of the following actions (these are very unofficial and totally made up by me, by the way).

These steps apply to both the error described in this article, but also cases when your app just won’t update.

Error in dependencies or packaging

If you’re encountering this with your own package in development, grab the component name and/or the Guid. The component name will help you pinpoint which one of your imports is being misconstructed.

Now, if it indeed is YOUR package, fix it somehow like the steps in this article by Shantha Kumar Thambidurai.

You could also try running gulp clean and rebuild, something like this:

gulp clean
gulp build
gulp bundle --ship
gulp package-solution --ship

This issue only exists in Internet Explorer…

Oh, how I would love to tell you to stop using Internet Explorer… But I know, I know – maybe your customer requires it.

Anyhow, these are some of the extra things you can try with IE:

• Force IE to use 11 document mode
  • IE 10 or compatibility mode is not supported. If you have to, modify the master page to get IE to behave properly.
• Set your site and CDN to be in the same security zone
  • Shouldn’t matter – but it still does. Duh.
• Go through your dependencies once more
  • There are a TON of dependencies, that might not be compatible with legacy browsers. Verify, that you’re not using something that doesn’t work with IE at all!
  • This applies especially if you get the threaded error below:

[SPLoaderError.loadComponentError]:
***Failed to load component "58c4fb68-60f1-45ac-b057-ba7cc51c3ec2" (WebPartName).
Original error: ***Failed to load URL 'https://publiccdn.sharepointonline.com/tenantname.sharepoint.com/sites/AppCatalogName/ClientSideAssets/ca2eacd0-4645-4306-a335-e5d9aa919578/web-part-name_e437798e9f3bcfff6ee74118a0bf73ed.js' for resource 'web-part-name' in component '58c4fb68-60f1-45ac-b057-ba7cc51c3ec2' (WebPartName). There was a network problem.
This may be a problem with a HTTPS certificate. Make sure you have the right certificate.

Another quick note about the error above – also verify that your system time is correct – if not, you might run into funny SSL certificate errors… :)

Is it not your package? Check the solutions below, and if none of them resolves your issue, ask whomever you got the package from, if the package is working for everyone else.

Error with External/Guest users

Okay, sounds pretty broad, right? But I’ve found 2 different solutions here. These solutions apply to AT LEAST the situations when your internal users don’t necessarily experience the issues at all, but your external/guest users do.

Not using CDN?

If you’re not using CDN with your SPFx webparts, most likely they’re hosted from your app catalog’s SiteAssets/ClientSideAssets library. If you have external users accessing your site, they won’t by default be able to access this site at all, and will hence encounter weird issues with the SPFx webparts.

In a case like this, you have at least two different options:

How to enable your external users to access your SPFx webparts that are not hosted on CDN:

1. Enable CDN and deploy your apps there instead of the app catalogue
   1. See my snippet on how to do that: How to fix Office 365 CDN when it breaks?
2. Modify the ClientSideAssets -library’s permissions in the app catalogue site to allow external users access there. This includes at least the following steps.
   1. Enable external sharing on your tenant if it isn’t enabled already.
   2. Enable external sharing on the App Catalog site
   3. Invite a group with your external/guest users to the ClientSideAssets library as visitors/readers.

As a side note, to enable hosting your SPFx solution from SharePoint, you need to have “includeClientSideAssets” as “true” in the package-solution.json file. This configuration is also typically ignored when building debug builds (bundle without –ship).

Using CDN and messing up the permissions

In a case like this, it’s probably not you, it’s Microsoft. There isn’t that much you can mess up with CDN that would be external users -specific. And if you have, I want to hear about that, so please do leave a comment below!

Otherwise, to try and fix the CDN, see my steps for Office 365 CDN tweaking here.

References

More info about Office 365 CDN:

• https://docs.microsoft.com/en-us/office365/enterprise/use-office-365-cdn-with-spo
• https://docs.microsoft.com/en-us/office365/enterprise/content-delivery-networks
• https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges?redirectSourcePath=%252farticle%252f8548a211-3fe7-47cb-abb1-355ea5aa88a2
• https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/hosting-webpart-from-office-365-cdn
• https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service

If you want to read more on Office 365 CDN, these are good sources to get started!

• Author
• Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)

• How to stop Surface Headphones from autoplaying audio when you place them on the desk? - December 10, 2024
• “Phone Link” permanently disabled and Windows claiming “Some of these settings are managed by your organization”? (Probably) an easy fix! - December 3, 2024
• Refreshing DefaultAzureCredential in Visual Studio - November 26, 2024