Font best-practices

[igrigorik]

Had an interesting chat with @drott about font best practices. Some notes and ideas we might want to investigate in Lighthouse, in no particular order...

Long font-family lists as an anti-pattern

You should prioritize high-coverage fonts higher in your declarations, as that minimizes the amount of work the browser has to do to find the right glyph -- e.g. each step down the chain requires loading the file, querying for the character, etc. Ideally, your first~second font should provide coverage.

• It would be interesting to know the depth of the chain you have to resolve.
• We should probably warn developers if/where:
  • the fallback chain is deep (>X fallbacks)
  • system fallback is used for content on the page: your font stack does not cover this content, which means they may not render correctly, etc.

Byte efficiency of fetched fonts

It would be really interesting to see an efficiency metric -- e.g. you fetched 100kb of fonts vs how much of that 100kb was actually used? Low byte efficiency can help identify cases where you're using suboptimal subsetting.

Encourage use of language tagging

Scenario: you're in China and you're reading a language in Japanese. The page does not declare the language on the content and browser may default to a system fallback (China locale) that can render wrong kanji character(s).

Specifying language helps the browser select correct fallback font quickly and helps with performance if there are coverage gaps in the font stack.

---

@drott hope that's coherent.. please feel free to jump in and correct where/if needed.

/cc @KenjiBaheux

[drott]

As for language tagging, I put up an example of CJK ideographs looking slightly differently depending on language tagging: http://codepen.io/anon/pen/ENWmJQ

An example what this looks like on Windows, where this probably works best:

/cc @kojiishi

[KenjiBaheux]

How does unicode-range fits in this narrative? Does it help or not?

On Mon, Nov 21, 2016, 11:39 PM Dominik Röttsches notifications@github.com
wrote:

As for language tagging, I put up an example of CJK ideographs looking
slightly differently depending on language tagging:
http://codepen.io/anon/pen/ENWmJQ

An example what this looks like on Windows, where this probably works best:

[image: chrome_cjk_ideographs]
https://cloud.githubusercontent.com/assets/1021784/20486514/bcb64d1c-b008-11e6-8dc6-dca94a7192b0.PNG

/cc @kojiishi https://github.com/kojiishi

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#848 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGD3Cp3qQB1Uz7prmfMdUkcaB_5baiTgks5rAa0OgaJpZM4Kjuex
.

[connorjclark]

Adding some 2020 thoughts. No immediate plans to do this.

Long font-family lists as an anti-pattern

Would be interested to see how this affects performance. I'd think that if they are system fonts it would be no issue. I'd see a really bad case if there are a bunch of webfonts in the chain, and none contain the proper glyph.

subsetting

this is the one I'm most interested in supporting in LH.

CDT tells you how many glyphs are used in a text node from a specific font, but not what those glyphs are. I think we'd need to render a text node stuffed with all the characters on the page and count the number of glyphs used–then we also need a way to inspect a font fact to know how many glyphs it has. That last bit would require Chromium protocol work.

If we are doing some protocol work, maybe we should just do the entire thing in Chromium–somehow wire a font's utilization from the font engine to devtools.

Encourage use of language tagging

I think we do this already via axe.