When Do Web-Fonts Load and Can You Pre-Load Them

When do web-fonts load and can you pre-load them?

When are webfonts downloaded?

Paul Irish made a simple page to test this: http://dl.getdropbox.com/u/39519/webfontsdemo/loadtest.html

It shows that most browsers download fonts when they're used in a page rather than when they're declared in CSS. I believe IE is the exception but I don't have it running to test right now.

The reason for downloading on usage rather than on declaration is to reduce unnecessary network traffic, e.g. if a font is declared but not used.

Can font downloading be avoided?

You're right that if fonts are already installed they shouldn't need to be downloaded. As @Patrick said above, this can be done using local(). It's placed before url() in the CSS and takes the name of the font (the PostScript name is subsequently needed for Safari on Mac OS X). Try out the following change to your CSS:

@font-face {
    font-family: 'Roboto';
    src: url('../fonts/Roboto-Regular-webfont.eot');
    src: local(Roboto Regular), local(Roboto-Regular),
         url('../fonts/Roboto-Regular-webfont.eot?#iefix') format('embedded-opentype'),
         url('../fonts/Roboto-Regular-webfont.woff') format('woff'),
         url('../fonts/Roboto-Regular-webfont.ttf') format('truetype'),
         url('../fonts/Roboto-Regular-webfont.svg#RobotoRegular') format('svg');
    font-weight: normal;
    font-style: normal;
}

Finally, to reduce font download times, you could make sure you're doing the following:

• Putting CSS before JavaScript
• Adding far-future Expires headers for
  the fonts (so the browser caches them)
• GZipping the fonts

Here's a good summary of dealing with font display delays: http://paulirish.com/2009/fighting-the-font-face-fout/

Preloading @font-face fonts?

This answer is no longer up to date

Please refer to this updated answer: https://stackoverflow.com/a/46830425/4031815

---

Deprecated answer

I'm not aware of any current technique to avoid the flicker as the font loads, however you can minimize it by sending proper cache headers for your font and making sure that that request goes through as quickly as possible.

Wait for fonts to load before rendering web page

This is down to how the browser behaves.

First off where is your @font declared? Is it inline to your HTML, declared in a CSS sheet on the page, or (hopefully) declared in an external CSS sheet?

If it is not in an external sheet, try moving it to one (this is better practice anyway usually).

If this doesn't help, you need to ask yourself is the fraction of a second difference really significantly detrimental to the user experience? If it is, then consider JavaScript, there are a few things you might be able to do, redirects, pauses etc, but these might actually be worse than the original problem. Worse for users, and worse to maintain.

This link might help:

http://paulirish.com/2009/fighting-the-font-face-fout/

Do you need to pre-load fonts in the head and declare them in CSS as a font-face?

Both declaration don't have the same goal.

The preload value of the element's rel attribute lets you declare fetch requests in the HTML's , specifying resources that your page will need very soon, which you want to start loading early in the page lifecycle, before browsers' main rendering machinery kicks in.

• Source @ https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

If you add preload by itself, your font won't be taken into account. You have to specify the action too.

<link rel="preload" href="style.css" as="style"> <!--preload-->
<link rel="stylesheet" href="style.css"> <!--action-->

Here we preload our CSS and JavaScript files so they will be available as soon as they are required for the rendering of the page later on.

Like Graham said in the comment, preload can only be efficient if it is specified before any font related actions like the <link> tag (loading font via html) or the css file itself.

Additionally, your request is dependent to style.css. loading your font in the html could greatly improve performance. Either by inlining it in a <style> tag or by loading through the <link> tag.

With the recents improvements to font servicing using CDNs, loading a font from a locally saved version as become inefficient. The local version should be used as a fallback. I would recommend you take a look at Google Fonts.

<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@300;400;700&display=swap" rel="stylesheet">

On a side note .ttf shouldn't be used, it's not optimised. @ https://stackoverflow.com/a/11002874/3645650 consider using .woff and .woff2 instead.

(Run lighthouse with your browser set to incognito mode, to get actual reliable information).

When to use rel=preload? Why is preloading fonts/FontAwesome a good idea?

You will often see this recommendation if you use @font-face to load fonts in.

To understand why you get this recommendation you have to consider how the browser receives and parses information.

1. HTML is downloaded, browser looks at all the assets to download it found in the HTML and starts downloading them and parsing them.
2. The browser discovers a CSS file and downloads it. When that CSS file has downloaded and been parsed your browser finds a reference to your 'font-awesome' font and then adds that to the list of things to download.
3. The browser downloads that font, but a lot later than it is needed.

By adding preload to the item your order changes to HTML first, then CSS and the font-awesome font at the same time, meaning a key asset is loaded earlier.

Why is this important?

To understand why this is important you need to understand 'critical requests' - those are all the assets required in order to render the 'above the fold' content.

Above the fold content is content you can see without scrolling the page.

Now if you have any icon showing in this 'above the fold' content then your font-awesome font becomes part of your 'critical request chain' - i.e. content that is essential to paint everything above the fold.

By using preload you get the font delivered sooner (2 steps not 3 as illustrated earlier), so your above the fold content can be rendered sooner and so your site appears to load faster - this is a major factor in PSI scoring and real-world conversion rate improvements.

Should I use rel="preload" then?

In most circumstances yes you should if it is recommended, it reduces your critical request chain depth and normally results in faster loading times. However you do need to check your critical request chain to ensure it isn't a false positive (PSI isn't perfect).

The easiest way to check is to open developer tools, enable 3G throttling on the network tab and then see if the page displays faster with or without preload.

Is it my best option for the scenario given in the question?

In this example, no, but only because font-awesome is not a good idea in general.

What you really want to do is get rid of font-awesome entirely. Icon Fonts are an out-dated and terrible practice us web developers have adopted that just won't go away.

Instead of loading a 50kb+ file (for each 'weight' of font-awesome you use) plus 30kb of CSS why not use inline SVGs instead.

Inline SVGs have several advantages, but the key ones are:-

1. As they are inlined in the HTML you remove at least one network request (normally 2-3) - great for speed.
2. They are tiny - a typical icon is less than 1kb unzipped - with 10 icons you said you use that is 10kb total before zipping. Compare that to 180kb zipped for font-awesome fonts, CSS etc. and you can see the performance improvement.
3. As you have inlined your icons within your HTML you reduce your 'critical request chain' length, so you can get to sub 1 second initial page renders (obviously you need to inline all of your critical CSS required for the above the fold as well.)
4. The most important reason - people use custom stylesheets on your websites. For example people with dyslexia may prefer a certain font as it is easier to read, so they may force a site to use that font. Your beautiful 'font icons' become the dreaded 'missing character square box of doom' - which makes it really difficult to know what they are clicking. Accessibility is becoming more and more important!

Note on point 2 - the reason icon fonts are so large is they contain hundreds of icons. It is possible to reduce them to be slightly smaller that inline SVGs but that kind of optimisation often gets over-looked and is actually more time consuming than simply inlining and referencing SVGs. I just thought I would add this for completeness.

preloading font with rel preload

Your preload-Tag takes the argument "crossorigin", which must be given for Webfonts, even if they are on the same host as your website.

See https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content#Cross-origin_fetches or https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/#early-loading-of-fonts .

Right way to pre load fonts?

when using @font-face in CSS, it is down to browser, how it behaves.

It's good to use external CSS sheet for declaring fonts.
If this doesn't help, you could try making different CSS files with fonts for different subpages. As you mentioned, you don't use all fonts on all subpages, so it may reduce the filesize and consequently load faster.
Once I was working on a project with a lot of fonts and I had similar problem. The best solution then was to base64 encode all of the fonts I used. So by that approach, all of the fonts had to be loaded before HTML was parsed and displayed. Font squirrel's webfont generator found here: https://www.fontsquirrel.com/tools/webfont-generator can be really helpful tool. If you will use it you should click "Expert" and "base64 encode".
Also, for testing and seeing how your load times improve, you can check out Fontloader here: https://github.com/smnh/FontLoader . It detects when fonts of the specified font-families loaded and rendered by the browser so you can see which step is taking the most time.

---

Related Topics