For developers, the road to a web fonts API in WordPress has been a rollercoaster of emotions. It was relocated to the Gutenberg project after being removed from the WordPress 5.9 release, where it could be built with related features that relied on it.
The API has been incorporated into the Gutenberg plugin, and version 12.8 should be available soon. Theme authors can clone the development version of the plugin or download the nightly version from Gutenberg Times to test it.
In February 2019, Jono Alderson created the first ticket for a web fonts API. However, it did not get widespread support and development until late 2021. The API appeared to be ready to launch with WordPress 5.9, according to most accounts. Andrew Ozz, one of the primary WordPress developers, put the project on hold.
It was a controversial choice, but it may have been the best one. The API was limited due to the lack of theme.json support. Because PHP was the only option, theme authors would have been forced to do what they’ve always done: create their own solution. This was not the reason for the delay in its release, but it will almost certainly be the most prevalent use case for the API.
While many expected this functionality to be included in WordPress 5.9, the extra time has allowed it to mature into a more user-friendly API that connects with the site and content editors.
Theme authors can now provide font-face definitions in theme.json files alongside their respective families, and WordPress will load the appropriate @font-face CSS in the editor and on the front end.
The disadvantage is that the feature only supports a local supplier, which means that fonts must be included with the theme. The original implementation included a Google Fonts supplier, but it was eventually removed.
Ozz goes into more depth in an earlier ticket, but for the time being, he recommends dropping Google Fonts support:
Add support only for local fonts for now. If WordPress decides to include support for the Google CDN later on, the implementation will have to consider web privacy laws and restrictions and be tied with an eventual User Consent API, etc.
One of the web fonts API’s creators, Ari Stathopoulos, highlighted how including a solution in core that writes font files directly to the server will increase privacy:
Instead of removing it, maybe we could implement them properly, enforcing locally-hosted webfonts to improve performance & privacy? This way we’d be setting a good example, and we’d see a significant performance & privacy improvement in the WP ecosystem as themes & plugins that currently use Google-fonts, Adobe-fonts and whatnot will start to adopt the API.
Local fonts appear to be officially supported for the time being, although theme and plugin authors must register custom providers. One concern with omitting Google Fonts support is that there would be a plethora of competing alternatives in the wild, rather than a single reliable service on which everyone can rely. The more developers who create their own wheels, the more likely it is that different implementations will contain bugs or security flaws.
Automattic has a draught patch for a Google Jetpack provider already. If that is incorporated into the plugin, it will almost certainly conflict with a future theme that registers its own Google provider ID.
Supporting only local fonts may result in bigger theme download sizes. This should be a non-issue for many themes. Font packages of one, two, or three fonts are sufficient. If global style variations grow popular, we may see themes that include dozens of typefaces to cover a variety of pre-made designs. This will quickly result in bloated theme files, and when combined with enough images, theme creators may exceed the directory’s 10MB restriction. That may seem like an issue for tomorrow, but it is something to consider today.
There are still some bugs with the API that need to be resolved. However, releasing it thus early in the WordPress 6.0 release cycle will allow everyone to try it and contribute to its improvement.