New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay loading of fonts #3

Closed
ndarville opened this Issue Nov 20, 2015 · 23 comments

Comments

Projects
None yet
1 participant
@ndarville
Copy link
Owner

ndarville commented Nov 20, 2015

Might consider abandoning it altogether.

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

screen shot 2015-11-20 at 11 11 37

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

@ndarville

This comment has been minimized.

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 20, 2015

screen shot 2015-11-20 at 12 39 06

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 ndarville closed this Nov 20, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 20, 2015

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

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

screen shot 2015-11-23 at 09 52 49

@ndarville ndarville reopened this Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

Just the two:

filmstrip 1
filmstrip 2

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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 comment has been minimized.

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

  • Revert initial revert and document the changes
  • Afterwards, fix the intermittent FOIT
@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

Uhhh:

Before reverting:

filmstrip-2
waterfall php-3

No intermittent FOIT.

ndarville added a commit that referenced this issue Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

  • Fix FOIT
@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

Implemented checks for all three fonts.

ndarville added a commit that referenced this issue Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

@ndarville

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 23, 2015

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

screen shot 2015-11-23 at 20 56 41

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

Compare to previously:

screen shot 2015-11-20 at 12 39 06

(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

This comment has been minimized.

Copy link
Owner

ndarville commented Nov 30, 2015

Closing for now.

@ndarville ndarville closed this Nov 30, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment