How to make Google fonts load locally.

How to make Google Fonts load locally. In this post I’ll be discussing how to make Google Fonts load locally, why you might want to do this, and what the benefits you’ll gain by doing this.

If you’d rather just find out the quick and easy way to do this, rather than read about what’s happening and why, you can click here to skip to the “or you could just use a plugin” section.

Why you’d want to make google fonts load locally.

Why would you want to make Google Fonts load locally when the text on your website is displaying perfectly fine as it is?

When you’re optimising your site to improve it’s performance one of the improvement opportunities you may be able to fulfil is “eliminate render blocking resources”.

You’d typically see this when using https://pagespeed.web.dev/ to analyse your site in the “performance” section.

If you expand this section, you may well see this:

That’s 750ms of render blocking taking place, just by using Google Fonts and calling them externally.

Consequently, you may well want to eliminate this render blocking time, and one of the (easier) ways you can do this is by making Google Fonts load locally.

Why loading external google fonts render blocking.

There are a few reasons why loading google fonts externally can be render blocking.

The first thing to take in to account is the address of the Google Fonts CSS file. If you see the same as the example above, clicking on the “/css?family=…” text will open the google fonts file:

If you look at the address in your browser’s address bar, you’ll see something like this:

That’s not the address of your site in the browser’s address bar is it?

This means that when your site’s pages are accessed, the browser is instructed to load the Google Fonts file from fonts.googleapis.com, which isn’t part of your site.

The computer being used to access your site then has to carry out a DNS lookup, then send a request to https://fonts.googleapis.com, the CSS file is then obtained from this source, and once all of this has happened, the browser can then start rendering the page.

If you have a look in the CSS file itself, there’s also no:

font-display: swap;

The lack of this means that the browser isn’t going to fall back on a system font and use that to display the text on your site while the DNS lookup, request, download and render mentioned above takes place. This can also cause the “ensure text remains visible during webfont load” message in https://pagespeed.web.dev/:

Ensure text remains visible during webfont load

So you might have two problems here. One being that the page can’ t be rendered as quickly as it might due to the lookup, request, and download mentioned above, and the other being that text isn’t displayed until the CSS file has been requested, obtained and rendered by the browser.

There are a few ways that this can be dealt with. The easiest is to load Google fonts locally, and let a plugin sort this out for you, which is covered later in this article (the local aspect is what essentially eliminates the call to an external resource and the plugin you use may also reduce some of the associated overhead mentioned above). Let’s cover some of the other aspects first though.

These “other aspects” that I’m going to talk about are mentioned so that you know what’s actually happening here. The idea being that you’ll gain a greater understanding of the situation at hand, rather than being the de facto way to address them. These other aspects are:

Asynchronous loading
font-display: swap;

Asynchronous loading.

Instead of using a standard link tag to include the external CSS file, you can use the a javascript function to change media attribute, to load the font file asynchronously.

In the example I took the screen shots of above, the Google Fonts file is being called like this:

But if it’s called like this:

var stylesheet = document.createElement(“link”);

stylesheet.rel = “stylesheet”;

stylesheet.href = “//fonts.googleapis.com/css?family=Lato:300,400,700,900,300italic,400italic,700italic”;

stylesheet.type = “text/css”;

document.head.appendChild(stylesheet);

</script>

It makes the loading of the fonts file asyncrhonous.

By using the additional <script>, you’re effectively telling the browser that it should execute this script when the CSS file has finished loading.

The page can be rendered while the CSS file is still being downloaded, and that the CSS can be applied once the page has been rendered.

Without this the CSS would have to be downloaded and applied for the page to be rendered by the browser.

Exactly how you’d apply this is very variable when using WordPress, as people generally use WordPress so that they don’t have to do things like this. If you’re writing your own site code this might be an option, but it’s probably going to be nightmarish to apply what I’ve mentioned above when using WordPress.

CSS font-display: swap;

In CSS font-display: swap; effectively means “fall back on a system font while this custom font is still loading”.

In practical terms, this could mean that using font-display: swap; in a CSS file would mean that something like the text (or a piece of text) on your site’s page is very briefly displayed as Time New Roman for a second (or under a second) while the custom font loads.

As your site calls the CSS file from fonts.googleapis.com you can’t actually add font-display: swap; directly to the CSS file.

According to Google’s own advice covering this you can bring font-display: swap; in to effect by adding this:

&display=swap

To the end of the URL being used to call the Google Fonts CSS file, so you’d change this:

To this:

To bring font-display: swap; in to effect on the called fonts file.

The problem is, at this point, the use of WordPress itself. The whole reason people use WordPress is so that “this kind of thing” is effectively done for you, and as it’s been done for you (albeit not in quite the right way), you don’t know what to change to carry out the above, or where to change it.

Now factor in the variable nature of WordPress (based on variations in themes, plugins and page builders themselves), and “make this change here” turns in to thousands of variations of “when using x you make this change by doing y”. There’s no specific way of changing what I’ve outlined above due to this.

It’s possible that you might be able to make this change by doing something like manually editing the database or a file in your WordPress, but:

You have to find where to make the change in the first place.
It’s possible that the change you make might not remain in place after updates have been applied.
Even if you do manage to do this, you’re still calling a resource from an external source, and there’s an overhead associated with doing so (so whilst https://pagespeed.web.dev/ might stop complaining, or at least complaining in the same capacity, you’re still making a browser do additional work).

Having said that, you might be able to globally enforce font-display: swap; by doing something like using a custom CSS plugin such as the “Simple Custom CSS and JS” plugin, and then add the following to this plugin’s “Custom CSS” section:

/* Globally enforce font-display: swap; for all custom fonts */

@font-face {

font-display: swap;

}

There are some potential downsides of operating in this manner, such as:

What I’ve mentioned above could potentially be overridden with a css !important declaration somewhere else in your site’s CSS.
There would still be an external DNS lookup associated with calling the CSS file from an external source (fonts.googleapis.com), which has some overhead associated with it.

Or you could just use a plugin to make google fonts load locally.

In some countries loading Google Fonts externally isn’t compliant with their data privacy laws (especially is the provider of the external fonts is based in another country).

Whilst this might sound a little excessive, this does mean that plugin developers have made WordPress plugins to effectively make sites compliant with such laws. The OMGF plugin is one such plugin, and it’s also easy to use and has a sensible “Font display” option that you can use to set font-display: swap; which is nice.

You’d install this as you would do any other plugin. Hover over plugins, then click on “add new”:

Then type OMGF in the search box, wait a few moments, then click on “Install now” next to OMGF:

Then wait for the install to complete, then click on “Activate”:

When the activation completes, you’ll then be directed back to the list of installed plugins, and on the same line as OMFG, there’s “settings”, click on this:

Hopefully you’ll see a big green box with “No potential conflicts found in your configuration.” at the top after clicking the settings link above. If you do then you’re good to go ahead and use this plugin. Whilst there are quite a few pages of options, there are only really a handful you’s initially need to take in to account:

Auto-configure subsets. If you don’t know what you’re doing or you don’t know what this means, ticking this box would probably be a good idea. OMGF will work out what subsets your site uses (essentially font variations) and then install these locally. The only downside might be that the CSS file it creates might be big, and have more of an overhead, but you’d probably have to have lots of font variations on your site for this to take place.
Font-Display option. Set this to “swap” as it helps with the “ensure text remains visible during webfont load” issue flagged by https://pagespeed.web.dev/ . It tells the browser to fall back on a system font while CSS is loaded.
Test Mode. If you tick this, you can then browse around your site to see if any problems are caused by using this plugin (you’ll need to be logged in to your site’s back end to see issues on pages).

Clicking the “Save and Optimize” button brings the changes into effect (unless you’ve ticked “Test Mode”) and makes your site start loading Goolgle Fonts locally. You can see what I’ve mentioned above here:

When you click the “Save and Optimize” button OMGF will cache the Google Fonts CSS file(s) and put them in:

document_root/wp-content/uploads/omgf

And it also generates a custom CSS file that points to the locally cached font files instead of the original Google Fonts URLs.

You might need to clear caches to see the effect of what you’ve just carried out take place.

If you generate more site content using different fonts to the ones you’ve previously, OMGF should automatically cache these locally as well, but if it doesn’t you can make it do so by click on “Empty the Cache” as seen in the screen shot above.

In conclusion.

Loading Google Fonts from an external source has an overhead associated with it.
If you load Google Fonts from an external source, it’s possible that more than the external factor can be flagged as an issue by tools such as https://pagespeed.web.dev/.
Whilst some of the flagged issues can be addressed by bringing font-display: swap; in to effect, or using the onload=”” directive, this doesn’t address the overhead associated with calling external resources.
Both the external aspect AND the “ensure text remains visible during webfont load” issue can be addressed using the OMGF plugin.
Your site will get a better performance score in analysis tools if you call font files locally, addressing the “ensure text remains visible during webfont load” issue when doing so.

How to Make Google Fonts Load Locally