Asset optimization - preloading fonts

Support
1

Couldn’t see anything on this and was not sure where it should go, hence posting here.

I would normally do something like this to quickly load a subset font before loading the full fonts later.

In the head:


<link rel="preload" href="/assets/fonts/myfont-subset.woff2" as="font" type="font/woff2" crossorigin/>
<style>
@font-face {    
  font-family: 'myfont';    
  src: url(/assets/fonts/myfont-subset.woff2) format("woff2"),     
  url(/assets/fonts/myfont-subset.woff) format("woff");    
  font-weight: 300;    
  font-display: swap;
}
</style>

When served from Netlify you can see the CDN for the fonts in the CSS, but not on the ‘link preload’ Does preload actually work or am I missing something?


<link rel="preload" href="/assets/fonts/myfont-subset.woff2" as="font" type="font/woff2" crossorigin/>
<style>
@font-face {    
  font-family: 'myfont';    
  src: url("https://d33wubrfki0l68.cloudfront.net/f0755cab1e08e3d758265757e5191595c7a85926/bac8d/assets/fonts/myfont-subset.woff2") format("woff2"),     
  url("https://d33wubrfki0l68.cloudfront.net/afa235179956eb63e0f0ab05bc8d77061ebd2b32/cb722/assets/fonts/myfont-subset.woff") format("woff");    
  font-weight: 300;    
  font-display: swap;
}
</style>
2

The cloudfront URL’s are the result of asset optimization, as configured on your site’s deploy settings page most of the way down:

image

Things that get optimized (which don’t include the <link> tag at present) will get rewritten to cloudfront URL’s. HOWEVER all content we serve is served from a CDN - that’s just the CDN we use for optimized assets. All traffic from netlify comes from some part of some CDN :slight_smile:

If you want things to be consistent, turn off that feature in our UI. But hopefully things work normally, even if they look a little weird in the source code?

3

Thanks Chris, it does seem to work, I was just a bit confused.

We don’t process the CSS, JS and Images as they are already compressed, but we do like the Pretty URL’s - hence settings.

So all good, consider me a bit less confused…

4

Glad to hear that @AudioBear! If you have any other questions, feel free to ask.

5

By any chance Netlify will optimize <link> tags in the future?
I’m preloading static font assets and it causes double downloading.

image
image.png693×258 15.6 KB

6

Hi @phuoc,

We don’t have any immediate plans to work on this, but it’s something we may address in the future. Can you provide a link to the page where you’re getting the double asset loading? Thanks.

7

Hi futuregerald

You can take a look here https://dreamy-babbage-f68941.netlify.com/ using Chrome.

What happened was I deployed the site without asset optimization. Everything works correctly as the font url is /static/.....

Once I enabled asset optimization, the font url becomes cloudfront url, and it shows double downloading in Chrome.

So I disabled asset optimization and only enabled Pretty URLs, the problem persists.

1 Like
8

Actually we are seeing this on Chrome as well, same as phuoc with just Pretty URL’s enabled,see:

9

effectively, ANY asset optimization set in netlify’s build settings will likely cause this behavior. You can’t know the URL of the optimized assets during build time, so it’s impossible to change your references to point to just those.

We don’t have any plans to update this behavior at present, so you should choose one or the other (asset optimization or preloading) for best results on netlify.

1 Like
10

I just wanted to chime in saying that I ran into the same issue on my project: fresh open of excalidraw doesn't render correct font in Firefox · Issue #637 · excalidraw/excalidraw · GitHub

To clarify what’s going on, the gets url rewritten to be hosted on the CDN, including the link to the font inside of the stylesheet. Unfortunately, the url rewriting doesn’t work on the . This means that the url for the preloaded font and the font in the css are different, essentially breaking preloading and downloading the font twice.

The real fix would be for netlify to update the url rewriter to also take into account which seems like it would be a small change.
The workaround is to disable the url rewriter (which is unfortunate because it’s nice to have things on a CDN).