Hacker News Reader

Comment by paulirish | Hacker News Reader

> It is very frustrating when loading up a website and seeing a mostly blank page because the fonts are still downloading.

Soon to be fixed! Blink (Chrome, Chrome on Android, Android 4.4+ WebView, Opera) will be implementing new behavior for how webfonts are loaded: http://crbug.com/235303#c17 Basically, you'll only see invisible text for a maximum of 3 seconds (this is the same as Firefox). As Ilya's post also points out, we have strong data on webfont latencies in the wild that supports this behavior.

Further, we're shipping it with Font Load Events so you can customize loading behavior very easily. On the Safari side of things, I've seen WebKit add a radar tracking ticket for font loading behavior, so it seems likely Safari will be updating their style soon as well.

View on HN

> you'll only see invisible text for a maximum of 3 seconds

"Even a few seconds' delay is enough to create an unpleasant user experience. Users are no longer in control, and they're consciously annoyed by having to wait for the computer. Thus, with repeated short delays, users will give up unless they're extremely committed to completing the task. The result? You can easily lose half your sales (to those less-committed customers) simply because your site is a few seconds too slow for each page."[1]

[1] http://www.nngroup.com/articles/website-response-times/

This delay is not repeated, though.

Showing nothing for 3 seconds beats just using the fallback and switching when the download finishes?

It's great you collected data, but I think the working hypothesis is flawed.

I would rather not have the fallback font as the font changing suddenly is jarring. It also can muck up spacing to quite a high degree. If for example you were at an anchor quite a distance down the page and then the entire page shifts.

I added a Feedback drawer to the top of my site. Javascript would determine the height of the drawer then set the top position equal to the inverse of it's height. That way the drawer was completely hidden.

However when a font was loaded the height of the drawer changes and then you've got it sticking down over of the top of the page.

These kinds of things are really frustrating. I'd like to see the page not display until the fonts are loaded and I'd like to see Chrome start shipping with some of the more common web fonts included.

In some instances, showing nothing for a few seconds can be preferable. Some fonts are very different in size and that web font could flow a lot differently than what the fallback is. If you start reading and the font changes halfway through the sentence, it can be very jarring and slow you down as you try to find your place again.

A lot of the problem is poorly implemented web fonts that are not optimized, or web designers going crazy and including 6-8 different font/weight combinations. Having half a meg of web fonts download is no different than using way too many images that are not compressed enough.

3 seconds is an eternity when it comes to responsiveness. Better than nothing, sure, but we're a long way from an ideal scenario.

3 seconds is already way too long.

I see weirder Web-font-related behaviors on both Android and Ubuntu. Specifically, either 1) spacing is very wrong, maybe as if the text was laid out with metrics from the Web font but actually rendered with glyphs from a fallback font (ex: http://imgur.com/KovolXb, from https://news.ycombinator.com/item?id=6954882 -- the page should be in a webfont (Computer Modern Roman), but it's in some generic sans with bad layout), 2) very rarely, I see text that should appear in a Web font replaced with total gibberish (random characters overlapping each other, weird spaces) until I select text or do something else forcing a repaint. I last remember the latter effect in the title text of Slate articles (viewed on Android) that shows in a position:fixed bar after one scrolls down; think I've also seen it in titles on The Verge (viewed on Ubuntu). In both cases, the title text is in a different font from most of the rest of the page.

I'm glad there's performance progress, nothing but high praise for Chrome overall. Just weird things to see.

in our industry we have a graph from .0000 seconds to 3 seconds and 3 seconds is in RED.

Why 3 seconds... who made that choice

We instrumented Chrome and measured the download times: approximately ~1.1% of font loads are longer than 3s. New timeout will help address that 1.1% by using a system fallback.

http://www.igvita.com/2014/01/31/optimizing-web-font-renderi...

How does this impact fonts used as icons? Solutions like icon moon and font awesome?

As far as the browser is concerned, there is no distinction between icon fonts or any other fonts. If your icon font fails to load within 3s then it'll go ahead and try to paint the page with a fallback -- the results of that will vary based on how your icon font is setup / what glyphs it maps to.

If you want to define own load behavior: use the upcoming Font Load Events API.

I'm under the impression, chrome doesn't download webfonts in any hidden tab.

Please experiment this!

Also please test if Chrome saves fonts in the cache. (And also test for non-active tabs!)

You might have lost commits, when the chrome team introduced the Tab-Music-Indicator.

Reply on news.ycombinator.com