Delay loading of fonts

[ndarville]

Might consider abandoning it altogether.

Right now, font loading takes up more than two thirds of the page size—(80%):

That’s ridiculous. Find a proper fallback for skeleton.css projects.

[ndarville]

Via http://keithclark.co.uk/articles/loading-css-without-blocking-render/.

[ndarville]

This thwarts the font blocking the remaining loading and rendering with a significant boost to DOMContentLoaded. Looks like it also shaved off 7 kB somehow.

[ndarville]

Shortcomings:

• This method does not work in Android < 4.4 because the onload handler does not fire when content is available - I’m looking into a work around for this.
• Some browsers appear to still block CSS render despite media=“none”. This means CSS loads as it usually would — I’m looking into this.

http://keithclark.co.uk/articles/loading-css-without-blocking-render/

Android < 4.4 is 36.3% of all Android devices cf. http://developer.android.com/about/dashboards/index.html.

• [ ] Will have to explore how this affects Android < 4.4.

Worst-case scenario, the website renders without downloading the font (a nifty way to enforce a performance gain).

[ndarville]

FOUT—when you throttle the connection to slow things down:

[ndarville]

It’s tempting to add the font-family CSS farther down the DOM, but the problem is that it creates a race condition—which is always going to lose due to the size of the fonts.

[ndarville]

On a 3G connection—current:

---

[ndarville]

On a 3G connection—current:

---

[ndarville]

Just the two:

[ndarville]

So that wasn’t an improvement—in fact, it was the opposite. Could be it’s a Chrome thing, and not Safari which I tested on?

[ndarville]

This article describes the delayed FOIT problem with delayed font loading.

[ndarville]

• [x] Revert initial revert and document the changes
• [x] Afterwards, fix the intermittent FOIT

[ndarville]

From what I understand:

1. Delay loading of font
   • DOM loads faster due to removal of blocking fonts
2. FOIT occurs after DOM is finished loading, because the DOM is repainted with new font

At first we wondered if the blink was just an artifact of repainting/reflowing a moderately complex layout. But the characteristic hidden text alongside visible graphic elements sure looked like your run-of-the-mill FOIT, and sure enough, it was. In short, a FOIT happens when a browser attempts to style an HTML element with a font-family that is defined (via a @font-face declaration) but not yet loaded. Interestingly enough, in this case it appeared that although the CSS and its included fonts had indeed already been delivered over the network to the browser, the browser still seemed to hide the text while parsing the data URI string, which we know can take a little time, particularly on slower devices.

[ndarville]

Uhhh:

Before reverting:

No intermittent FOIT.

[ndarville]

After reverting:

[ndarville]

Renders 300ms faster—but the FOIT lasts 700ms. Let’s hope this tweak fixes it.

[ndarville]

After delaying re-painting using fontfaceobserver (based on this fontfaceobserver article).

[ndarville]

There’s a flash of FOUT now instead. Could create an option to allow people to choose which they prefer.

[ndarville]

After:

[ndarville]

Loads 100ms faster but has 500ms of FOIT. That shouldn’t be the case.

• [x] Fix FOIT

[ndarville]

Implemented checks for all three fonts.

[ndarville]

This fixes the FOIT; after implementing checks for all three fonts:

[ndarville]

For some reason, the loading of fonts.css is not deferred according to this waterfall:

(The blue line representing the DOM loading is on the left side of fonts.css.)

Compare to previously:

(The blue line is on the right side.)

OTOH, it looks like the DOM loading indicator is kinda wrong, seeing that nothing loaded beyond the DOM on the second timeline?

[ndarville]

Closing for now.