The demo-head submodule no longer exists, so can't be updated after cloning.

Hi,

Do I have to do anything else but

• adding the script to my site
• editing the fonts used in the lower function of the script
• adding the @font-face rules to my site
• adding a css class .fonts-loaded body with my font-family in it

?
I tried so, but unfortunately the class .fonts-loaded is not added to my page, so that the text won’t be show in the right font. Have you any idea how I can debug this or if I may have overseen something?

Hi! I've tried this technique and got it working on Chrome. However, on Firefox, I got the following error in the console and all fonts on the page are the fallback ones.

downloadable font: incorrect file size in WOFF header..

Tried googling but it seems like most of the results are not specifically about font embedded as data uri. Any idea?

This is ... really odd, so odd that at first I thought it was what you were trying to show.

This is how the demo page for Font Events looks in Chrome 42 on Vista:

This is how the Data URIs page looks:

I only see the messed-up font in Chrome -- the particular mess-up depends on whether I zoom the browser, but something is wrong at every size.

What's the difference between the URI files and the @font-face files? Whatever is causing this, I want to make sure not to do it!

Im using http://master.origin.font-loading.fgtest.com/data-uris-cookie.html

And now I get this error in chrome:
Failed to decode downloaded font: data:application/font-woff2,

How to fix this?

Unless I misunderstand part of the latest recommended technique, the HTML markup is different depending on whether a cookie has been set. This means that the page cannot be properly cached, and we all know how important proper caching is for performance.

I have a question about the final step of your new recommendations to set a cookie and then apply the "fonts-loaded" class immediately to the HTML in order to speed up the font-loading on subsequent page loads.

This seems unreliable to me. How do we know how long to set the cookie for? The amount of time the font files will be cached will be determined by the server's Cache-Control headers, so you'll need to ensure that your cookie's expiry length matches that value. (Right? I'm not 100% sure of this)

Or what if the user decides to clear their cache through their browser, while keeping their cookies intact? With the demo script, the function to get FontFaceObserver to fetch the webfonts would return early, and so the user would have no webfonts at all until they clear their cookies.

Could you elaborate on what other steps you need to take, or things to consider, before employing this optimization?

Related also #1. Test both methods.

The demos dissapeared :(