If Multiple Sources Are Listed in an @Font-Face, Are All of Them Loaded on the Client Side

If multiple sources are listed in an @font-face, are all of them loaded on the client side?

A typical browser should attempt to load the fonts in the list one by one, depending on what format it supports, starting from the first in the list. Once it obtains a font file that it can use, it doesn't attempt to load any of the rest of the files in the list. If a browser doesn't support a particular format, it should never attempt to load that font; it should move straight on to the next source and looks at that.

This is similar to how a browser uses a font stack in the font-family property.

Of course, not all browsers behave conformingly to the spec. Some browsers like IE will try to download as many fonts as they can or parse the rule in unexpected ways; see the comments for more info and research.

CSS is already designed to help minimize the load time and number of requests through this sequential approach. If your fonts are taking too long to arrive from your own server, consider using a fast CDN instead like Google Web Fonts, Typekit or Adobe Edge.

Will multiple @font-face formats slow download?

Under certain circumstances, some browsers will download multiple formats of the same font-face.

A thorough explanation can be found at Bulletproof @font-face syntax, but the gist of it is that FontSquirrel is doing all the hard work for you and their syntax implements the the best syntax and prevents multiple resources from being downloaded.

The article is worth reading and also provides links to more information.

Is there any performance impact of using too many font-face declarations?

If I understand your question correctly, you're not asking for network loading times but rather for the time to select the right font declaration from the loaded list.

The time to select the font from the css file is neglectable. Almost any other operation while loading your site will take much more time. If you'd like to test this with your browser of choice, just open the css file in the browser and search for any font with CTRL+F. The results should be visible in less than 100ms, even on older machines.

Anyway you should consider that not all browsers behave the same and that Internet Explorer (or at least the older versions) WILL download every font you declare. It doesn't matter if you use it or not so your project won't be an option if the site should be cross-browser compatible.

Where are @font-face files stored on the client side?

Where is this file stored on the client's computer?

Wherever the browser wants (including, possibly, only in RAM).

How easy is it for the client to obtain the file?

Trivial. They can read the URL from the CSS file and download it manually if nothing else.

@font-face SyntaxError when using typeface-nunito-sans and @poi/plugin-vue-static

Fixed this by adding process.client check:

if (process.client) {
  require('typeface-nunito-sans');
}

This prevents CSS from being processed in server-side code /p>

On IE CSS font-face works only when navigating through inner links

I found a solution but I cannot see the reason why it works (well, only one reason - it's IE :D).

What I did was to put the same site on Apache and test again. On Apache the fonts worked fine even when using Refresh button. Then in the network inspector I saw that Apache is returning 304 instead of 200 for the eot file and it hit me - so it's caching issue. I went to my ASP.NET app and sure enough - for security reasons (and also to avoid caching AJAX requests) someone had disabled every caching you could imagine:

        // prevent caching for security reasons
        HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(false);
        HttpContext.Current.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
        HttpContext.Current.Response.Cache.SetValidUntilExpires(false);
        HttpContext.Current.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
        HttpContext.Current.Response.Cache.SetNoServerCaching();

        // do not use any of the following two - they break CSS fonts on IE
        HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
        HttpContext.Current.Response.Cache.SetNoStore();

As soon as I commented out the last two lines of code, suddenly fonts started to work without problems on IE. So I guess the answer is: IE cannot load the font if it is not cached. I have no idea why the problem happens only when refreshing/navigating back, though.

Edit - Alternative solution

Instead of commenting those last two lines

    // do not use any of the following two - they break CSS fonts on IE
    HttpContext.Current.Response.Cache.SetCacheability(HttpCacheability.NoCache);
    HttpContext.Current.Response.Cache.SetNoStore();

Change the SetAllowResponseInBrowserHistory to true instead:

HttpContext.Current.Response.Cache.SetAllowResponseInBrowserHistory(true);

This should still allow no-cache with the exception of back and forward navigation as I understand it.
MSDN - SetAllowResponseInBrowserHistory Method

---

Related Topics