https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/5

• Interesting article analysis on web font performance: https://www.keycdn.com/blog/web-font-performance/

• Another good resource on web font optimization: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization

Some notes of mine from the January 19 meeting with @Pginer-WMF, @Volker_E, @JGirault, @Jdrewniak, @Jdlrobson

Drawbacks:

• (Timo) We can't subset fonts because of our content is highly localised. This leads to our fonts likely being 10x larger than the typical size of web fonts recommended by industry leaders like Google.
• (Timo) Our current critical path only consists of 1 main stylesheet. As soon as that is arrived (or cached) content will progressively render as the browser continues to download the page HTML content. All JS and images are loaded asynchronously and don't block rendering or layout. (Image dimensions are reserved). Adding web fonts may add a significant delay to critical path rendering.

Compromises:

• (Pau) Targeting secondary page views only seems reasonable given most users visit Wikipedia multiple times. The first (uncached) page view would have a tight timeout on font load (e.g. 0ms or 50ms), and would populate the cache for subsequent page views.
• (Volker): First invisible instead of swap (fallback->web font) is preferable (less distracting) during the timeout.

Potential trial grounds for web fonts before considering MediaWiki pages:

• Portal (https://www.wikipedia.org/)
• Annual report (https://15.wikipedia.org/)
• Policy site (https://policy.wikimedia.org/)
• Transparency report (https://transparency.wikimedia.org/)

Alternatives:

• (Timo/Pau) Various sites have moved their font policy from "identity consistent" concerns to "legibility-driven" approaches. The rising of new native fonts on various platforms has also motivated this effort. Aside from various good fonts available on most platforms by default, there's also various articles on how to specifically use the operating system's default font (e.g. "San Francisco" on iOS and macOS, "Roboto" on Android, etc.). This also makes web pages feel more like native apps on mobile, which have the same behaviour. Note that this is different from the "browser default" font, which is typically something like Arial for sans-serif.
  • Facebook: -apple-system, BlinkMacSystemFont, '.SFNSText-Regular', sans-serif;
  • GitHub: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; - (Hacker News, Designer News)
  • Medium: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,Cantarell,"Open Sans","Helvetica Neue",sans-serif; - "body default and UI-only, still a webfont for main content area" (Medium.com article, Smashing Magazine article)
• (Timo) However, for standalone sites such as the Annual Report and Policy site, a consistent identity with offline publications can still be beneficial (they already use different fonts compared to our wiki content). And can be done with fairly good performance given that the content is tightly controlled (font subsetting, single variation, invisible first, short timeout, etc.).

@Volker_E + @Krinkle FYI https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/5 rebased and updated per comments