Skip to content
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.

Force web fonts into progressive enhancements for users on slow connections #4

Closed
KenjiBaheux opened this issue Jan 18, 2016 · 3 comments

Comments

@KenjiBaheux
Copy link
Collaborator

For users on slow connections (e.g. 2G or flaky connectivity), it is a frustrating experience to see a website apparently loaded but with no content to read because of missing web fonts.

From metrics sent by Chrome opt-in users, the blink team has observed that 40% of web font requests actually outlived the 3s timeout. If the browser knew in advance that there is no point waiting after a web font request that is unlikely to complete before the timeout kicks in, it may as well start with a fallback font and down prioritize the web font request to improve the loading user experience.

Developers who seek specific loading experiences are encouraged to take advantage of the Font Loading API and/or experiment with and share their feedback about the CSS font-display API.

Note: given that the loading behavior of web fonts differ among browsers (annex), the nature or the relevancy of this intervention may vary.

Annex
Browsers like Firefox, Safari, Opera or Chrome are waiting after the required web font in order to display an associated text element. On the other hand, Internet Explorer and Edge start by rendering the text with a readily available fallback font which is then swapped whenever the web font is downloaded. See the following table for more details:

Browser Timeout Fallback Swap
Firefox 3 seconds yes yes
Opera 3 seconds yes yes
Chrome 35+ 3 seconds yes yes
Safari no timeout n/a n/a
Internet Explorer 0 seconds yes yes
Edge 0 seconds yes yes
@KenjiBaheux
Copy link
Collaborator Author

Shipping in Chrome 50 for users on 2G connections: fallback if not readily available, swap as soon as the web font is available.

@KenjiBaheux
Copy link
Collaborator Author

KenjiBaheux commented Apr 22, 2016

Follow-up: refine the triggering signal. Chrome is hoping to use a network quality estimator instead of a hard coded rule on the connection type (crbug.com/578029).

@johannhof
Copy link
Member

(As noted in #72, we intend to archive this repository and are thus triaging and resolving all open issues)

From a standards perspective this kind of alternating behavior seems explicitly allowed for the auto font-display setting, so I think this can be closed. I'm not sure to what extent this progressed in other browsers but it still seems like a useful thing to experiment on.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants