How to Host Google Fonts Locally in WordPress

Every WordPress site that loads Google Fonts pulls font files from Google’s servers: two extra connections, a render-blocking stylesheet, and a small delay before text settles into place. Most site owners never notice, because it all happens in fractions of a second. But on a slow mobile connection those fractions stack up — extra DNS lookups, TLS handshakes, and a stylesheet that must arrive before the browser can paint text. Hosting the same fonts on your own server removes that chain entirely. Your fonts load from the domain the visitor is already connected to, and as a bonus you stop sending your visitors’ IP addresses to Google — which is precisely what a German court penalized a site owner for a few years ago. This guide walks you through three ways to do it: a plugin that handles everything automatically, the manual method for full control, and the one-click option hiding inside popular caching plugins.

Why Google Fonts Slow Down Your WordPress Site

When a font loads from Google’s servers, this is what happens on every first visit:

1. The browser requests fonts.googleapis.com (the stylesheet) — a new DNS lookup, a new TLS handshake, a new connection.
2. That stylesheet points to fonts.gstatic.com (the actual font files) — another DNS lookup, another handshake, another connection.
3. The .woff2 files finally download.

That is three network round trips before text rendering can fully settle — and the stylesheet in step 1 is render-blocking, meaning the browser waits for it before painting text (or briefly hides text, depending on font-display). On high-latency mobile connections, the DNS + TLS + download chain routinely costs a few hundred milliseconds on first visit, and it sits directly in the page’s render path. Preconnect hints soften it; removing the request removes it.

There is also a control problem. Because these are third-party requests, your cache rules do not apply to them — you cannot set cache headers on Google’s servers, and every new visitor has to fetch them fresh. Serve the fonts yourself and your own CDN or server cache policy applies to font files like any other static asset. For a refresher on how font CSS interacts with your other optimization choices, see our guide to eliminating render-blocking resources in WordPress.

Step 1 — Confirm Your Site Loads Google Fonts Remotely

Before changing anything, verify you actually need this fix:

• Open any page of your site, open DevTools (F12), go to the Network tab, reload the page, and filter by “font”. If you see requests to fonts.gstatic.com or fonts.googleapis.com, you are loading Google Fonts remotely.
• Right-click → View Page Source and search for fonts.googleapis.com. You will find a <link> tag, often injected by your theme or a page builder.

The usual sources: the theme customizer (Appearance → Customize → Typography), Elementor (Site Settings → Settings → Google Fonts), Divi, and various plugins. Write down which font families and weights your site actually uses — you will need that list in a moment. If you have not run a baseline performance test yet, our 15-minute WordPress speed diagnosis is a good place to start.

Step 2 — Choose Your Method

Method 1: Use a Plugin (Recommended for Most Sites)

The easiest reliable option is OMGF (Host Google Fonts Locally) — a free plugin that does the whole job: it scans your site for Google Fonts, downloads the files to your server, and rewrites the stylesheet links automatically.

1. Install and activate OMGF from Plugins → Add New.
2. Go to Settings → Optimize Google Fonts.
3. Run the optimization scan — the plugin finds every Google Font your site loads, including ones injected by themes and page builders.
4. The plugin downloads the font files into your uploads folder and replaces the external stylesheet with a local one.
5. Clear your page cache and CDN cache, then re-check the Network tab — there should be no more requests to Google.

Alternatives: Perfmatters has a “Local Google Fonts” option, and Autoptimize can inline the Google Fonts CSS. Any of them works — the principle is identical: fonts served from your own domain.

Method 2: Host the Fonts Manually (Full Control)

If you would rather not add another plugin, doing it by hand takes about half an hour:

1. Get the font files. The easiest route is google-webfonts-helper, a free site that lets you pick a family, its weights, and the character subsets you need, then download the .woff2 files along with ready-made CSS. Google now serves most families as variable fonts — one file covering a range of weights, smaller than a dozen separate static files. Grab the variable version when it is offered.
2. Download only what you use. If your design uses regular and bold, do not download nine weights. Fewer files means less CSS to parse and less to maintain. Include the latin subset at minimum; add latin-ext only if your content needs it.
3. Upload the files to a folder like /wp-content/uploads/fonts/ (or a /fonts/ folder in your child theme if you want them versioned with the theme).
4. Add @font-face rules to your stylesheet with font-display: swap, so text never goes invisible while the font loads:

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400 700;
  font-display: swap;
  src: url('/wp-content/uploads/fonts/inter-latin.woff2') format('woff2');
}

Adjust the weight range and file name to match what you downloaded.

5. Remove the old Google Fonts links. This is the step people forget — leave the <link> to fonts.googleapis.com in place and you will load the fonts twice. Check the theme customizer typography settings, Elementor/Divi settings (both have a “Disable Google Fonts” toggle), and consider a plugin like “Disable Google Fonts” that strips the request globally.
6. Clear all caches and verify in the Network tab that every font request now points to your own domain.

Method 3: Your Caching Plugin May Already Do It

Before installing anything new, check what you already own:

• LiteSpeed Cache → Page Optimization → CSS Settings includes a Google Fonts option that can load fonts asynchronously or remove the request.
• WP Rocket → File Optimization includes Google Fonts optimization handling.
• Perfmatters → Fonts section can disable Google Fonts and host local copies.

These options move around between versions, but the pattern is constant: your caching/optimization plugin is the first place to look, and a dedicated plugin is the second.

Step 3 — Preload Only the Fonts Above the Fold

Hosting locally removes the request chain, but the browser still does not know it needs your font file until the CSS arrives and parses. For the one or two font files that render your header and hero text, add a preload tag to your <head>:

<link rel="preload" href="/wp-content/uploads/fonts/inter-latin.woff2" as="font" type="font/woff2" crossorigin>

Only preload the files used for above-the-fold text — preloading every weight is a bandwidth tax that delays everything else. Our full walkthrough on how to preload fonts in WordPress covers exactly which files deserve the hint and which do not.

Step 4 — Verify the Win

1. Open an incognito window, open the DevTools Network tab, filter by “font” — every font request should point to your own domain, with zero requests to googleapis.com or gstatic.com.
2. View page source — no fonts.googleapis.com <link> tags anywhere.
3. Run PageSpeed before and after. Look for improvements in LCP (if text was the largest element waiting on the font chain) and a cleaner “reduce third-party code” audit. Keep expectations honest — this is usually a few hundred milliseconds, not seconds — but it is free, and it stacks with everything else.
4. Re-check after theme and plugin updates. Updates sometimes re-enable Google Fonts silently; a quick Network-tab glance after updating keeps it from creeping back.

The Privacy Bonus (and Why It Matters in the EU)

When fonts load from Google’s servers, every visitor’s IP address is transmitted to Google — and an IP address counts as personal data under GDPR. In 2022 a Munich court ruled that a site owner owed damages for exactly this practice. Hosting fonts locally removes the issue entirely: no third-party request, no data shared, no consent-banner debate about fonts. It is a side benefit rather than the main reason to do this — but it is a real one, and font-related layout shift problems disappear at the same time.

Common Mistakes to Avoid

• Forgetting to remove the old Google Fonts link — you end up loading the fonts twice, which is worse than where you started.
• Downloading every weight and subset “just in case” — keep only what your design actually uses.
• Preloading too many font files — preload is a priority signal; overuse it and it slows everything else down.
• Using TTF or EOT formats — .woff2 only. It is the only format modern browsers need, and it is the smallest.
• Skipping font-display: swap — without it, text stays invisible until the font arrives (FOIT), which reads worse than a brief flash of fallback text.

Google Fonts loaded remotely are a small but entirely unnecessary tax on every first visit. Host them locally — with a plugin in ten minutes or by hand in thirty — and you remove two origins from your critical path, tighten your privacy story, and shave a few hundred milliseconds off first paint. It is one of those rare optimizations with zero downside: the same fonts, the same design, delivered faster. Stack it with proper preloading, and fonts are a solved problem on your site.