
Show HN: Download and inline Google web fonts from the command-line - mmastrac
https://github.com/mmastrac/webfont-dl
======
steakejjs
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...](https://github.com/steakejjs/OpenSans-
CSS/blob/master/OpenSans.css)

~~~
danieltillett
How did you do this?

~~~
steakejjs
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.

~~~
mmastrac
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...](http://www.metaltoad.com/blog/how-use-font-face-avoid-faux-italic-
and-bold-browser-styles)

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

------
mmastrac
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

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

~~~
mmastrac
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...](https://developers.google.com/web/fundamentals/performance/critical-
rendering-path/render-blocking-css?hl=en)

~~~
deanclatworthy
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.

------
hubot
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.

~~~
mmastrac
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".

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

------
Joe8Bit
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

~~~
mmastrac
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](https://www.google.com/fonts#ReviewPlace:refine)

