WordPress ensure text remains visible during webfont load

WordPress ensure text remains visible during webfont load. In this article I’ll be discussing what the WordPress “ensure text remains visible during webfont load” issue is, why it’s a problem, what you can do to address this issue, and the benefits you’ll see after doing so.

If you’d rather simply cut to the chase and find out how to sort this out (not recommended) you can skip to the part that tells you how to address this issue by clicking here.

If you’ve got the time and the inclination, it would be a better idea to read through this post, as it will give you a much greater understanding of the issue and also how to address it.

I’ve been working on this topic for a while now, and I’ve written a couple of related posts. One that covers how to address ensure text remains visible during webfont load when using Elementor and Fontawesome within WordPress, which I’ll fully admit is a dirty fix (it involves manually editing the problematic CSS file to bring font-display: swap; in to effect – more on this in a moment) and unlikely to persist after updates. The other talks about how to make Google Fonts load locally when using WordPress which can bear some relation to ensure text remains visible during webfont load, but doesn’t completely cover this aspect.

I thought I’d write a full post about ensure text remains visible during webfont load to cover it as a universal topic, to cover it as a whole, and to provide some guidance that can at least be applied generally when encountering this issue.

What you’ll see as The problem with wordpress ensure text remains visible during webfont load.

You’ll probably be familiar with that the ensure text remains visible during webfont load problem looks like if you’ve been using something like https://pagespeed.web.dev/ to analyse your site:

And if you expand this section you’ll see something like this:

Ensure text remains visible during webfont load expanded

And if you click on “learn more about font-display” you’ll see some of Google’s advice about what the issue is and how it can be addressed.

Whilst the advice given is concise and does address the issue, it can be tricky to work out exactly how to do this in WordPress. This is due to WordPress being used so that you don’t tend to have to do this kind of thing (as it’s effectively been done for you), and WordPress being a very variable environment (due to the many different plugins and themes that could potentially be used) meaning that there’s no one size fits all answer that covers how to address this problem.

So Google’s advice is accurate, but it doesn’t really help you. You’re effectively being told how to address and issue that you were mist likely hoping to avoid by using a CMS that meant you wouldn’t have to do this kind of thing.

What the wordpress ensure text remains visible during webfont load problem is.

The ensure text remains visible during webfont load problem is pretty much what it says:

The text on your site may not be visible while webfonts are loaded.

It doesn’t take a great deal of time to load webfonts over what are considered to be normal network speeds, so in practical terms the text on your site may not be visible for a short period of time (a brief flash of invisible text, or FOIT).

Then again, if your font file is enormous and you’ve fallen through a hole in time and space and found yourself connected to a late 1990s dial up service, there might be no text displayed on your site for a bit longer.

So what is actually going on here?

When you browse to a page (using your browser) the page is requested, your WordPress then executes all it’s code, some of this interacts with your site’s database, your page code is then generated by the two, and sent to the browser. The browser then renders the page, and the page is displayed.

It’s the “browser renders the page” part that the ensure text remains visible during webfont load problem is specific to.

The browser effectively doesn’t know how to load the text on your site’s pages (so doesn’t) until the font file is downloaded. It’s this that causes the flash of invisible text. This is taking place because your site isn’t using a fallback font to display text, while the font file for your site is downloaded and applied to the page.

This is typically caused by the use of custom fonts, which is understandable given that the system fonts available in a browser can be limited. It is possible to use custom fonts without this issue being prevalent, by using directives in your CSS files, or in the URLs used to call custom fonts.

The flash of invisible text / ensure text remains visible during webfont load problem can extend beyond a flash of invisible text, as this can also cause:

Layout shift. This is when page elements move around on the page as the page is loaded.
Page load times. Having to wait for a font to be downloaded before the page can be displayed can make it take longer to display a page.

Addressing the ensure text remains visible during webfont load in theory.

This next part might sound along the lines of “malicious compliance” in the sense that I’ll be describing how these issues can be addressed, in a minimal way, with no guidance covering how to actually apply these changes. Don’t worry though, I’ll cover the “how you actually do this” in a moment.

The purpose of this section is to outline the fixes, and what they actually do, as it’s important to know what you’re doing and the effect it will have.

Use font-display: swap; in your site’s CSS:

The font-display: swap; directive tells the browser to use a fallback font. A fallback font is a system font (one that’s built in to the browser), and this can be used to display text while the font file your site actually uses is downloaded and applied.

The effect that this has is that instead of there being a brief flash of invisible text while your site’s font file is downloaded, there’s a brief flash of text being displayed using a system font (probably times new roman… ewww) while your site’s font file is downloaded. Does anyone actually like times new roman, or am I just being a snob (at least it’s not comic sans)? Anyway, by setting a system font as a fallback font, instead of there being a brief flash of invisible text, instead there’s a brief flash of unstyled text (FOUT).

Whilst this might not look particularly pretty, it does mean that text is displayed, as opposed to text not being displayed. It will also stop the performance score in https://pagespeed.web.dev/ being decreased.

You’d bring font-display: swap; in to effect by changing this in your site’s CSS:

@font-face {
font-family: ‘Pacifico’;
font-style: normal;
font-weight: 400;
src: local(‘Pacifico Regular’), local(‘Pacifico-Regular’),
url(https://yoursite.com/path/to/font-file.woff2)
format(‘woff2’);
}

To this:

Or, if you’re calling Google Fonts externally (although do be aware that are implications with regard to loading font files from external sources) you can add &display=swap to the end of the URL used to call the font file.

What this does is tells the Google Fonts API to include the font-display: swap; directive.

For example if you browser to here:

https://fonts.googleapis.com/css?family=Roboto:400,700

You’ll see this in the top part:

/* cyrillic-ext */
@font-face {
font-family: ‘Roboto’;
font-style: normal;
font-weight: 400;
src: url(https://fonts.gstatic.com/s/roboto/v30/KFOmCnqEu92Fr1Mu72xKKTU1Kvnz.woff2) format(‘woff2’);
unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}

Where as if you browse here:

https://fonts.googleapis.com/css?family=Roboto:400,700&display=swap

You’ll see this in the top part:

/* cyrillic-ext */
@font-face {
font-family: ‘Roboto’;
font-style: normal;
font-weight: 400;
font-display: swap;
src: url(https://fonts.gstatic.com/s/roboto/v30/KFOmCnqEu92Fr1Mu72xKKTU1Kvnz.woff2) format(‘woff2’);
unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}

So adding &display=swap to the end of the URL results in the called CSS including the swap directive.

So to do this you’d change the address used to call Google Fonts from this:

<link

href=”https://fonts.googleapis.com/css?family=Roboto:400,700″

rel=”stylesheet”

To this:

Preload webfonts:

This tells your browser to load font files earlier. You’re effectively telling the browser to fetch and cache the font file in the background, making it readily available when the font is actually needed to render text on the webpage.

To do this, you’d use rel=”preload” in your site’s code, like this:

Now, I’ll admit this one makes my butt tighten just thinking about it. Will the font file have been completely downloaded before rendering takes place? Well I guess that depends on the size of the font file, the size of the page and maybe the speed of the internet connection in use when requesting the page. So many variables! I’d suggest using this option with caution, and being sensible where you can to minimise the size of font files (using WOFF2 format font files to reduce the size of the font file, for example).

Make the loading of font files asynchronous:

What I’ve mentioned above (using link rel=”preload”) does make the font file downloading, but it’s also possible to use Javascript to make the downloading of font files asynchronous.

The Javascript technique gives you more control over how and when your fonts are loaded, but unless you’re coding your own Javascript (which in reality, most people using WordPress aren’t going to do) you’re going to be reliant on using a plugin.

Just for example’s sake (so that you know roughly how plugins might operate) this Javascript would make fonts load in an asynchronous manner:

var font = new FontFace(‘CustomFont’, ‘url(path-to-custom-font.woff2)’); font.load().then(function(loadedFont) { document.fonts.add(loadedFont); }).catch(function(error) { console.error(‘Font loading failed:’, error); });

In this example, the font is loaded using the FontFace API, and then it’s added to the document.fonts collection. This allows the browser to start fetching the font asynchronously.

Some of the plugins that can be used to bring asynchronous font loading in to effect are:

Autoptimize. This plugin can handle font loading asynchronously. It provides options to optimise and load CSS, JavaScript, and fonts in a way that minimises render-blocking resources.
Flying Scripts. Flying Scripts is a plugin focused specifically on async and deferred loading of JavaScript and CSS files. While it doesn’t directly address fonts, it can be useful for managing other assets that might impact font loading.
Asset CleanUp. This plugin does more than allow you to async CSS and Javascript, it can also be used to debloat a lot of the CSS and Javascript present on site pages that isn’t being used. This can also have a positive effect on page load times (see the post about reducing unused Javascript for more about this plugin).

Does this really matter?

After reading the above, you might well be thinking something like “That’s a LOT of effort to go to to make something that’s red in https://pagespeed.web.dev/ not be red any more”. Or “Does this really matter?”.

Don’t worry, you’re not alone.

Here’s the thing though.

92.54% of web searches are carried out using Google. Google ranks your site pages based on various factors. Performance is one of these factors. Ensure web fonts remain visible during webfont load is one of the factors used to establish your site’s performance.

Also, there are about as many websites as there are people on the planet. Yours is one of many. Combine that with the above, and it probably matters. Just a bit, but it matters.

So whilst ensure web fonts remain visible during webfont load is effectively one part of a bigger picture, it can have an influence (or at least a degree of influence) over how your site ranks in Google search results, and therefore being found in amongst the many many websites available on the internet.

The purpose of this blog post is to help you with that one aspect.

That said, there is more to this than just “doing what Google says”, and that’s chiefly user experience. It would probably be more positive to think of things along the lines of “Google highlighting issues experienced by your site visitors” rather than “I’m ticking a box to keep Google happy”.

Addressing the ensure text remains visible during webfont load in practice… using WordPress.

It’s a bit hard to completely say “do this and it will sort this problem out” due to the variable nature of WordPress and the functionality of the various plugins and themes that you might potentially use, and the different ways of calling CSS.

That said, there are some things to try. Note the use of the word “try” there, so take a backup first, just in case.

Let’s start with the most straightforward.

If you’re calling google fonts from fonts.googleapis.com.

If you’re looking in to the ensure text remains visible during webfont load and you see this in https://pagespeed.web.dev/:

This can be quite easily sorted out by installing and configuring a plugin to have google fonts load from a local location (i.e. within your site). This can also sort out things like “render blocking resources” and it also negates the overhead associated with loading an aspect of your site from an external source.

The OMGF plugin can be used to achieve this. I’ve written a post covering how to use the OMGF plugin to make google fonts load locally (this also describes the situation and the benefit you’ll see). This plugin also allows font-display: swap; to be bought in to effect in a few easy clicks.

Globally enforce font-display: swap;

There are a few ways that you could do this.

The “correct” way to do this would be to make a child theme in your WordPress, and then set font-display: swap; in the child theme’s CSS file. I’ve written a full post covering how to create a child theme and then use it to globally enforce font-display: swap; (as it was too much to include within this post). A child theme essentially allows you to make customisations to the theme you’re using, without customising the main (parent) theme itself. Using a child theme means that you can control more theme customisation and that the customisations you’ll make will persist after updates. Do be aware that this only affects fonts called locally, rather than external fonts.

Alternatively, you could…

Add custom CSS to your theme’s customisation options

In your WordPress dashboard, hover over “Appearance” in the menu on the left hand side, then click on “Customise”:

Then scroll to the bottom of the menu on the left hand side, and click on “Additional CSS”:

On the “Addtional CSS” page there’s a field toward the bottom of the menu on the left hand side that can be used to add additional custom CSS:

In the are highlighted above, add this CSS to bring font-display: swap; in to effect:

/* Globally enforce font-display: swap; for all custom fonts */

@font-face {

font-display: swap;

}

Then click “Publish”:

Add Custom CSS Using a Plugin

This does roughly the same thing as the above, but using a plugin instead of the theme customisation options.

You could use a plugin such as Simple Custom CSS and JS and then use that to bring some custom CSS in to effect (the easy way) which I’ll cover below. The other would be to make a child theme (this is a post in itself, you can find WordPress’ own documentation covering child themes here) so I’m not going to cover this here, but I’ll make a post in the future covering making child themes) and then used that to bring some custom CSS in to effect.

The CSS you’d use for either method would be the same.

You’d install the Simple Custom CSS and JS plugin in the normal way (plugins > Add new > Search for simple custom CSS and JS > Install > Activate) and after doing so, a “Custom CSS and JS” option appears in your WordPress menu on the left hand side. Hover over this, then click on “Add Custom CSS”:

You’ll then see some sample/example CSS:

Now, you could replace the brown/gold example text above with this (this is the best option to use if you can, and it achieves the desired effect):

/* Globally enforce font-display: swap; for all custom fonts */

@font-face {

font-display: swap;

}

It’s also worth giving this custom CSS a relevant name (as highlighted below) and to bring the CSS in to effect, click publish:

There are a few reasons why the options above might not work.

Specificity and Cascade: font-display: swap; property should really be applied to individual @font-face rules rather than a global rule. When using a global rule, it might not override the specificity and cascade of existing @font-face rules defined by the theme or plugins that you’re using.
Existing @font-face Rules: Many WordPress themes and plugins define their own @font-face rules to load custom fonts. These rules may have different font-display settings or may not include this property at all. Applying a global rule might not affect these pre-existing rules.
Load Order: CSS rules follow a specific order of application. If a theme or plugin’s CSS file is loaded after the custom CSS with the global @font-face rule, it can override the global rule you’ve added.
Possible Conflicts: Themes or plugins may use different methods to load fonts, such as using a CDN or JavaScript-based solutions. These methods might not be compatible with the font-display property, so you might find that strange things then start happening to your site’s appearance.
It did work, but you haven’t purged cache’s created by caching plugins you’re using.

You may need to define the font being called and the font file itself, using the following (obviously you’d need to replace YourFontName with the name of the font and font-url.woff2 with the URL of the font file being used):

/* Apply font-display: swap; globally for local fonts */
@font-face {
font-family: ‘YourFontName’;
src: local(‘YourFontName’), url(‘font-url.woff2’) format(‘woff2’);
font-display: swap;
}

Manual editing (not recommended).

Operating in this manner isn’t something I’d recommend, chiefly because it’s unlikely to persist after updates (and not applying updates is a very bad idea if you’re using WordPress, as these often include patches to address vulnerabilities that could be used to compromise your site).

You also have to consider that it’s possible that some function in your WordPress effectively made what you’re editing, so if you either make something else, or the same thing gets remade (by you doing something like editing a post or a page) your change could get overwritten.

You also have to find what it is that you need to change, which can be tricky, depending on where it is. The post I wrote about ensure text remains visible during webfont load for Elementor and Fontawesome covers how you’d bring font-display: swap; in to effect by manually editing CSS. When I wrote that, it wasn’t much fun finding the file I needed to edit, what I had to do was:

Disable caching plugins to see font file that didn’t have font-display: swap;
Use shell access to recursively search for files referring to the font file (to know where to put font-display: swap;)
Manually edit the CSS file to bring font-display: swap; in to effect

Whilst it is possible to use a plugin such as the string locator plugin to find what it is you’d need to make a change to at file level, and a facility such as PHPMyAdmin in your hosting account can be used to locate database entries you’d need to update, is it worth the effort if the change you make might be wiped during an update or a page edit?

The changes you’d need to make would be along the lines of:

Adding font-display: swap; to CSS files (see this post for the syntax).
Adding &display=swap to the end of the Google Fonts URL (if you’re calling Google Fonts externally)
Preload web fonts by using <link rel=”preload” as=”font”>

I’m not going to go in to too much detail here, mostly because this isn’t a good idea. The only time I’d even consider using this would be to stop someone nagging me about seeing red things in https://pagespeed.web.dev/ in a situation that I didn’t really care about. And everyone cares about the sites they make don’t they? DON’T THEY?!?!?

Using plugins.

There are some caching plugins that will bring font-display; swap in to effect for you.

WP Rocket. Although this is a paid plugin it applies font-display: swap to local CSS when minify or combine is enabled for CSS in this plugin’s options. It also optimises Google Fonts upon installation.
Optimize More! This plugin can be used to load CSS Asynchronously and delay CSS & JS until User Interaction. Although it doesn’t bring font-display: swap in to effect it provides other options that can be used to do things like preload fonts.
10Web Booster. This plugin adds font-display: swap; by default, but the free version only allows you to optimise 6 pages.
WP FOFT Loader.This plugin uses a method to effectively emulate font-display: optional; which will address the “enure text remains visible during webfont load” issue, but it does involve uploading font files and some configuration (there are videos covering this on the plugin page linked to above.
Numerous plugins are available to make external Google Fonts use font-display: swap but you can make Google fonts load locally bringing font-display: swap in to effect when doing so (which eliminates the overhead associated with DNS lookups, and therefore minimises the amount of 3rd party code being used at the same time).
Elementor has a setting (Elementor > Settings > Advanced > Google Fonts Load) to set font-display: swap for Google Fonts.

In conclusion.

There are various methods that you can use to address “ensure text remains visible during webfont load”.
The methods used generally involve either preloading fonts, or falling back on system fonts while font files load.
Exactly how you’d deploy these methods varies according to what you’re using, and it’s possible they might not work.
Editing files or the database manually to address this issue isn’t advisable as the changes can be overwritten when updates are applied.
The correct way to globally enforce CSS directives when using WordPress is to do so by creating a child theme, and then using it to bring global CSS directives in to effect.