[seanwilson]

> It’s widely accepted that self-hosted fonts are the fastest option: same origin means reduced network negotiation, predictable URLs mean we can preload, self-hosted means we can set our own cache-control directives, and full ownership mitigates the risks that come with leaving static assets on third-party origins.

This is my general approach now. Feels like a lot of work to keep up with what the ideal remote loading snippet is when local hosting can be simpler and the fastest option. The deep dive into how all the approaches compare is really interesting though.

It's frustrating web developers still need to deal with this complexity just to load a font. I don't think most non-frontend developers realise how much effort it takes to make a nontrivial high performance website. Most of the time in frontend there's many ways to do the same thing, each with their own subtle performance tradeoffs.

[cpascal]

Another plus is you are not potentially leaking information about your users to a third party.

[Ayesh]

This is my approach too. For logo/slogan fonts, one can go ahead even subset the font.

It's probably a good idea to refresh the fonts off Google once or twice a year though. Although not often, these font file get updated.

[seanwilson]

> For logo/slogan fonts, one can go ahead even subset the font.

SVG is a nice option for logos. You can inline the SVG file directly into the HTML as well so there's no loading delay - especially useful for logos that need to be rendered immediately at the top of the page.