Abstract: Loading Web fonts is generally poor for Web performance, and no font loading strategy is particularly effective at solving this problem. In the upcoming font options this property may finally solve the problem of making the alternate font display consistent with the final font.

Font loading has long been a performance issue on the Web, but there is no better option. If you want to use a web font, your choice is basically to hide font flicker (aka FOIT), hide text or unstyled text flicker (FOUT) until the font is downloaded, you initially use the alternate system font and then upgrade it to the downloaded Web font. To be honest, there’s no real difference between the two options, because neither is really satisfying.

Isn’t font-display supposed to fix that?

The font-display property of @font-face gives Web developers a choice in how to render, whereas previously it was up to the browser to decide which rendering method to use (IE and Edge used to support FOUT, while other browsers supported FOIT). Beyond that, it doesn’t really solve the problem.

Many websites tend to set font display: swap, Google Fonts as the default when they first appear, and even in 2019. Perhaps the idea is to display the text as quickly as possible, which seems better for performance, even if it goes with an alternate font and then swaps the font for the final download.

I supported this at the time, but increasingly I found myself frustrated with the “chocolate effect” as web font downloads and characters expanded (or contracted) due to differences between fonts. Smashing Magazine, like most publishers, uses web fonts, and the screen capture below shows the difference between the initial rendering (using alternative system fonts) and the final rendering (using web fonts) :

Now when the two are placed side by side, the Web font is rendered much better, and it does fit the Smashing Magazine brand. But we also see a big difference in the text layout between the two fonts, with very different font sizes. As a result, screen content moves around. In the case of Core Web Vitals and Cumulative Layout (currently quite correct), the use of FONT display: swap is considered to be a bad experience for users.

Because I do find flashing after rendering text to be a very annoying experience, SO far I have set font display: block by default on the sites I develop. While it’s true that the block property doesn’t prevent fonts from flashing (fonts are still rendered as invisible text), it’s at least less noticeable to the user. I also optimized by pre-loading fonts, which I made as small as possible by self-hosting a subset of fonts — so visitors usually only see alternative fonts for a short period of time. For me, since swap’s “block period” is too short, I prefer to wait a little longer for the initialization to render correctly.

Use font-display: optional to resolve FOIT and FOUT– at a cost

Another option is to use font-display: optional. This property basically makes a Web font optional, or in other words, it’s up to the browser never to exchange it if the font isn’t there when the page needs it. With this option, we basically just use fonts that have been downloaded to avoid FOIT and FOUT.

If the Web font is not available after the page loads, we’ll fall back to the alternative font, but navigating to the next page (or reloading this page) will use that font — since it should already be downloaded. However, if a Web font isn’t important to your site, it might be a good idea to remove it completely — it’s even better for Web performance!

First impressions are important, because there seem to be too many websites on the market that don’t load web fonts. I think there’s an implicit impression that certain Settings on a site are “off” by default, and if turned on, it affects certain ways people use it (there’s no evidence for that, by the way).

Therefore, all font choices have their drawbacks, including not using web fonts at all or using system fonts (which are limited — but probably not as limited as many people think!). According to experience, many users of the computer installed font is not very complete, some font versions are not consistent, such as Microsoft yahei, windows8 after a font upgrade, interested can go to compare.

Make your standby font a better match to your web font

The trick to Web font loading is to make the alternative fonts closer to the actual Web font to minimize significant offsets and thus reduce the impact of using swap. While we can never completely avoid these transitions, we can do better than the screenshot above. Monica Dinculescu’s Font Style Matcher application is often cited in Font loading articles, and here is a great example of how it should work. It allows you to overlay the same text with two different fonts to see their differences, and adjust font Settings to align them more closely:

Unfortunately, the problem with font style matching is that we can’t make these CSS styles apply only to fallback fonts, so we need to apply (or restore) these style differences using JavaScript and the Fontface.load API when web fonts load.

The amount of code is not that much, but it still feels like a little more than it should be. Although, as Zach Leatherman explained in his wonderful 2019 talk, There are other advantages and possibilities to using JavaScript apis — but you can reduce backflow and deal with data-server mode and Ana-reduced-motion situations (but note that they’ve all been exposed to CSS since that conversation).

It’s already tricky to deal with the cached fonts we already have, not to mention the differences in fallback styles. At Smashing Magazine, we have tried a number of alternative fonts to take full advantage of system fonts for different users and operating system installations:

font-family: Mija,-apple-system,Arial,BlinkMacSystemFont,roboto slab,droid serif,segoe ui,Ubuntu,Cantarell,Georgia,serif;
Copy the code

Knowing which fonts to use, or making individual adjustments to each font and ensuring they are applied correctly, can quickly become very complicated.

A better solution is coming

So, that’s a brief description of what’s going on. However, there is a lot of smoke.

As I mentioned earlier, the main problem with applying fallback style differences is adding and removing them. What if we could tell the browser that these differences are only for candidate fonts?

This is part of what a new set of font descriptors introduced in the CSS Fonts Module Level 5 does. These apply to @font-face declarations that define a single font.

Simon Hearne wrote about this proposed update to the font descriptor specification, which includes four new descriptors: Ascent – Override, Descent – Override, line-gap-override and advance- Override (since deleted). You can use the F-Mods Playground created by Simon to load your custom and alternative fonts, and then use overrides to get a perfect match.

But once again, things seem to be changing. Advanced-override was recently dropped in favor of the upcoming size-ajust descriptor, which allows us to reduce layout offset by matching the scale factor (percentage) of the glyph to the alternate font and primary Web font.

How does it work? Suppose you have the following CSS:

@font-face {
  font-family: 'Lato';
  src: url('/static/fonts/Lato.woff2') format('woff2');
  font-weight: 400;
}

h1 {
    font-family: Lato, Arial, sans-serif;
}
Copy the code

Then all you need to do is create an @font-face for the Arial alternative font and apply the adjuster descriptor to it. You should then get the following CSS fragment:

@font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } @font-face { font-family: "Lato-fallback"; Size - adjust: 97.38%; ascent-override: 99%; src: local("Arial"); } h1 { font-family: Lato, Lato-fallback, sans-serif; }Copy the code

This means that when you first used Lato-Fallback (since Arial is a native font and can be used directly without any additional downloads), you made it closer to the Lato font by setting size-ajust and advant-Override. This is an extra @font-face statement, but certainly a lot easier than the pit we had to jump through before!

Overall, @font-face contains four main descriptors in the specification: size-adjust, ascent- Override, Descent – Override, and line-gap-Override, with some still under consideration for subscript, superscript, and other use cases.

Malte Ubl has created a very useful tool that automatically calculates these Settings given two fonts and a browser that supports these new Settings (more on that later!). . As Malte points out, computers are good at this sort of thing! Ideally, we could also expose the Settings for commonly used fonts to Web developers, such as in a font collection like Google Font? This will certainly help increase adoption rates.

Now, different operating systems may have slightly different font Settings, and getting them all to look exactly right is an almost impossible task, but it’s not the goal. The goal is to close the gap, so using font-display: swap is no longer an unpleasant experience, but we don’t need to go for optional or no-web fonts extremes.

When can we start using it?

Three of these Settings have been available in Chrome since version 87, although the size-ajust descriptor is not yet available in any stable browser. However, Chrome Canary (Chrome92 +) already supports it, as does Firefox, so this isn’t some abstract, distant concept, but something that will soon hit the ground running.

Currently, the specification has all sorts of disclaimers and caveats indicating that it is not ready for immediate use, but it does feel like it has arrived. As always, our designers and developers have a balance between testing it and providing feedback and discouraging its use, so that the actual application situation is not bogged down by too many people ending up using the early draft.

Chrome has indicated that they intend to provide the size-ajust attribute in Chrome 92, which will be released on July 20th, which may indicate that it is almost ready to use.

So, it’s not quite ready yet, but it looks like it will be in the near future. In the meantime, try out the demo in Chrome Canary to see if it can get any closer to solving your font loading problems and their CLS impact.

If there is any mistake in translation, please contact us for revision

The original address: www.smashingmagazine.com/2021/05/red…

Reference content:

The deploy – preview – 15 – upbeat-shirley-608546.net lify. App/perfect – ish…

The deploy – preview – 15 – upbeat-shirley-608546.net lify. App/posts/high -…