Ensure text remains visible during webfont load

[crock]

The confirmed fix is to add display: swap; to each of the @font-face rules.

[au5ton]

@crock @3x I submitted a PR involving this issue.

[mfilenko]

Hey @crock,

Thanks a lot for spotting that!

Do you think swap is the only way to fix this problem or fallback can be a reasonable middle ground here?

As Guillermo Garron wrote (emphasis is mine):

I think the best ones are swap or fallback, swap is the best in render times, but the website flashes and visitors may find that annoying, on the other side, fallback has a small blocking time, but if the font takes to much time in loading, then the browser will not use it at all, and your website will endup using the system fonts.

I can imagine it's a tough choice: even though both options contribute to a better user experience, they do it differently (no invisible text vs no blinking text).

My suggestion with fallback is coming from an idea that 100 ms delay is something a human eye can tolerate :)

What do you guys think?

[au5ton]

I haven't heard of fallback before but thank you for sharing more information about it!

Regarding its use in this repository, I'm not sure which method is objectively better. Its use of one vs the other seems situational. Personally, I prefer swap because I want to minimize render time. To me, when it comes to a repository that is dedicated to using webfonts it seems like swap is a good fit because (eventually) the intended font will swap.

Here are some additional resources on the font-display property:

• https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display
• https://developers.google.com/web/updates/2016/02/font-display#fallback

[3x]

I've merged #7, which adds swap to all fonts. This seems to be the best decision at the moment, per @au5ton's information, but I'm still open to changing this if it gives a better UX.

[mfilenko]

@crock,

Would it be possible for you to re-run the diagnostics you did above, but this time with font-display: fallback to see if that warning still persists?

[au5ton]

@mfilenko the diagnostic used above is: https://web.dev/measure/

[mfilenko]

Thanks! Checking...

[mfilenko]

Hey guys,

I'm very sorry it took me that long to get back to you on this one!

Both swap and fallback options pass Lighthouse's audit, so I'd say it's up to @3x to choose a way to go :)

Even though I personally share Garron's approach to "use swap for icons, and fallback for the rest of web fonts", I'll be totally fine with either value. xz/fonts should be fast enough for this difference to be unnoticeable anyways ;)

I made this animation to illustrate how both options work:

As you can see a header uses swap which makes it 'flash'. The other two subheadings use fallback and they are being invisible for a short period of time (I simulated very slow connection for this demonstration).

While researching this issue I also noticed that Google Fonts CSS API uses display parameter to specify this property explicitly. I guess, if it becomes a deal breaker down the road we can just generate and serve different CSS files with different font-display values 🤔

For the time being I'm totally fine with closing this issue again 😅

Thank you for being patient and open to discussions!

Cheers,
Max