This tutorial features the Feast Plugin, which contains enhances and extends your theme.
Note: this feature is still in BETA for testing and bug fixes and not officially recommended. Subscribe to the newsletter to be notified of its release.
The fonts implementation in the themes were implemented using best practices at the time they were developed, which was around 2016.
The web of 2016 is not the same as the web of 2020.
While the functionality was useful and simple at the time, we now consider it outdated. Unfortunately, no easy alternative exists due to the complexity involved in selecting and combining the appropriate fonts and variations.
What problem does this solve?
Google has changed their recommended implementation of Google Fonts, and now throws a warning in pagespeed insights if you followed their historical implementation.
The two documents they provide for guidance for this are:
This is a little confusing, because the speed index page claims that this can have a big impact, while the actual pagespeed insights tool claims that it doesn't.
Update June 2020: the Google Pagespeed Insights (lighthouse v6) is now throwing additional warnings, and recommend that sites self-host fonts, which adds all new complexity.
Why is this in the plugin rather than themes?
As of 2019, recommendations have changed to add additional parameters such as display-swap. Unfortunately, because this is coded into the themes, we have no way to update this for our customers.
To highlight this, we were recently made aware of a bug that crashed certain browsers, which we were able to resolve in the 4.3.0 theme updates. However, bloggers need to manually update the theme to apply this fix. This raised the concern that we need to provide a more modern alternative
Finally, each theme has a slightly different implementation (and none at all in Cook'd), which means that we can either fix this once in the plugin and update regularly moving forward, or spend 5x as long implementing a version into 5 themes, which will be out of date again in 12 months.
That's where the Feast Plugin shines. By building the modern implementation into the plugin, we can modify it through an update when it becomes necessary at some point in the future.
This functionality, when built into the plugin, becomes consistent across all themes, reducing anxiety involved in selecting a theme.
Problems with the theme implementation
The theme implementation was cutting edge when first implemented, but suffers from a few issues that weren't important back then:
- External connection - DNS connection download
- Runs code on each page load - fetch from database, parse, output (rather than serve cached result)
- Susceptible to FOIT (flash of invisible text) - resolved by font-swap
#1 was somewhat mitigated by the fact that shared external resources (such as Google Fonts) were sometimes cached by the browser. Recent privacy concerns means that browsers will no longer accept this behavior, which means font assets will no longer be cached and shared between websites.
#2 is not a best practice, but in all likelihood has very little relative impact on pagespeed and response times. Removing this would be a minor optimization, whose benefit would only really be noticeable in conjunction with the dozens of other optimizations we've made. Nevertheless, we want to do anything we can to improve pagespeed.
#3 is not something I've ever personally noticed, but is important enough that Google flags this in their Pagespeed Insights tool.
What's important to note here is that despite these issues, the theme's Google Fonts does not impact pagespeed when our recommended WP Rocket settings are enabled. The demo sites are able to hit 99/100 and 100/100 on the pagespeed insights tool despite this warning being there.
Taking it a step further
Google recently updated their fonts user interface to make downloading fonts much simpler.
Rather than continue loading fonts hosted externally, which slow pagespeed by adding a DNS call and connecting to an HTTPS server, some more advanced users may find it beneficial to self-host the fonts.
Self-hosting the fonts not only decreases page load times by removing external connections, it also safeguards your font choice against updates and edits may make to their fonts.
This is currently far too technical for us to provide support for, so we'll recommend advanced users follow this guide on self hosting Google Fonts.
Update 2021/03/03: self-hosting Google Fonts is not the solution it was promised to be, as it can still cause CLS and other issues.
By splitting this into a separate module, we're able to begin modifying the block editor styling to include the Google Fonts you've selected on both the front-end and in the block editor styling, for a more consistent post writing experience. This isn't currently implemented, but will be released in a future update.
We haven't been able to release a "Modern Google Fonts" because the following issues remain unclear in the long term:
- some fonts are different sizes than others - 20px in one font looks like 40px in another
- how do we avoid CLS (content-layout-shift) penalties with the upcoming Google Page Experience
- how do we support ensuring accessibility issues around fonts (eg. font size is readable and not too small)
- how do we import a customers imported font, and font-display, in the block editor and FSE
- is importing into the <head> still adequate? Google appears to be pushing for self-host fonts, which requires entirely different processes
- how do we provide guidance on the different font styles that may be required? italics? font weight? script subsets?
- how do we balance pagespeed with the number of fonts and font weights? is this even something we should support or does fall under pagespeed plugins such as WP Rocket?
Given the above, we estimate that supporting custom fonts would take 1-2 hours per customer and this level of support is not built into our pricing model.
Google Fonts basically requires its own paid plugin with active customer support.
When the themes were built, most of the issues above were not concerned. Given the current technical challenges and uncertainty, it doesn't seem like we can properly support this, and it would require a custom developer to implement.