replace webfont.js with simple font stylesheet

[silverwind]

Another attempt at #108. I don't think we really need webfont.js right now and a simple stylesheet from Google Fonts allows for native browser caching. So far, the only font flash I noticed is on initial uncached load, which I think is unavoidable.

[fhemberger]

Font flash can take quite long on mobile (even over wifi), that's the reason I used the webfont loader. It has an impact on performance.

[silverwind]

Hmm, the woff2 font files are just 11Kb for each weight, while that script alone is almost that size before gzip. Maybe another option would be to use a font stack with just locally available fonts to avoid webfonts altogether.

[fhemberger]

I'm using the same font on my own website, this is my fallback font stack:
Source Sans Pro,Open Sans,Roboto,Helvetica,Arial,sans-serif;

[silverwind]

Some nice fonts, but Open Sans and Roboto can probably be removed there, as it's highly unlikely the user has them installed locally.

What were you trying to achieve with webfont.js? The rendering of the fallback font before the webfont download had finished? (Only webkit browsers hide webfont-text before they are downloaded afaik)

[fhemberger]

Roboto is a default font on Android devices.

webfont.js removes the FOIT (Flash of Invisible Text) on both Android and iOS

[phillipj]

Dare I ask whether or not we need a webfont at all? Getting this perfect in regards to FOIT and FOUC seems doable with several nifty tricks, but is it really worth it? KISS by having a font which doesnt suffer from these FO**, glitches and no performance impact sounds tempting..

[silverwind]

Agree with @phillipj, Some Helvetica/Arial font stack ought to be good enough and it avoids all the mentioned issues.

[silverwind]

Been taking a look at font stacks using only local fonts and came to the conclusion that you are pretty much left to only Arial and Helvetica, so not sure it's really an option if we want to retain a hip font.

@fhemberger Care to re-evaluate the perf on this change? It's a huge improvement in how solid the site feels on desktop, and perf can't be that bad on mobile I assume. I wonder if our mobile traffic volume really urges us to favor mobile over desktop.

[mikeal]

We good to merge this?

[fhemberger]

I'd like to keep the webfont loader instead of going directly for the CSS. You get almost entirely rid of the Flash of Invisible Text, which can be a huge blocker on mobile (up to several seconds on slow connections). This way you can read the entire website even if the webfont loader is still working in the background. And once all fonts have finished loading, the updated style gets applied, which is really fast.

Helvetica itself is not optimized for screen, but it's a default font on OSX. The new San Francisco should be added to the font stack as well. And I'm pretty happy that the times of websites being only available in Arial, Verdana or sans-serif are over.

[silverwind]

Well, then you should investiage why font caching is broken and the webfont is requested on every page load. #139 and #69 don't seem like the right approach to me. I have no experience with webfont.js, but I'm pretty sure it's not used correctly.

[fhemberger]

I can't find anything online about caching in webfont.js. This script is used in the same way by Google, TypeKit, etc. and the webfonts there don't use browser caching as well.

[silverwind]

The only issue I see with the current usage is that you're using a a local instead of a global variable for WebFontConfig, but changing that apparently does nothing for the issue.

Also, caching does work from the looks of it. The issue seems to be caused by script evaluation delay and another delay when the script decides to fetch the font, which while cached still takes a moment.

I still think we should remove that script. These fonts are just 11kB transfers per weight, while the script adds around 7kB gzipped.

[phillipj]

This script is used in the same way by Google, TypeKit, etc ..

You know which websites they are using it on by any chance? The Google sites I've seen with fancy fonts are usually ones that initially render a blank page / progress bar, than suddenly pops in after a while - not at all what we're doing in other words.

Didnt dig too deep into typekit.com, but there's no doubt it suffers from bad FOIT.

@silverwind has some good points here, script evaluation and in practice side stepping the browser's cache isnt good. This reminds me why I'm not a fan of traditional single page apps, but that's a whole other story..

[fhemberger]

@phillipj Loading the webfont CSS in the header blocks the rendering of the entire page until the CSS is loaded/parsed. To avoid this, you have to use workarounds like loadCSS.

Some recent articles on the topic:
https://viget.com/extend/the-font-face-dilemma
https://www.filamentgroup.com/lab/font-events.html
https://helloanselm.com/2015/using-webfonts-in-2015/

[phillipj]

@fhemberger yepp, sure know about the impacts <script> and <link> has on page rendering.

Since you mentioned google and typekit, I was trying to find any website from any of those two, which uses webfonts and has all the quirks to make this work, while not being a single page app with a loading screen.

[silverwind]

I'd still like to land this, by the way. The flash of the default font on every page load is just too annoying. Compared to the current Webfont approach, we'd load 14kB more font data in a blocking manner, but its a one-time cost and chances are good that the user has the font already in cache.

[evanlucas]

+1 to fixing the jumping....drives me insane

[phillipj]

The flash of the default font on every page load is just too annoying.

Agreed.

TBH I'm not sure a custom font provides a site like nodejs.org much value. Its main purpose are providing Node.js to the people and relevant documentation/resources. I'm convinced our visitors would have been just as happy with a regular font. But that's subject to another PR I guess.

[silverwind]

Landed in aa4b373. I hope I'm not stepping on any toes here, but the general consensus seemed to be in favor of this change.