I got tired of using font CDNs, didn't like extra round trips for the woff files, and I also really liked open-sans, so I made an OpenSans.css which inlines all the OpenSans fonts.

It makes my life a little more convenient. https://github.com/steakejjs/OpenSans-CSS/blob/master/OpenSa...

How did you do this?

It's surprisingly not difficult.

I got the woff files, base64'd them, and then threw the output into several CSS files.

Words of warning, If you use Content Security policy, you must allow Unsafe Inline for the style-src directive.

One thing you might want to consider is just using the same family for each of those versions of the font, rather than using the same name as the font file, per this article: http://www.metaltoad.com/blog/how-use-font-face-avoid-faux-i...

Also, I hooked up support for data: URLs so you can use your stylesheet as a source for fonts (if someone was interested in extracting the .woff files back to individual files, for instance):

  webfont-dl -d "https://github.com/steakejjs/OpenSans-CSS/raw/master/OpenSans.css" \
    -o css/font.css --font-out=font --css-rel=../font --woff=link

I've been fighting the flash of invisible content problem while using Google's web fonts on Safari, so I bit the bullet and built a command-line tool that would both 1) host them locally and 2) inline the woff version that's supported by most modern browsers as a data: URL.

You can install this via:

    npm install -g webfont-dl

And download a set of fonts like so:

    webfont-dl "http://fonts.googleapis.com/css?family=Crimson+Text:400,400italic|Raleway:500" \
      -o css/font.css

Is it really so that inline fonts avoids the flash? I have not read this anywhere until now. Source?

It avoids the flash by effectively blocking load. It's not documented, but you can infer it:

  - CSS blocks rendering until download [1]
  - Inlining a font in CSS makes it part of the CSS
  - Fonts inlined in CSS block rendering until download

You can get a similar effect by using a webfont loader and hiding the body until the font loads. The utility uses a strong name for downloading font resources, so if you want to go down this road and use a long expiry for the font resources that'll work as well.

[1] https://developers.google.com/web/fundamentals/performance/c...

I was aware of the technique of hiding the body, but that for me is unacceptable. It causes further delays to get content on the page. This inlining of the fonts is quite interesting.

It'd be nice to have a way of clients caching webfonts. Fonts could have a signature (checksum) and loaded from the user cache.

I'm curious. If visitors visit a site using a font served by Google fonts and visit another using the same font, will it use the cache from the browser?

because if yes, then i rather let the font served by Google fonts.

The fonts themselves are cached for a "long time", but the CSS that links the font to a @font-face declaration expires far more frequently (ie: less than a day).

In my testing on slow connections, serving fonts from Google's site generally results in missing text on iOS devices and Safari if the cache is cold.

By inlining a woff font in the stylesheet you take a bigger hit on the first request to your site (~110kB for my site with three web fonts), but you never see the missing text. Because I'm inlining this in my CSS, I can ensure that it's strongly cached for return visitors and they pay this only once.

It's all a tradeoff that you have to judge for yourself: "What are the chances that a given user has a specific font that you've decided to use cached?" vs "What experience do you want the user to have on a cold cache".

given that most browsers already support woff, i may go with your approach :).

Does anyone know what implications this has on licensing of the fonts? I assume there's a restricted redistribution clause for some of the fonts

Each font is individually licensed. The two I use in my example are under the SIL open font license, for example:

https://www.google.com/fonts#ReviewPlace:refine