Consent to the use of Personal Data and Cookies

This website needs your consent to use cookies in order to customize ads and content.

If you give us your consent, data may be shared with Google.

Fix: Consider taking a look at crossorigin attribute

How to fix a problem causing chrome to complain about the crossorigin attribute on a preloaded resource.


By. Jacob

Edited: 2021-12-13 04:06

A preload for x is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.

This problem can happen because of incorrect use of the crossOrigin attribute and browsers Same-origin policy when loading externally hosted resources via certain methods. One of these methods is when preloading resources from external sources. But, crossOrigin should not be needed for resources hosted on the same-origin (same domain/host), in which case you can try and remove the crossOrigin attribute from the link tag to fix it.

Note. The exception seems to be when loading fonts, which require the presence of the crossOrigin attribute, even when loading the fonts from the same-origin. Source:

But what if you are loading a resource from an external source?

Then you should try using the anonymous setting:

<link rel="preload" href="" as="image" type="image/png" crossOrigin="anonymous">

The anonymous is implied, so you can also leave it out, and only enter crossOrigin.

<link rel="preload" href="" as="image" type="image/png" crossOrigin>

It is used to tell the browser not to include credentials with the request; credentials includes things like cookies and HTTP authentication entries. If you do want this data included, then you should use a value of use-credentials instead.

The as attribute can contain a value of:

  1. image
  2. style
  3. script
  4. media
  5. audio
  6. font
  7. video
  8. object
  9. embed
  10. worker
  11. manifest

Also, do not forget about a valid mime type for the type attribute.

Http2 link preload header

Alternatively, if you at least use HTTP2 and you got access to the server-sided code, you may want to consider adding the "essential" resource in a preload HTTP header instead:

header('Link: </root/relative/some-essential-css-file.css>; rel=preload; as=style');
echo $html_template;

Remember, it is about preloading as early as possible, so the HTTP headers will be a better place to add your preloads. In addition, you may also consider adding some of your CSS in the body of your HTML, as it allows for a more optimized rendering of your page, and despite not being entirely standardized, it is actually supported by browsers.

Preloading from the head

Browsers restrict loading of external resources with XMLHttpRequest and fetch APIs, which includes link tags with rel="preload" in the head part of a HTML page. It seems you should also specify a mime type on such preloaded resources:

<link rel="preload" href="/path/to/logo.png" as="image" type="image/png">

Because loading external resources is sometimes a security issue, especially when said resources are inserted by untrusted users, browsers typically limit which resources are allowed to load. But, besides that, site owners can also use it to prevent other people from leaching their resources. I.e. Loading of font files or embedding via iframe's without the authors permission.

CORS policy

The CORS (Cross-Origin Resource Sharing) policy works by clients sending a Origin: header along with their GET for said resource; this in turn allows the destination (in this example a CDN server), to validate that the client is allowed to fetch the content.

A standard way to allow all origins to fetch a given resource is to include the Access-Control-Allow-Origin: * in the response headers. Or, a specific origin:

A simplified request might look like this:

GET /images/some-image.png HTTP/1.1

In order for us to be able to load the resource, the cdn server must respond with:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

Note. This will NOT prevent hot-linking of images. This only applies to certain resources, such as those loaded via font-face, preload, or XMLHttpRequest and fetch APIs, in accordance with CORS policy.

This has at least a couple of uses; one is the added security, and another is to restrict other websites from loading your font files without your express permission.

Tell us what you think: