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

Inline Google Fonts #672

Merged
merged 1 commit into from Apr 3, 2015

Conversation

Projects
None yet
3 participants
@konklone
Member

konklone commented Apr 3, 2015

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:

npm install -g webfont-dl

And then I ran this command from the project root:

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

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 in assets/fonts. Font references are all worked out automatically.

From here, we're free to rejigger them however we want -- we could combine fonts.css and google-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":

before

And an "after" of what that looks like after this PR:

after

The homepage looks identical and the fonts work perfectly.

@gboone

This comment has been minimized.

Contributor

gboone commented Apr 3, 2015

@konklone do we need to add npm install -g webfont-dl to build instructions? If I'm understanding correctly that's a one time thing you had to do to make this happen. I ran it locally and had no problems but still want to double check.

@konklone

This comment has been minimized.

Member

konklone commented Apr 3, 2015

@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?

@gboone

This comment has been minimized.

Contributor

gboone commented Apr 3, 2015

Thanks for the clarification. I can fire up my modern.ie virtual boxes and test the internet explorers.

@gboone

This comment has been minimized.

Contributor

gboone commented Apr 3, 2015

Looks good in IE. 👍

@gboone

This comment has been minimized.

Contributor

gboone commented Apr 3, 2015

And in Safari. Merging!

gboone added a commit that referenced this pull request Apr 3, 2015

@gboone gboone merged commit 9b2aa30 into staging Apr 3, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@konklone konklone referenced this pull request Apr 7, 2015

Merged

Tighten up privacy settings #9

@mathiasbynens

This comment has been minimized.

mathiasbynens commented Apr 29, 2015

Why no WOFF2 in google-fonts.css? https://fonts.googleapis.com/css?family=Raleway:400,700%7COpen+Sans:400,700 contains WOFF2 versions when viewed in Chrome, Opera, or Firefox. (WOFF2 is much smaller than WOFF.)

It looks like there’s a setting that forces webfont-dl to download WOFF2 as well: https://github.com/mmastrac/webfont-dl#woff-v2

@konklone

This comment has been minimized.

Member

konklone commented Apr 29, 2015

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 webfont-dl disables it because it hurts compatibility?

@mathiasbynens

This comment has been minimized.

mathiasbynens commented Apr 29, 2015

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?

There is:

@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;
}

I assume that webfont-dl disables it because it hurts compatibility?

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.

@konklone

This comment has been minimized.

Member

konklone commented Apr 29, 2015

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

@mathiasbynens

This comment has been minimized.

mathiasbynens commented Apr 29, 2015

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

@konklone

This comment has been minimized.

Member

konklone commented Apr 29, 2015

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 webfont-dl command that does what you're recommending? Happy to take this work and get it into our front-end standards and include it in our third-party-avoidance evangelism.

@mathiasbynens

This comment has been minimized.

mathiasbynens commented Apr 30, 2015

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

@konklone konklone referenced this pull request Jan 9, 2016

Closed

Grunt/CSS #61

@konklone konklone referenced this pull request Apr 12, 2016

Merged

Inline the Raleway font #29

@konklone konklone referenced this pull request May 18, 2016

Merged

Inline the Google Fonts #84

konklone added a commit to 18F/guides-style that referenced this pull request Jul 18, 2016

@konklone konklone referenced this pull request Feb 10, 2017

Merged

Some more cleanup #2

mbland added a commit to mbland/guides-style that referenced this pull request Feb 20, 2017

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