Elementor and Fontawesome ensure text remains visible during webfont load.
In this post I’ll be talking about why sites made using Elementor and Font Awesome are flagged with the “ensure text remains visible during webfont load” issue by toold such as https://pagespeed.web.dev/ .
I’ll voer what the issue is, why it’s a problem and how you can address the Elementor and Fontawesome ensure text remains visible during webfont load problem.
This is one of many issues you’ll have to address when optimising your WordPress, if you’re using Elementor and Fontawesome.
Elementor and Fontawesome ensure text remains visible during webfont load… what’s the problem?
This has been annoying the life out of me for a while now.
I quite like Elementor. It’s free version is rich enough in features to cover most aspects of page content. It’s easy to use and other people make plugins that integrate with it as well. All good. Fontawesome also provides a lot of fonts, again for free, so Elementor and Fontawesome together are a nice free combination.
What’s not so good is is that there’s ONE aspect of it that negatively affects google’s page speed performance audit, and you loose a few percent on the performance audit, just because there’s a font awesome woff file being called with no font display attribute.
The good news is, I’ve got a fix. It’s not pretty and it’s unlikely to persist after updates, but it does, nonetheless fix the problem.
This is what you’ll see in google’s page speed performance audit it you’re affected by this:
What’s going on?
Font files can be pretty big, and if the text on your site uses a certain font (with a big file) text can be invisible while the font file is loaded.
What the google page speed performance audit is complaining about is a lack of font-display attribute in the CSS file that calls the font. This attribute tells the browser how a font face is displayed based on whether and when it is downloaded and ready to use.
All that’s needed to fix this is this:
What this does is tell the browser to fall back on a system font, while the actual font file is loaded. Text displays, and at worst, it’s in a font other than the one that should be used for a fraction of a second. Boohoo… boohoohooohoo.
Working out where to put it can fry your mind, especially if you’ve got caching plugins enabled (which you probably have if you’re using WordPress), and even with these disabled it’s not completely obvious which CSS file is calling the fontawesom-webfont.woff2 font file (that’s the part being complained about at the top of the screen shot above). All I really knew when I started looking in to this was that Elementor and Fontawesome were causing the “ensure text remains visible during webfont load”.
How to fix the Elementor and Fontawesome ensure text remains visible during webfont load problem.
I fixed this by manually editing a file. Not everyone’s cup of tea, and unlikely to persist after updates, but it does do the trick.
You’ll need to do this via the hosting account that contains your site, or by downloading the file, making the change and then uploading the changed file using FTP.
The file you need to edit is here:
Obviously you’ll need to replaced document_root with the actual document root (the directory in which your site is held). This could be public_html (cPanel), httpdocs (plesk), /var/www/html (vanilla default apache), or something custom if you’re using a multisite hosting account.
Anyway, edit this file (these screen shots are taken from the cPanel file manager), and locate the part I’ve highlighted in the screen shot below:
See the semicolon (;) at the end of the highlighted section? Immediately after that (no spaces), add:
Just like the highlited text in this screen shot:
Check your syntax (spelling) is correct, then save the change.
The purge all the caches of your caching plugins, the browse to your site (to rebuild caches), and ta-daa!:
So there you go, that’s how you fix the Elementor and Fontawesome ensure text remains visible during webfont load problem.
Do be aware that this is highly unlikely to permanently address the issue. If the document_root/wp-content/plugins/elementor/assets/lib/font-awesome/css/font-awesome.min.css file is overwritten by an update you may well need to carry out the same again.
Why don’t I get 100%?
There’s a lot to getting good performance in google’s page speed audit. No one thing covers everything. What I’ve covered here is just one REALLY ANNOYING thing that’s been bugging me (and other people) for a while now.
You can buy me a pint if you’re feeling appreciative!
Why this might not work for you.
If you’re using caching plugins and carry out the above, you’ll need to rebuild the cache to see the fix in effect. This is because the cache that’s being served is from BEFORE you made the change detailed above, so the cached CSS doesn’t contain the font-display:swap you’ve added. How you’d rebuild the cache varies between caching plugins, most have some kind of ‘purge cache’ or ‘clear cache’ option, others you may have to turn off and on (disable cache), some you might even have to deactivate and reactivate.
You’re using Elementor pro
The fix above only applies to the free version of Elementor. I don’t think the pro version does this, so I’d guess Elementor have fixed this in the pro version, or at least provided an option to specify font-display:swap (I could be wrong here).
You’re seeing the “ensure text remains visible during webfont load” for a different reason.
This fix is ONLY for the free version of Elementor and Fontawesome. This fix doesn’t universally apply to the “ensure text remains visible during webfont load” as a whole. You’ll need to work out what’s being called without font-display:swap to fix this if you’re not using the free version of Elementor, then make a similar change.
Working this all out wasn’t pretty, what I did (just in case you need to work out how to fix the same issue for a different CSS file) was:
- Disabled all caching plugins
- Browsed to a page on my site
- Looked at the page source to see the font file being called
- Used shell access to locate the font file causing the issue
- Still using shell access cd’d up a directory level
- Still using shell access carried out a recursive grep for the end of the font file’s name (to see what was calling it)
- Repeated steps 5 and 6 until I found a couple of likely CSS files (I was looking for @font-face with no font-display:swap which I got from the “How to avoid showing invisible text” section of this page).
- Trial and error’d adding font-display:swap to the CSS files I’d found that contained what I was looking for (make a change check the site in https://pagespeed.web.dev/ repeat until there’s no more “ensure text remains visible…” error.
Yes, I’ll agree that’s a bit of a dirty way of doing things, but as I didn’t write any of the code, what else could I do?