Add Swap to font-display for FontAwesome in theme.css

[danielmrey]

Hi:

Could you add to theme.css file the rule: font-display: swap for the FontAwesome font:

theme.css (Line: 10738)

@font-face { font-family: 'FontAwesome'; font-display: swap;

The font-display descriptor determines how a font face is displayed based on whether and when it is downloaded and ready to use. The value swap, gives the font face an extremely small block period and an infinite swap period.

Thank you.

Daniel.

[bacoords]

I think this is feasible (assuming it passes testing). We'll put it on the roadmap to test.

[danemorgan]

Using swap makes sense for me on the body copy and on the headline and other text-based fonts where providing the user with readable copy as soon as possible is desirable. Still, I'm not sure I understand the point of using it for Font Awesome and showing □ characters where the icons will go?

Font Awesome seems like it's one of the rare cases where font-display: block actually makes sense. That way, if the font never loads, it never displays "broken" icons. I'm open to learning where I've gone wrong on this, though.

As a side note, are we using swap for our body copy and headlines at least? We would check on that and make sure we are.

[pattonwebz]

Using swap prevents escalating CLS scores mainly as well as making initial load and render times quicker on slow connections.

[bacoords]

This is one of those cases where pagespeed insights leads to design patterns that aren't actually ideal in the real world. @danemorgan makes a good point that swap looks funky for icons. But @pattonwebz is also correct that it is typically considered a page speed win for the algorithm (and thus SEO) and for getting your site loaded faster.

I suggest we should defer to whatever the default FA behavior is, but open to other ideas.
It looks like they explicitly went with block intentionally, but not sure how up-to-date this is: FortAwesome/Font-Awesome#14387

[pattonwebz]

It isn't just a page speed win - it is mostly a user experience win. Improved user experience is absolutely the correct decision in the real world.

We should measure if changing the display mode in any way shifts CLS scores in the wrong direction. Particularly when it is common for people to have these icons appear above the fold.

[danemorgan]

For an icon font, though, wouldn't a more appropriate approach be to block the font-display and reserve the space needed for elements with height and width settings? That would prevent CLS accumulation and not display "broken" icons.

as I understand it, font-display block isn't going to block the loading of the page, it's only going to block the display of an unloaded font.

Another approach — is there a system font that makes sense as part of the font-stack for swapping with an icon font?

[pattonwebz]

Sure, it is always best to set an inline width and height for visual items that affect layout but it isn't all that common outside of images. Most people rely on the font size when they use a font icon.

FWIW I have no strong feelings for swap or block beyond that which has the best user experience. We don't know which is best without testing but I would imagine swap is the better option because it requires the least amount of documentation and the least amount of rework.

In my mind showing something is better than showing nothing. Silent or invisible failures are great for unseen items but not good for anything that should be seen. As a user, I am happy to see a different glyph momentarily if it prevents a large layout shift when it loads at a later point.

[danemorgan]

I'm not sure I agree that something is always better than nothing. I mean, in most cases, yes, but I believe there are cases where nothing is better than something that looks broken.

Consider these 'broken' clock Font Awesome icons vs their simply not being there.

To my eye, the first looks broken, and the second looks like something I wouldn't even notice as something being missing.

Now as I write this I do think of one case where my position may fall apart, and that is when the icon is linked.

If that blocked icon were a link it would be invisible, but I'm still not certain that is worse than the broken version which would give no indication of what the link is for. I personally ignore blind links as they have more potential for misadventure than not and probably wouldn't click on that glyph.

[danemorgan]

The ultimate resolution Font Awesome went with was block.

FortAwesome/wordpress-fontawesome#110

[pattonwebz]

I didn't clarify but I did always mean something is better than nothing when it comes to an interactive element or key piece of functionality.

When something is entirely presentational then it only matters to a designer and not to a developer ;)

Of course, FA will go with 'block' as their display mode. It is in their best interests for people to know they are on the page. That doesn't mean it's the best for user experience.

We can test that quite easily if we really are basing the decision on actual insights rather than just what we feel. I feel swap is the best option but that may not be the case and till someone tests it directly we don't really know :)

[bacoords]

Hitting this discussion again for the next release. A few thoughts:

• For the Bootstrap 5 version, how about switching away from Font Awesome completely and moving to Bootstrap Icons? The BS4 version of the theme would still load Font Awesome for legacy purposes, but future sites wouldn't load FontAwesome, since we're on an older version anyway.
• Personally I'm against changing the default behavior of a third party library at all. It might null out the purpose of having a 'copy-assets' script and mean we're keeping a separate version. If we did this (instead of using BS Icons), I think we should update to v5 where they have a SCSS variable for it, and would be able to override it correctly. But that's a separate issue.
• Another alternative: putting instructions in the documentation for users?

[0dp]

I'm all for removing the dependency completely and have how to's for both in the documentation