Last Friday, the WordPress Themes Team announced the release of its new Webfonts Loader project. It is a drop-in script that allows theme authors to load web fonts from the user’s site instead of a third-party CDN. The secondary message included in the team’s announcement is that it no longer plans to allow themes to hotlink Google Fonts in the future.
Throughout most of the team’s history, it has not allowed themes to hotlink or use CDNs for hosting theme assets, such as CSS, JavaScript, and fonts. The one exception to this rule was the use of Google Fonts. This allowed themes to have richer typography options at their disposal from what the team has generally declared a reliable source.
“The exception was made because there was no practical way to not have the exception at the time,” said Aria Stathopoulos, a Themes Team representative and developer behind the Webfonts Loader project. “The exception for Google Fonts was made out of necessity. Now that there is another way, the exception will not be necessary.”
In effect, disallowing the Google Fonts CDN would not be a new ban. It would be a removal of an exception to the existing ban.
Google Fonts has become so embedded into the theme developer toolset over the years, there was no way the team could simply pull the plug and prohibit the use of the CDN overnight. If the Themes Team members wanted to focus more on privacy, they would need to build a tool that made it dead simple for theme authors to use.
There is no hard deadline for when the team will remove the exception for Google Fonts, and it is not set in stone at this point. Stathopoulos said removing it has been the goal from the beginning, disallowing all CDNs. However, it took a while to find an efficient way to handle this. With a viable alternative in place, they can discuss moving forward.
Webfonts Loader for Themes
The Webfonts Loader project keeps it simple for theme authors. It introduces a new wptt_get_webfont_styles() function that developers can plug in a stylesheet URL. Once a page is loaded with that function call, it will download the fonts locally to a /fonts folder in the user’s /wp-content directory. This way, fonts will always be served from the user’s site.
The system is not limited to Google Fonts either. Any URL that serves CSS with an @font-face {} rule will work. It does not currently include authentication for CDNs that require API keys, such as Adobe Fonts. However, that is something the team might add in the future.
“For end-users, moving away from CDNs and locally hosting web fonts will improve performance (fewer handshake roundtrips for SSL), and is the privacy-conscious choice,” said Stathopoulos. “The only ‘valid privacy concern’ is that the web fonts’ CDN does not disclose information that is fundamental to the GDPR: what information gets logged, for how long these logs remain, how they are processed, if there is any cross-referencing with all the other wealth of information the company has from users, etc. The concern is a lack of disclosure and information. If a site owner doesn’t know what kind of information a third-party logs for its visitors, then they should ethically not enforce that on their visitors. With this package, the CDN is removed from the equation and the font still gets served fast — if not faster.”
A Path to Core WordPress
Today, there is now a broader focus on privacy concerns related to third-party resources, particularly with tech giants like Google. Such concerns extend to whether third parties are tracking users or collecting data. Additional concerns are around whether sites are disclosing the use of third-party resources, which may be required in some jurisdictions. Site owners who are often unable to work through the web of potential issues are stuck in the middle.
Jono Alderson opened a ticket to create an API for loading web fonts locally in core WordPress in February 2019. It is a lengthy and detailed proposal, but it has yet to see much buy-in outside of a handful of developers.
“If such a script is standardized and included in WordPress core, one of the main benefits would be more respect for the end-user’s privacy,” said Stathopoulos. “In the end, that’s all privacy is about: respecting users.”
A standard API like Alderson proposes could solve some issues. Namely, it would virtually eliminate any privacy concerns. However, loading fonts locally could allow WordPress to optimize font loading and would create a shared system where plugins and themes do not load duplicate assets because of the current limitations of the enqueuing system. A standard API would also put the responsibility of efficiently loading fonts on WordPress’s shoulders instead of theme and plugin developers.
The Themes Team’s new project is a solid start and strengthens the current proposal.
“If we’re serious about WordPress becoming a fast, privacy-friendly platform, we can’t rely on theme developers to add and manage fonts without providing a framework to support them,” wrote Alderson in the ticket.
