- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Jan 2020 20:37:51 +0000
- To: public-css-archive@w3.org
Okay, just wrapped up a meeting with @chrishtr and @xiaochengh to discuss the minutiae of our implementation. I'll summarize here, with our preferred conclusion, and other browsers can chime in if there's a disconnect with their own impls. * When you're processing styling and realize a font is needed, we kick off a load. If the font is in memory cache (generally per-tab), this load is synchronous, and takes <1ms. Otherwise (if it's in disk cache, or not cached at all) the load is asynchronous, and we proceed without the font for this frame. (Next frame it might get picked up, assuming it loaded fast enough; disk cache should generally return before a second frame is started.) * Memory cache is pretty ephemeral; usually it'll stick around as long as a tab is alive, but it can evict at any time (so subsequent same-origin navigations *might* have it available, or might not). If you close and re-open the site, it'll usually, but not always, be evicted. * This means that, if we don't delay the render process, much of the time an `optional` font will be skipped, *especially* on the first navigation to a page. This matches up with what I intend the value for; the way I use it on my blog, for example (as a pure aesthetic upgrade to heading and code font), it's perfectly okay for it to often get skipped and render with the system fonts. But some use-cases, reasonably, would like a slightly greater assurance that the font will be used. It seems to us that a reasonable signal is whether the font is preloaded - that's a pretty strong signal that the font is expected to be used and important enough to start loading early. So our plan is: * make sure that font preloads cause the font to be put in the tab's memory cache * track which fonts are being preloaded this way. During the "load font" check, if the font's not currently in memory cache, check if it's on the list of preloaded fonts. If so, do a blocking load for a small amount of time (20-30ms, maybe?) to give it time to finish loading into memory. Keep a bit around to track whether this happened, so it can't reoccur serially due to multiple fonts needing loading; it only delays once, and if additional preloaded fonts aren't ready yet, too bad. * otherwise act like `optional` normally does This means that if you preload your `optional` font, there's a very high chance that it'll be used as long as it's been cached appropriately (or it's served off of a fast SW, or even network-loaded from an extremely fast network); the only time it'll likely be skipped is on first visit when it has to be network-loaded. ---- In terms of spec changes, I think I can get away with just adding a SHOULD about preloaded fonts, probably phrased more vaguely as "fonts for which the page has signaled ahead of time are likely be used", keying the "delay the first paint of the page" off of that. How does this sound to people? Do other browsers have loading architectures that differ significantly from what I described, and would require different handling? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4108#issuecomment-574362519 using your GitHub account
Received on Tuesday, 14 January 2020 20:37:53 UTC