A preload for '[AzureCDN]/hello-world-web-part_25beead865729ba82e5f.js' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.

[MarksPoint]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

macOS

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [ ] 💥 Microsoft Edge
• [X] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• browser version: Chrome Version 120.0.6099.109 (Official Build) (arm64)
• SPFx version: 1.18.2 (but issue exists at least since 1.14)

Describe the bug / error

Deploying an SPFx solution to Azure CDN results in the following browser warning:

A preload for '[AzureCDN]/hello-world-web-part_25beead865729ba82e5f.js' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.

We've got our SPFx solutions deployed to Azure CDN, and we've been seeing this behaviour for a long time now. We're not sure about the actual performance impact because the script is eventually cached in browser (so re-loading should be fast), but nevertheless we feel like there's some performance improvement we're missing out on.

If I disable cache in my browser (devtools), and open something like Fiddler to inspect network traffic, I see the following two requests that both load the same script file, but seem to differentiate primarily in the cors/no-cors header:

I think the first request is for the 'preload', but the result of is discarded (according to the warning).

Looking at the HTML of the page, I see the <link tag that's responsible for the preload:

<link rel="preload" href="https://[AzureCDN]/hello-world-web-part_25beead865729ba82e5f.js" as="script" crossorigin>

Steps to reproduce

I followed these steps to create a new dummy web part that was then uploaded to Azure Storage:

https://learn.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/deploy-web-part-to-cdn

Additionally, I made the storage account anonymously accessible and I added the following CORS settings on the Blob service:

This to prevent CORS errors that would otherwise appear, loading the script file(s).

Expected behavior

Preloading the script should work as expected, providing performance improvements to loading the (web part) script. The script should not be loaded twice.

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[MarksPoint]

I understand that my question isn't an easy one, but I would really like to know if I'm doing something wrong or if there's something fishy at the SharePoint side of things. Bump?

[MarksPoint]

Anyone?

[MarksPoint]

I could really use some help or advice here... Since there's no reply so far, I'm not sure if my question is to vague, or the issue isn't reproducable, or it's just not high-prio enough, or...?

[MarksPoint]

I'll just start bumping this until someone replies... Not sure what else I can do to bring this to your attention.

[MarksPoint]

Help!

[MarksPoint]

@VesaJuvonen @shagra-ms This issue appears to have dropped from everyone's radar and I'm not sure how to bring this to your attention. Any ideas here? Maybe re-tag this one with Needs: Triage? Thanks!

[andrewpeterson99]

I think I'm running into this same issue. @VesaJuvonen @shagra-ms any updates?

[MarksPoint]

@andrewconnell @AJIXuMuK could you shine a light on this? It's been open for ages and no one seems to want to reply...

[andrewconnell]

Have to yield to Microsoft on this... not sure why they wouldn't include "crossing=anonymous" to the preload (a way to get around the credential response).

[MarksPoint]

Thanks for the prompt reply, @andrewconnell. Is this something that you can take to MS, or is it something I should do?

[andrewpeterson99]

This issue also occurs for the customers who have the .js load error. in my case Not sure if they're linked or not.

[Amey-MSFT]

Hello @MarksPoint, Thank you for bringing this issue to our attention. Could you please confirm if the issue still persists for you?

[MarksPoint]

Hi @Amey-MSFT,

Yes, absolutely! I just confirmed that I see this message in our production environment:

[Amey-MSFT]

Hello, We were able to reproduce the issue, and we are investigating it. We have logged this as a bug, and our engineering team will look into it. Thank you!

[MarksPoint]

Any update on this issue? It's been open for so long now...