Goodbye Google (Fonts)

I recently wrote about an experiment by Gizmodo journalist Kashmir Hill to stop using products and services provided by the top five tech companies. Part of that experience was that websites slowed dramatically because they were so enmeshed with large technology companies — this is a follow-up, looking at ways to avoid such services.

Google has spent considerable effort trying to speed up the internet. It’s one of the areas where Google’s interests align with a fast, free and open web. By encouraging developers to create faster, better experiences, Google can ensure that users will browse the web (where Google makes money from advertising), rather than stay within the controlled confines of networks and apps, such as Facebook.

Google uses a stick and carrot approach to try and improve site speed. In July 2018, site speed became a factor in the Google Search algorithm, meaning that slow sites would be penalised in search results, but Google also provides developers with free testing tools and services, like Google Fonts, to make it easier to improve website speed.

The philosophy behind Google Fonts is to provide access to a library of open-source fonts, hosted on Google infrastructure, and to take advantage of the network effect — if you visit a website that requests a font from Google, that font is cached in your browser and when you visit other sites that also use those Google fonts, since you already have a cached version, those sites load faster.

That sounds great, why would I not use Google Fonts?

As the Gizmodo article points out, Google Fonts doesn’t track individual users, but it’s still a Google product and there are plenty of reasons to avoid supporting a company that has been at the centre of numerous scandals. But there are also plenty of reasons for developers to not use Google Fonts, and perhaps the best of those is learning how to build a better, faster user experience without a third party.

Downloading Google Fonts

All the fonts in the Google Fonts library are open source, so it should be easy to download webfont packages. Google suggests using Monotype’s SkyFonts to download files, but the easiest way is to use Mario Ranftl’s google-webfonts-helper app.

This web app is specifically created to make it easy to self-host Google Fonts and not only provides downloads of webfont files but generates a CSS snippet to use them.

Once you’ve made your choice, download the font files, add the CSS snippet to your stylesheet, load everything to your server and you’re self-hosting font files.

Browser support

Part of the CSS snippet generator in the google-webfonts-helper app is a toggle between “Best Support” and “Modern Browsers”. The default option is Best Support and this provides font support for old versions of Internet Explorer, Safari, iOS and Android. The Modern Browsers option provides support for browsers that are able to display WOFF and WOFF2 font files.

It might seem that offering broad support is the best option, but every web font and each variant and weight of that font requires an additional server request and will contribute to the overall size of your website. So, it’s worth considering the importance of the font to your site design and judging whether a user on an older browser, possibly with less computing power and bandwidth, would have a better experience using a system font.

Font rendering controls

Something missing from the app, and from Google Fonts, is a new CSS property font-display. This property gives developers more control over the browser’s font rendering process.

When browsers request a font, they need to decide how to display elements that are styled with this font. One method is to display invisible elements which are rendered when the font is loaded, this is known as “Flash of Invisible Text,” or FOIT. The alternative is when elements load using a fallback font and then swap to the custom font once it is loaded, known as “Flash of Unstyled Text,” or FOUT.

The font-display property allows the developer to choose how the browser should behave.

It’s another decision to make, based on the user experience and where the font is being used. If it’s essential to the design that the custom font is displayed, it might be preferable to use the keyword block and have a FOIT. If the content is essential (body text, for example) it’s probably a better user experience to display it immediately, using the keyword swap and have a FOUT.

There’s a great article on font-display at CSS Tricks.

Optimising font loading

By self-hosting webfonts, we have greater control over the way the resources are loaded on the site. Using the preload resource hint, we can instruct the browser to start loading the font as early as possible.

Here’s an example of the preload hint in action:

<link rel="preload"
      href="./fonts/fira-mono-v6-latin-regular.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

• rel=”preload” tells the browser to fetch the resource without blocking the browser onload event
• as=”font” tells the browser the type of resource that it will be downloading, without this the browser will lower the priority of the request
• type=”font/woff2 tells the browser the mime type of the resource
• crossorigin is required because preload will fetch resources using anonymous mode CORS.

This preload directive tells the browser that we will need the resource at some stage. So, the file will always be fetched on pages with the directive. You can use prefetch if you want to provide a hint to the browser that a resource might be needed, but that ends up lowering the priority of the request.

Another thing to note, since browsers that support preload also support WOFF2 files, it’s probably only worth using this directive to preload WOFF2 webfonts.

In conclusion…

This hasn’t been an exhaustive look at webfonts, there are plenty of tutorials and guides for that, but hopefully this offers a simple way to say goodbye to Google while still using Google Fonts.