You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.
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
The text was updated successfully, but these errors were encountered:
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).
(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.
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:
The text was updated successfully, but these errors were encountered: