-
-
Notifications
You must be signed in to change notification settings - Fork 182
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
Conversation
This is an interesting proposal. I'd like to take some time to play with the solution and test the impact. |
Hmmm interestingly the font sizes are different. From Google Fonts they are smaller: (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:
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. |
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? |
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. |
Looks like quite a difference even without the |
FYI I wrote this up in a blog: https://www.tunetheweb.com/blog/should-you-self-host-google-fonts/ |
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).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.