Re: [css-fonts] Proposal for 'font-rendering' property

On Wed, Apr 8, 2015 at 1:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> No, preloading doesn't help. Or rather, it can help, but it's solving
> something different.  Getting necessary fonts loaded faster is always
> good, of course, but even if you trigger the font download in the very
> first network packet of the response (which can potentially be done
> today, with appropriate arrangement of styles/content), you still have
> to deal with potentially seeing no text until 3s in, during which the
> entire rest of the page could have already loaded.  So a "block or
> not" control is still very useful even in a world with font
> preloading.  And it's useful for things that *aren't* known ahead of
> time and can't be preloaded - you can still want those things to
> display immediately with a fallback font rather than have invisible
> text.  Font preloading really is a completely separate issue that
> doesn't impinge on this proposal.

Here's some hard data supporting "preloading isn't enough", compiled
by Ilya Grigorik:
https://docs.google.com/document/d/1HDCTgd1xu9VkjreQDNyIWzJpMjb4GzuJ0zsy4XtHovs/edit

I think this might only be accessible to @google.com addresses.  If
so, I'll bug Ilya to loosen it up. The gist is that our analytics
shows that ~30% of page loads show at least some "blank text" *in the
viewport* (that is, text that actually matters, that impacts the
user's experience).

Plus, given a conservative estimate of a 650ms budget from
first-byte-received to page-is-ready-to-display-something (based on
actual analysis), even a small font (10kb) will often take longer than
the budget to download.  This means that even if we started the font
download upon receiving the first byte of the response, we'll still
often get blank text for some period of time.

~TJ

Received on Thursday, 9 April 2015 23:17:46 UTC