Font Face Causes Performance Issues

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.

@font-face is causing slow load times

I used base64 enconding to embed the font inside the CSS to reduce the amount of requests. The base64 has the downside of costing more initial bandwith but hey, it works! This fixed it.

Ofcourse i'm not really happy with a CSS file that is 180KB in size :/

Edit:
It turned out to be the ISP that was the problem. When I mannualy loaded the font it retrieved it from cache (dammit chrome!). Somehow these fonts where not directly available on the ISP service and requests/reads from the harddisk would take a while.

@font-face rendering performance

@Husky,

I have been using @font-face embedded fonts for all the type for a while now and I have have not had any problems with rendering or performance.

Steve Sauders has an excellent article about website performance effects of @font-face

The clearfix hack in the article you referenced will slow down the site on all versions of IE. All the IE filters cause performance issues.

Should @font-face declarations be done early in the css file or towards the end?

The position of declaration doesn't really affect the performance provided that the font has been used only after declaration. I don't think there is any difference in using an external CDN. For further reference see this.

Does Flash of Unstyled Text - FOUT, impacts website performance?

Short Answer

FOUT has no impact (a tiny rendering time impact) on performance in terms of load speed, it does affect user experience.

Longer Answer

A Flash of Unstyled Text (FOUT) itself doesn't affected performance, it is a consequence of Web Font performance.

The browser loads it's default font and then when the webfont loads it swaps the new font in. As Web Fonts are normally relatively large files that is where the performance aspect comes in (and people seem to download 10 variations of fonts adding hundreds of KB to the page size).

Now there is a big issue with FOUT / font-swapping. This often results in a layout shift which affects your Cumulative Layout Shift (CLS) for the site.

It is user experience you are bothered about here with FOUT (which is what CLS is designed to partially measure).

If anything a FOUT is good for performance (load time), the page displays quicker than if you simply hid it until the font loaded in.

Solutions?

As with anything there are loads of things you can do to mitigate the issues but they all have tradeoffs.

One example (and what I believe is currently the best solution) is to use a web safe font set on initial page load.

Then load the custom font(s) using a service worker and store them locally.

Then when the user navigates to a new page (or returns to the site if they immediately leave) you have the font cached locally and can serve it from there.

I have over-simplified the above, it is not a simple thing to implement but it is the best performance to experience balance.

If you really want to push the envelope you might want to look into Variable Fonts as support is pretty good for variable fonts and it massively reduces the number of font variations you need (to one).

Custom TTF fonts loading slowly in React app

The delay in loading the web fonts is an expected behaviour issue and it's happening because the browser load the fonts when it detects a DOM element with a CSS selector that matches the font-face rule and that happens when then HTML file and all the CSS files have been downloaded on the client. It's a lazy loading mechanism. There are some solutions to improve this behavior:

• Use optimized web font file:

  For better performance, you can swap your TTF font file in the
  font-face with the woff and woff2 file formats. these formats are
  compressed in gzip thus reducing the file size and initial
  downloading time on the client. If those formats are not available
  you can use one of many online tools to convert the font file (google
  TTF to woff2).

---

• Webpack Preload:

  In webpack 4.6.0+ you can preload modules. this uses
  the preload hint in HTML link tags (<link rel="preload">). it will tell the browser to preload the resource before downloading the rest of the resources. To use this option replace import './fonts/tarrgetital.ttf'; with import(/* webpackPreload: true */ './fonts/tarrgetital.ttf');
  More on webpack preload here: https://webpack.js.org/guides/code-splitting/#prefetchingpreloading-modules and more info on HTML preload hint here: https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

---

Related Topics