Ensuring text remains visible during webfont load

Hi,

Please can you give a definitive answer to the topic.

There are numerous forum posts on referencing FOIT/FOUT/webfont issues with Pro/X-Theme. The responses range from ‘don’t worry about this (Themeco support response from 2019)’ to ‘read this article’ -> Paid Plugin. There are also articles referencing ‘general page speed improvements’ and others referencing google fonts and preloading.

Digging deeper, there are many articles when searching Google which serve to over-complicate the matter - debating what needs to be done; HTML/CSS/JS - and whether to use Swap/Optional etc.

We have uploaded our fonts and used a plugin to preload them - then used Cloudflare to manage cache/preloading. However we still get the following results from PageSpeed analysis an GT Metrix:

Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading.

Learn how to improve this

What does do recommend doing (CSS/HTML/JS) and where do recommend placing any code to sort this issue out. Just so you are aware, we previously used our TypeKit resource from Adobe and also Google Fonts, however, because of the way Google and Adobe manages fonts, this does not bode well for a decent page score - we don’t really care about this, however, Google appears to do so and we need to know how to improve this.

We would like to have sans-serif fonts visible whilst the ‘preloaded fonts’ are loading - which seems bizarre, because they are being preloaded yet GTMetrix and PageSpeed still produced the errors.

We’ve seen articles on the forum that say ‘use the absolute URL’ and others which reference …/…/ or /uploads/etc

Please can you help out and let us know exactly how to fix this issue. It’s a really common issue that we face and I can see that users were requesting this in 2019 on the forum. Please may we have a definitive answer to understand what to use (exactly) and where to place this (eg global CSS? etc).

Hey @stuartmurphy,

The Font Display setting you would want is swap. That will load the fallback font according to this article.

However, the fallback would only work if it’s added in the list of fonts like font-family: "my-custom-font", arial, sans-serif;. That is not currently possible in Cornerstone as you can’t set a fallback font.

You can do that with your own custom CSS as shown in the screenshot below.

image

A feature request has been submitted for the font fallback so it might be taken into account in a future version.

For now, you will need to assess what elements you need to use the font with and override the font-family like shown in the screenshot. Regretfully, we couldn’t provide you with custom CSS as that is beyond the scope of theme support.

You might want to check out One where we can provide custom development guidance.

Hope that helps and thank you for understanding.

Christian,

Thanks for the reply. I see that Support placed a request for this with your Dev team in 2019 and the answer to clients requesting help is similar to what you have provided. I’ve output this issue to Fivrr for a response. This is quite a headache of an issue, especially as we’d expect the theme to have a solution for this - likewise for Font Awesome, though preloading works well for this, but nonetheless, there’s always been issues with blocking / FOIT with X. It would really help if Themeco could address this common issue via a tutorial or clear documentation. We would have thought preloading the fonts and storing them locally (stripping out Typekit and Google Fonts) would have been sufficient and you’ll be aware of the importance of this request as users seek to reduce overall blocking times. The font loading issue is one which is commonly flagged up by page loading tests.

Hey @stuartmurphy,

Please note that the “render-blocking” issue is not the same as the FOUT issue. The render-blocking issue is not just because of our theme. It happens to other themes as well as WordPress itself so that is why you must set up an optimization plugin. That however is beyond the scope of our theme support to discuss.

The FOUT issue can be solved by having a fallback font and we already have submitted a feature request for that. We can’t create documentation of a non-existent feature (the fallback font) in the theme.

Please kindly check the future updates.

Thanks Christian

You are most welcome @stuartmurphy

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.