Everything You Never Wanted to Know About CORS and Font Preloads

CORS and font preloads – it’s complicated. When fonts are preloaded via <link rel="preload" as="font">, we must always include the crossorigin attribute. If we forget it, unexpected issues may arise as we will see later. But there are scenarios where problems cannot be avoided – even if best practices are followed. But let’s start at the beginning:

1. What is CORS?
   1. The crossorigin Attribute
   2. Safari’s Peculiar Behavior
2. The vary: Origin Dilemma
   1. The Scope of the Issue
   2. A Real-World Example
   3. Live Demo of the Problem
3. How Browsers Can Improve

What is CORS?

In simple terms, CORS is a protocol that lets webservers control which resources are allowed to be downloaded from other origins (different domain, port or protocol). The webserver declares in HTTP headers which origins are allowed to download given resources. If you want to know more about CORS and its origin (pun intended), check out this great article be Jake Archibald

In the context of this post it’s important to understand that – according to CSS specification – font requests shall always be made with CORS.¹ This also applies to when the requested font is hosted on the same origin (same-origin). In such cases it adheres to the CORS same-origin policy. Why this is the case is not easily explained.^a But it is what it is.

Also important to know: CORS requests will come with an Origin HTTP header, where the value is set to the origin that initiates the request. This header can be used to determine if the request is allowed or not.

The crossorigin Attribute

Requests initiated by preloads will only be made with CORS if we explicitly demand so. This is done via the crossorigin attribute, which will classify the request as CORS and also sets the associated credentials mode.² Since, as noted, font requests must always be made with CORS and while preloads are (currently³) performed without CORS by default, the crossorigin attribute is required for font preloads.

Safari’s Peculiar Behavior

Only Safari deviates from the specs and does not load fonts with CORS when initiated from CSS. This has resulted in ongoing discussions.⁴ The arguments against following the specs are a bit hard to grasp,^b but again, it is what it is. Try it yourself.

While this deviation does not cause harm in most circumstances, it can lead to severe issues when combined with font preloads.

The vary: Origin Dilemma

Sometimes it’s necessary to include a vary: Origin header in the response to a font request. For instance, when we want to allow loading of a font from more than one origin, but not all origins.⁵

Unfortunately, we are now in a scenario where we can’t preload fonts without causing caching issues.^c There is currently no way to satisfy all browsers.

The Scope of the Issue

Here are some numbers to quantify the impact:

• 11% of all websites use font preloads for at least one font. ⁶
• An HTTPArchive BigQuery analysis shows that 3.38% of font requests include a vary: Origin response header. ⁷
• 98.5% of <link rel="preload" as="font"> elements specify a crossorigin attribute. ⁸

Combining these statistics, we can estimate that Case 1 (CORS preload with vary: Origin) affects roughly 1 in 273 websites, while Case 2 (non-CORS preload with vary: Origin) is less common, affecting 1 in 17,930 websites. That might seem insignificant, but major platforms can still be impacted — as demonstrated in the next section.

A Real-World Example

Recently, I came across this exact issue while testing the Bluesky web app. The problem became apparent when I used a fun tool by Brian Louis Ramirez^d that was introduced in the Web Performance Calendar.⁹

It turned out that Bluesky was preloading their webfonts without CORS and those fonts answered with a vary: Origin header. The scenario described above appeared and in this specific case caused more than 1MB of data uselessly being transferred on every page load, including refreshes. Purely because of a missing attribute, one that is called crossorigin and counter-intuitively should have been set for same-origin fonts.

The consequences of a Missing Attribute

In addition to the decreased font-loading performance the mistake had a substantial impact on carbon emissions.

• The issue was present for around three month (Oktober – Dezember 2024). In this period the website das 350 million visits according to similarweb.¹⁰
• Roughly 77% of visitors were using Chromium-based browsers 18% were using Safari.¹¹
• Calculating conservatively, we assume that no page refreshes were done during visits and that 10% of those visits came from first-time visitors.
• On Chromium the bug caused 505KB of extra data transfer for first-time visitors, for repeated visitors the bug caused 1.01MB of extra data transfer. Ironically, on Safari the bug saved data transfer. For repeated visitors it saved 505KB of extra data transfer.
• The numbers above lead to 256 Terabytes of unnecessary data transfer on Chromium-based browsers and 30 Terabytes of saved data transfer on Safari.
• With the open-source library co2.js this leads to 28 tonnes of CO₂e being emitted uselessly.^e

Live Demo of the Problem

I prepared a small live demo. Check it out with different browsers. On click on one of the buttons below we can reload an iframe. It preloads a webfont that CSS then tries to use. Info about the HTTP-request(s) is then output in the iframe. The text on the buttons have the following meaning:

• with/noCORS: Fonts preload will be done with/without crossorigin attribute
• with/no vary: the font responds with/without vary: Origin header

What I find particularly interesting is that in Chromium-based browsers the font preloaded without CORS will be fetched from the HTTP cache if no vary: Origin is involved.^f

Another nice surprise was to see that Firefox preloads fonts with CORS even when no crossorigin attribut is set.

How Browsers Can Improve? Be like Firefox!

Browsers should default to the mode of the requested resource type when doing preloads. In Chromium-based browsers this means, that font preloads should automatically be done with CORS. An according proposal has been submitted for the HTML specifications.³ Implementing this suggestion would eliminate potential problems in Chromium. I really hope the proposal will be accepted this time around – unlike 10 years ago when a similar one was rejected.^g

For Safari, however, this change would not eliminate the issue, because in Safari’s case the crossorigin attribute that is explicitly set would have to be ignored. I don’t think that this would be intended in the proposal mentioned above. Instead, Safari should make font requests with CORS like all the other browsers do. Together with the proposal above this would eliminate the described issues, it would follow the specification and ensure consistency between browsers.

In short: Chromium and Safari should follow Firefox’s example. Firefox correctly initiates font requests with CORS and executes font preloads as CORS requests, regardless of the presence of a crossorigin attribute. Try it yourself using the live demo above.