Inline Google Fonts #672
Inline Google Fonts #672
Conversation
@konklone do we need to add |
@gboone No, it doesn't need to be run ever again. I suppose we could do it every once in a while, in case Google makes improvements to the upstream files...? But it doesn't need to be any kind of regular thing, anyway. I guess Google Fonts does do some browser-detection as part of their service, but I think this approach should work on all browsers we target. I can confirm this works fine on Chrome and Firefox. Anyone in a position to check out Safari and IE? |
Thanks for the clarification. I can fire up my modern.ie virtual boxes and test the internet explorers. |
Looks good in IE. |
And in Safari. Merging! |
Why no WOFF2 in It looks like there’s a setting that forces |
Hi @mathiasbynens -- I don't know very much about WOFF2! Is there a way for us to make a static CSS file (that doesn't change its content based on user agent) that can serve WOFF2 to those browsers that can use it, while falling back gracefully for other UAs? I assume that |
@font-face {
font-family: MyAwesomeFont;
src: url('MyAwesomeFont.eot');
src: url('MyAwesomeFont.eot?#iefix') format('embedded-opentype'),
/* Ready? Here comes the important part: */
url('MyAwesomeFont.woff2') format('woff2'),
/* That’s it! */
url('MyAwesomeFont.woff') format('woff'),
url('MyAwesomeFont.ttf') format('truetype'),
url('MyAwesomeFont.svg#myawesomefont') format('svg');
font-weight: normal;
font-style: normal;
}
According to their README, it’s disabled by default because of WOFF2’s limited browser support. I don’t think this applies anymore however, since nowadays WOFF2 is supported by Chrome, Opera, and Firefox. I’ve filed mmastrac/webfont-dl#8 for that. |
@mathiasbynens I'm asking in that thread whether there are compatibility issues. The author's reticence to include it by default gives me pause as well. |
@konklone There are no compatibility issues. The only reason the author doesn’t want to include it yet is because by default, webfont-dl inlines each font file as a base64-encoded data URL, and adding the WOFF2 version inline would only increase the resulting CSS file size, which kind of defeats the point. However, I’d argue that it’s better to not inline (over HTTP2) and use separate files instead. That way, modern browsers get the lightweight WOFF2 version, and older browsers pick whatever alternate version they support. |
We support SPDY here, so that would work here. More generally across our projects, some can support SPDY/H2 and some can't. Hopefully by a year from now, H2 will be standard and supported everywhere, but in the meantime, it sounds like a file that links to both WOFF2 and WOFF is best for 18f.gsa.gov. Mind doing a bit of the legwork and figuring out the correct |
Here’s the full command: webfont-dl 'https://fonts.googleapis.com/css?family=Raleway:400,700%7COpen+Sans:400,700' -o assets/css/google-fonts.css --font-out=assets/fonts/ --css-rel=../fonts --woff1=link --woff2=link --svg=omit Note that I also omit SVG fonts since they’re not needed anymore nowadays. (This is another thing I think webfont-dl should do by default.) |
This uses the glory that is
webfont-dl
to download and inline the Google Fonts we use. This removes one of our third party services that gets pinged during user visits.Specifically, what I did was install
webfont-dl
:And then I ran this command from the project root:
This creates a new file,
google-fonts.css
, with the@font-face
instructions that references a bunch of newly downloaded files for Raleway and Open Sans that are put inassets/fonts
. Font references are all worked out automatically.From here, we're free to rejigger them however we want -- we could combine
fonts.css
andgoogle-fonts.css
, for example. But of course, there isn't any real performance penalty to keeping them separate over SPDY, which is part of why this move improves performance for our site in the first place.A "before" of capturing network requests during homepage load in Chrome developer tools, filtering on "font":
And an "after" of what that looks like after this PR:
The homepage looks identical and the fonts work perfectly.