Skip to content
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

Change to host Google Fonts locally for performance reasons #607

Merged
merged 3 commits into from Jan 10, 2020

Conversation

tunetheweb
Copy link
Contributor

@tunetheweb tunetheweb commented Dec 29, 2019

Using Google Fonts requires downloading a CSS file from one domain and then the fonts from another. Although we preconnect to the second domain, this CSS download still creates quite a delay in loading the fonts and a noticeable switch when they do finally download (as we are using font-display:swap to avoid blocking the rendering totally).

image

This PR changes to serve the fonts locally, which can also mean then that we can preload the fonts directly, rather than just preconnect to fonts.gstatic.com (note the preload is not included in this PR and is a future enhancement if this is accepted as need to test performance impact of this).

Note Google Fonts are open source and are allowed to be served locally though their FAQ recommends serving from their server for performance reasons, mostly under the assumption that they will already be cached but this is a bit hopeful (Lato is popular but still only on 3% of sites and our other font Poppins is only used 1% of sites according to our own stats) and also becomes meaningless in a double cached world - like Safari is already, and Chrome will likely be soon.

Note I have only included WOFF2 as feel browser support is at the point that this serves a sufficient majority of the clients (93.66% of global users according to caniuse) and the rest can fall back gracefully to the system default sans-serif font. In fact they'll probably benefit from this as older and slower browsers. I tested the site locally in IE11 (which doesn't support WOFF2) and it looked acceptable to me.

@tunetheweb tunetheweb added the development Building the Almanac tech stack label Dec 29, 2019
@tunetheweb tunetheweb added this to TODO in Web Almanac 2019 via automation Dec 29, 2019
@rviscomi
Copy link
Member

rviscomi commented Jan 6, 2020

This is an interesting proposal. I'd like to take some time to play with the solution and test the impact.

@tunetheweb
Copy link
Contributor Author

tunetheweb commented Jan 6, 2020

Hmmm interestingly the font sizes are different.

From Google Fonts they are smaller:

image

(Note production currently loads 7 fonts as opposed to 6 due to some design changes not on production yet.)

This is because Google Fonts uses sub-setting as their stylesheets contain unicode-ranges:

/* latin-ext */
@font-face {
  font-family: 'Lato';
  font-style: italic;
  font-weight: 400;
  font-display: swap;
  src: local('Lato Italic'), local('Lato-Italic'), url(https://fonts.gstatic.com/s/lato/v16/S6u8w4BMUTPHjxsAUi-qNiXg7eU0.woff2) format('woff2');
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'Lato';
  font-style: italic;
  font-weight: 400;
  font-display: swap;
  src: local('Lato Italic'), local('Lato-Italic'), url(https://fonts.gstatic.com/s/lato/v16/S6u8w4BMUTPHjxsAXC-qNiXg7Q.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Didn't realise that made such a difference! This is one of the advantages of Google Fonts is that they take care of things like this for you.

Anyway I just changed this PR to also subset fonts this way for WOFF2 when hosting locally and added to this PR and we're back to the same size. Looks like pretty much all the browsers that support WOFF2, also support font sub-setting so don't think it's worth feature detecting this like Google Fonts does.

On a similar note, what's your thoughts on not supporting WOFF? Nearly all browsers support WOFF2 now (IE11 being the exception) and we always have the fallback fonts for them (and they probably would be better off with no fancy fonts for performance reasons) so I think it's time to move to a WOFF2 only world.

@rviscomi
Copy link
Member

rviscomi commented Jan 6, 2020

@davelab6 and @zachleat may have opinions and answers on this subject :)

@tunetheweb
Copy link
Contributor Author

tunetheweb commented Jan 7, 2020

Just watched this talk from @zachleat : https://www.youtube.com/watch?v=FbguhX3n3Uc&feature=youtu.be

In it he suggests self-hosting, preloading critical (but not all!) fonts for best performance, and then ideally do a JavaScript font-loading API to minimise reflows.

Does depend on decent HTTP/2 prioritisation and being on Google Cloud CDN means we're not according to https://github.com/andydavies/http2-prioritization-issues#cdns--cloud-hosting-services so should do some testing.

Maybe release soon before landing this as a few other changes affecting performance, then try again with landing this?

@rviscomi
Copy link
Member

rviscomi commented Jan 10, 2020

I've staged these changes to https://20200110t162143-dot-webalmanac.appspot.com/en/2019/ (minus the static font file caching rules since fixed by #628). I'll run some WPT tests and post some results here.

@tunetheweb
Copy link
Contributor Author

tunetheweb commented Jan 10, 2020

Looks like quite a difference even without the preload tag from a quick test for me as first render no longer blocked on that Google Fonts CSS:

https://www.webpagetest.org/video/compare.php?tests=200110_31_6c563f40d32a2930af9d0988a6a8c6fb,200110_1V_f40e55dc0c8dcd7d49d2a79de38fde8b

image

image

@rviscomi
Copy link
Member

rviscomi commented Jan 10, 2020

[I wrote this comment but forgot to hit Submit]

Yup it's faster! 😄

Desktop / Mobile

Each are ~500ms faster in the lab tests. This looks like a good change, great work @bazzadp!

@rviscomi rviscomi merged commit 6c44618 into master Jan 10, 2020
Web Almanac 2019 automation moved this from TODO to Done Jan 10, 2020
@rviscomi rviscomi deleted the local_fonts branch Jan 10, 2020
@tunetheweb
Copy link
Contributor Author

tunetheweb commented Jan 11, 2020

@rviscomi I noticed the fonts weren't loading to submitted another fix (#631 ) and merged and released since production was broken.

@tunetheweb
Copy link
Contributor Author

tunetheweb commented Jan 12, 2020

FYI I wrote this up in a blog: https://www.tunetheweb.com/blog/should-you-self-host-google-fonts/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
development Building the Almanac tech stack performance Issues related to site performance
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

2 participants