How to Optimize Google Fonts in WordPress

94,251,097,328,344+.

Yes, you counted the commas correctly (It took me some time as well, don’t worry)--Google Fonts have been viewed over 94 TRILLION times across the web. 

However, as popular and optimized as they are, how they are implemented on a WordPress site can make a big difference in loading speed.

That said, if you’re seeing slow load times from fonts.googleapis.com or fonts.gstatic.com in your DevTools waterfall, or your PageSpeed Insights report sends back warnings like “Ensure text remains visible during webfont load” and “Enable text compression”, this article will walk you through exactly how to fix all of that. 

Read on.
 

Understanding Google Fonts and Performance Implications

Why is that important?

Understanding how things work in the background will allow you to easily identify what causes the issue and which optimization will bring immediate results. 

That said, here’s how browsers handle font files and why sometimes there might be issues:

When a user visits your website, the browser starts by downloading the HTML. As it parses the page, it encounters CSS rules that reference external fonts, like those from Google Fonts. It then needs to pause rendering, fetch the font files, and apply them to the text.

 

This process can cause delays in how quickly text appears on screen. 

If the font isn’t loaded yet, some browsers hide the text (also known as a Flash of Invisible Text, or FOIT). 

Others might display fallback fonts first and then switch, causing layout shifts.

Now here’s the good news: 

Google Fonts are actually built with performance in mind:

• It serves font files through Google’s fast, globally distributed CDN
• Fonts are compressed using modern formats like WOFF2, which dramatically reduce file size
• It supports HTTP/2 for faster, multiplexed connections and serves only the character sets needed for your selected language
• Stylesheets are minified, and fonts are cached, so repeat visits load even faster

But, despite all these optimizations, performance issues can still happen if fonts are used carelessly.

Loading too many font families or weights can result in multiple, separate network requests. This not only increases load time but also blocks text from rendering. Large font files — especially those containing many styles or characters — can have a noticeable impact on page speed.

That’s why optimization isn’t just a nice-to-have. Even with a well-optimized service like Google Fonts, it’s crucial to use fonts intentionally and efficiently.

Let’s look at the best practices to help you do that.
 

Best Practices for Optimizing Google Fonts in WordPress

Limit the Number of Font Families and Weights

A font family is a typeface like Roboto, Inter, or Lato. Within each family, you’ll find font weights (the thickness of the letters) like 400 (regular), 700 (bold), or even 300 (light). 

What many site owners don’t realize is that every combination, like Roboto 400, Roboto 700 italic, or Lato 300, is a separate file. The browser needs to download each file before your text renders properly.

That means more network requests, longer load times, and slower experiences for your visitors, especially on mobile or slower networks.

 

While not using different fonts and weights may sound limiting, the truth is: you probably don’t need that many. 

In fact, most well-designed sites get by just fine with one font family and two weights, usually 400 for body text and 700 for headings.

That said, here’s how to make sure you don’t load any unnecessary families or weights with Google Fonts:

1. Go to Google Fonts and search for the typeface you want. For this example, I’m going to use Roboto. 

2. After you click “Get font,” you will be redirected to your cart to download the file or get an embed link. We’re going to embed the link directly.


 

3. Copy the embed code and adjust it. The original code looks like this:

This URL loads all combinations of Roboto:

• Weights from 100 (thin) to 900 (black).
• Widths (wdth) from condensed (75) to normal (100).
• Both normal (0) and italic (1) variants.

Unless you're explicitly using all these variations (which is rarely the case), this significantly slows down your page. 

That’s why you need to trim down the code and remove all unnecessary weight. Let’s say you will need regular weight (400) and bold weight (700). The optimized link would look like this:

This trimmed version drastically reduces font loading time and improves site performance without sacrificing the typography quality you need.

4. Add that embed code to your WordPress theme manually. You have two options:

1. Option A: Edit header.php by pasting the tag just before the closing head tag.
2. Option B: Use functions.php to enqueue the stylesheet. 

5. Review your CSS to avoid referencing unused weights. For example, if you’ve only loaded 400 and 700, don’t write font-weight: 300; or use styles that depend on italic unless you’ve included those variants too. Using unsupported styles can cause the browser to substitute fallback fonts, which might look inconsistent.

 

Self-Host Google Fonts

Google Fonts is fast, but you can make it even faster and more privacy-friendly by hosting the fonts directly on your own server. This eliminates external requests to Google's CDN, reduces DNS lookups, and allows browsers to cache the fonts more effectively.

Self-hosting also lets you take complete control of your fonts. You can subset them (include only the characters you actually use), compress them for smaller sizes, and even help comply with privacy regulations like GDPR by preventing third-party data requests.

Here’s how to self-host Google Fonts:

Step 1: Download the Fonts You Need

1. Visit Google Fonts
2. Search for your font (e.g., Roboto or Inter).
3. Select only the weights and styles you’ll use (e.g., regular 400, bold 700).
4. Choose your character subsets (like Latin).
5. Download the generated font files (usually .woff2 for best compression).

Step 2: Upload Fonts to Your Server

1. In your WordPress theme folder (wp-content/themes/your-theme), create a folder called fonts.
2. Upload the downloaded .woff2 files into this fonts folder.

Your theme structure should look like this:

Step 3: Add Fonts to Your CSS

In your theme’s CSS file (style.css), add the following @font-face rules:

Step 4: Use the Font in Your CSS

Now, simply reference your self-hosted font in your CSS as you normally would:

Step 5: Remove the Google Fonts External Call

Don’t forget to delete or comment out any external links to Google Fonts in your theme files (header.php or functions.php). You're now fully self-hosted!
 

Implement Font Display Strategies

Getting back to what happens in the background, when your site loads, your fonts don’t appear instantly because the browser has to fetch them first. And during that delay, what the user sees depends on a single CSS property – font-display.

The font-display property tells the browser how to handle text while waiting for a font to load. 

Should it hide the text until the font is ready? Show fallback text immediately? Wait a little, then decide?

Applying this property to your font files lets you control this behavior and dramatically improve the user’s experience, especially on slow connections.

And there are four font-display options to choose from:

1. font-display: swap – shows fallback text immediately, then swaps in the custom font once it’s loaded.

✅ Prevents invisible text (FOIT / Flash of Invisible Text).
✅ Feels faster to users.
❌ May cause a small layout shift once the font swaps in.

2. font-display: block – hides the text for up to 3 seconds while waiting for the custom font.

✅ Ensures consistent layout once loaded.
❌ Risk of blank text (FOIT), especially on slow connections.

3. font-display: fallback – shows fallback font immediately. If the custom font loads quickly, it swaps in. If not, it stays with fallback.

✅ Balanced approach.
❌ Font may not appear at all if loading is slow.

4. font-display: optional – бehaves like fallback, but deprioritizes loading the custom font entirely.

✅ Great for performance-focused sites.
❌ Font might not load at all — depends on connection and device conditions.

For most websites, the best choice is font-display: swap. 

Why? 

Because it avoids the Flash of Invisible Text, improves perceived performance, and still gives users the benefit of your custom font once it’s ready.

Here’s how to use font-display in your project:

1. Self-hosting fonts

If you're self-hosting your fonts, simply include font-display in your @font-face declarations:

2. Using the embed link

If you're using Google Fonts via their embed link, they already include font-display: swap in the URL by default — just make sure it’s there:

 

Preload Critical Font Files

When your site loads, the browser doesn’t automatically know which resources are most important. Priorities depend on the resource type (e.g., text, image, stylesheet, script, video) and the placement of the resource reference in the document. 

That means your fonts might not start downloading until late in the page load process, especially if they’re declared deep in your stylesheets.

That’s where resource hints and preloading come in. 

Link rel=preload is a powerful directive you can implement to give the browser a heads-up: “This font is critical, start loading it sooner.” 

Important: Use this directive sparingly and only for late-discovered resources that are critical for the above-the-fold experience.

Preloading is especially useful for fonts used in above-the-fold content like headers, navigation, and hero sections – the parts users see first. Also, it can positively impact metrics like Interaction to Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS).

Here’s how to preload your font files:

If you're self-hosting fonts, place the following tag inside your head before your main stylesheet loads. That way, the font begins downloading early in the page lifecycle:

Here’s what each part does:

• href — points to the font file
• as="font" — tells the browser the type of resource
• type="font/woff2" — specifies the format (use .woff2 for best compression)
• crossorigin — ensures the font is loaded correctly under CORS rules (recommended even if fonts are served locally)

If you’re using the embed link to load your font files, applying preloading is a bit complex. And to be honest, it can lead to more issues than gains, so it’s not worth the effort.

 

Preconnect to Font Origins

Just like preload, preconnect is another type of resource hint, and it’s especially useful if you’re embedding Google Fonts using their default CDN link rather than self-hosting the files.

While preload gives self-hosted fonts a head start, preconnect helps when you don’t control the font files directly, like when loading them from fonts.googleapis.com. 

It tells the browser: “Go ahead and set up the connection to this domain early — we’ll need it soon.”

That means the browser can start the DNS lookup, TCP handshake, and TLS negotiation right away — before it even encounters the actual request for the font CSS or font file. This can shave off precious milliseconds, especially on first visits.

 

How to use preconnect with Google Fonts:

If, for some reason, the Google Fonts’ embed code doesn’t include link rel=preconnect (which would be weird), you’ll want to preconnect to both domains involved in Google Fonts delivery:

• fonts.googleapis.com serves the CSS file that defines which fonts to load.
• fonts.gstatic.com serves the actual font files (like .woff2).

Make sure to always include crossorigin for fonts.gstatic.com to ensure the browser handles CORS properly. Furthermore, these should be placed before your Google Fonts embed code — ideally at the top of your head section.

 

Remove Unused Characters (Subsetting)

Every font file you load doesn’t just contain the letters you see on your screen. It often includes entire alphabets, symbols, and special characters, sometimes across multiple languages. That’s great for versatility, but not so great for performance.

If your site doesn’t need all those extra characters, you’re sending unnecessary data to every visitor. And that means longer load times and wasted bandwidth.

That’s where font subsetting comes in.

Subsetting is the practice of stripping out everything your site doesn’t use — leaving only the essential characters, like the basic Latin alphabet, numbers, or a custom set of glyphs. It’s one of the most effective ways to shrink font file sizes and speed up text rendering.

This is especially important for:

• Multilingual websites, where fonts often include multiple writing systems (e.g., Latin, Cyrillic, Greek).
• Fonts with large Unicode sets which can quietly add hundreds of kilobytes.
• Performance-focused builds, where cutting even a few KB can make a noticeable difference, especially on mobile.

By subsetting your fonts, you’re delivering only what’s needed, nothing more. That means faster sites and a smoother user experience.

How to subset your fonts:

If you're self-hosting your fonts, there are two ways to optimize them:

1. The easy way

If you're using NitroPack, font subsetting is handled for you automatically. It detects which characters your site uses and delivers a custom, lightweight version of each font — no manual setup, no code changes. This is ideal if you want performance without getting into the weeds.

2. The manual way

If you prefer a hands-on approach, you can generate custom subsets using tools like:

• Transfonter – A browser-based tool that lets you upload a font, pick the weights and character sets you want, and download optimized files with ready-to-use @font-face CSS.
• Glyphhanger – A command-line tool that can scan your site’s HTML and generate a font file containing only the characters you use.

Then, you need to update your files. 
 

Optimize Your Fonts Automatically with NitroPack

What’s the point of building your website on WordPress and having access to thousands of plugins if you’re going to apply optimizations manually? 

It doesn’t make sense.

And you don’t have to. 

As I mentioned, NitroPack can handle font subsetting automatically, but that’s just one part of what it does. NitroPack includes several font-specific optimizations that work together to improve load times and visual stability, all without requiring manual changes to your theme or CSS.

Here’s what NitroPack can do for you with just a click of a button:

• Font Subsetting – Automatically strips unused characters from font files, keeping only the glyphs used on your site. This reduces font size and speeds up rendering, especially on multilingual pages or sites using large font families.
   
• Font Compression – Serves font files in modern formats like WOFF2, which are much smaller than older alternatives. Smaller files mean faster downloads and less strain on mobile networks.
   
• Font Loading Strategy – Lets you control how and when fonts are loaded. You can choose to preload critical fonts early, defer non-essential ones, or let NitroPack determine the optimal loading order to improve Core Web Vitals and First Contentful Paint (FCP).

• Font Display Control – Gives you the option to override the default font-display behavior without editing your CSS. You can choose between values like swap, fallback, optional, block or auto to prevent invisible text and improve perceived performance.
   
• Google Fonts Optimization – NitroPack can automatically download, compress, and serve Google Fonts from its own CDN. This reduces reliance on external requests and improves caching efficiency.
   
• Disable Text Flashing – Helps eliminate flashes of unstyled or invisible text during font swaps by optimizing how fonts are introduced in the render process.

All of this is handled automatically. 

No manual subsetting, no editing link tags, and no guesswork. 

Optimize your Google Fonts and performance without lifting a finger. Get NitroPack now →

FAQs

Can I use Google Fonts without slowing down my site at all?

Not entirely — even though Google Fonts is well-optimized, any external resource can introduce some delay. But with proper optimization (like limiting weights, using font-display: swap, and preconnect), the impact can be minimized to almost nothing.

Is it better to use system fonts instead of Google Fonts?

System fonts offer the best performance because they’re already installed on the user’s device, meaning no downloads. But they come at the cost of design flexibility and brand consistency.

Are variable fonts better for performance than loading multiple static weights?

Yes, often. A single variable font file can replace multiple static files (e.g., 400, 500, 700), reducing the number of requests. But they can be larger in file size if you don’t subset them carefully.

What happens if I don’t set font-display at all?

The browser uses the default, which often hides text until the font loads (FOIT). This can delay content visibility and hurt perceived performance.

Do I need to worry about font licensing when self-hosting Google Fonts?

No — Google Fonts are open source and free to use and self-host. Just make sure you’re actually pulling them from fonts.google.com and not a third-party source with different terms.

Which performance metrics are affected by Google Fonts?

Mostly rendering-related metrics:

• FCP (First Contentful Paint) – Measures when the browser first renders any text or visual content. If font files delay text rendering, FCP is pushed back.
• LCP (Largest Contentful Paint) – Tracks when the largest visible element (like a heading or hero text) appears. If that element uses a web font that loads slowly, LCP is delayed.
• CLS (Cumulative Layout Shift) – Measures unexpected movement of content. If a fallback font loads first and is later swapped by a web font with different sizing, it can cause layout shifts.
• TBT (Total Blocking Time) – Captures time the main thread is blocked by long tasks. If fonts are render-blocking or handled inefficiently, they can contribute to longer blocking times.