GoogleChrome / GoogleChrome/lighthouse
Font best-practices
- Dominant language
- JavaScript
- Stars
- 30.8k
- Forks
- 9.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 19
Description
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](https://www.w3.org/International/questions/qa-html-language-declarations)
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
Contributor guide
Assessment
This issue has not been assessed yet.