TL;DR: Use the Create Block Theme plugin to bundle fonts in your theme with just a few clicks.
WordPress block themes allow you to add fonts to a theme by adding the font file assets to the theme folder and referencing them in the theme.json. Editing a JSON file manually does not deliver the best user experience. The good news is you can use the plugin to make this task much simpler without technical trade-offs.
Disclaimer: The plugin is for development only and is not intended for live production websites because it modifies the currently active theme. It was conceived as a tool to create new production-ready themes.
The plugin stores the font assets in a sub-folder of your theme ( <your-current-theme>/assets/fonts/ ) and adds font family definitions to your theme.json file. This is the case no matter if you upload a local font asset or use the Add Google Font option.
The plugin removes both the theme.json definition and the font assets if you remove a font face.
WordPress takes the font faces you added using the plugin, which are listed in your theme.json, and automatically converts them to CSS font face definitions which are included in the HTML page downloaded by the user browser.
Yes and no, or not necessarily. That can be counter-intuitive so let’s explore it in more detail.
WordPress references all the font files needed in your site CSS to let the browser know what font assets may need to download.
Even though WordPress references many fonts, modern browsers are optimized to only download the fonts that are used in the page being loaded. It is important to note that browsers calculate this considering just the current page loaded and not on a site-wide basis.
For example, if you include an ultra-thin variant of the Inter font family, but there is not a single element (ex: paragraphs, links, etc.) using Inter ultra-thin variant, the browser will not download this font asset. In this case, the performance penalty for including this font is nearly zero.
No, both from a performance and design perspective, having a good font pair is always advisable over a proliferation of too many different fonts. Also, if the font is not in use, what’s the point of including it?
There is no magical number of font faces you can or should include. But usually, less is more. Sticking to the minimal quantity required to implement the aesthetics you are looking for is always a good idea.
As with any other font file, you can add variable font assets using the “Add Local Font” option. The plugin will add the font definition and asset just like any other type of font. You can use it just like that or adjust more options related to variable fonts by editing the theme.json file.
Yes, because the plugin bundles the font files in your theme, and your WordPress instance will serve them. No third-party servers or tracking technologies are involved in serving the fonts to your users. You don’t need to request extra permissions from your users to include the fonts.
Do you need a more detailed step-by-step guide? No worries! Check out this great video tutorial about how to use the plugin.
Have any questions about fonts and themes? Ask in the comments!
When building block themes there is often more than one way to achieve the same thing. It’s often not clear which of these options is preferable. Below I outline some tips and guidelines that I find helpful. The guiding principle here is to remove as much complexity as possible from the theme; instead block themes should be using the affordances provided by Gutenberg.
As much as possible, block themes should avoid providing CSS. Gutenberg increasingly offers design tools which allow theme builder to control the design of the theme without using CSS. If it is not possible to achieve a particular design without CSS please create an issue for it on Gutenberg so we can consider adding a design tool to achieve the design.
As the number of block themes we build grows we will have an ever increasing number of templates and template parts in each theme. In practice there are a small number of patterns which can be reused on many themes. We should be aiming to reuse existing patterns rather than implementing new templates. This means we need clever patterns which are able to reuse settings from theme.json.
Connected to the point above, when we want to change the appearance of a block in a template or a pattern it is usually better to do so in the theme.json file than in the block template. This means that the design will be used for all instances of the block, not just the edited instance. It also keeps templates design agnostic, so that they be reused (see above).
What other tips do you have for building block themes?
Login
