How to Disable Google Fonts in WordPress and Speed Up Your Site
Most WordPress themes load Google Fonts by default. It happens quietly, in the background, and most site owners never question it. The problem is each font family adds an extra HTTP request, sometimes more than one, before the page even starts to render. On a slow connection that delay is visible. This post walks through exactly how to stop WordPress loading Google Fonts, what to replace them with, and when it genuinely moves the numbers.
On this page
Why Google Fonts Affect Load Time
Every time a visitor lands on your site, the browser has to fetch those fonts from Google’s servers before it can finish rendering the page. That is an external HTTP request, and it adds a round-trip to the load sequence that your hosting has no control over. On a fast connection it might only cost a few hundred milliseconds, but those milliseconds sit inside your Largest Contentful Paint timing, which is one of the signals Google uses to score your Core Web Vitals. The font request also has to resolve a DNS lookup, open a connection, and wait for a response before the browser can move on.
The reason people assume this is fine is that Google’s CDN has a reputation for being quick. And it often is. The problem is that the browser treats the font stylesheet as render-blocking by default, meaning it will pause page construction until the stylesheet has loaded and the font files are confirmed. Add a slow network, a cold DNS cache, or a user on mobile data, and that pause becomes noticeable. Local hosting removes the external dependency entirely. The font files live on the same server as everything else, the browser finds them without leaving your domain, and you cut one more variable out of the load chain. It is a small change, but small changes stack up.
Check Whether Your Site Is Actually Loading Them
Before you change anything, confirm the fonts are actually there. Open your site in Chrome, right-click anywhere on the page and choose Inspect, then go to the Network tab. Reload the page and filter by “Font” or just search for “fonts.googleapis.com” in the request list. If you see calls going out to Google’s servers, the fonts are loading. If you don’t, the job’s already done and you can move on. It sounds basic, but skipping this step means you could install a plugin, change settings, and fix a problem that never existed.
Google PageSpeed Insights gives you a second way to check without touching DevTools at all. Run your URL through it and look at the diagnostics section. A flag for “Eliminate render-blocking resources” that references fonts.googleapis.com tells you exactly what’s happening and where the delay sits in your load sequence. That context matters because the fixes that actually shift your Core Web Vitals scores are rarely the obvious ones, and Google Fonts is one of the more straightforward wins once you know it’s genuinely present. Start with evidence, not assumptions.
The Plugin Route: Disable Without Touching Code
If you’d rather not open a functions.php file, there are a handful of plugins that handle this cleanly. OMGF (Optimise My Google Fonts) is the one worth reaching for first. It scans your site, identifies every Google Fonts request, and lets you host those font files locally instead of pulling them from Google’s servers on each page load. That single change removes an external HTTP request and can shave a noticeable amount off your Largest Contentful Paint score. Asset CleanUp is another option, and it gives you granular control over which scripts and styles load on which pages, so you’re not disabling fonts site-wide if you only have a problem on specific templates.
The caveat worth knowing is that not every “speed” plugin does this job well. Some popular all-in-one optimisation plugins include a Google Fonts setting buried inside a larger bundle, and the overhead of the plugin itself costs more than the font request it saves. It’s worth being honest about that trade-off. If you only need to deal with fonts, a focused plugin like OMGF is tidier than installing something with forty features you’ll never use. More plugins almost always means more moving parts, and more moving parts means more to go wrong when WordPress updates.
The Code Route: Remove Google Fonts Properly via functions.php
If you’re comfortable working in a child theme, dequeuing Google Fonts directly in functions.php is the cleanest approach. Open your child theme’s functions.php file and add a function hooked to wp_enqueue_scripts with a priority of 100 or higher, which ensures it fires after your theme and plugins have registered their own font handles. Inside that function, call wp_dequeue_style() and wp_deregister_style() for each font handle you want to remove. A typical Twenty Twenty-style theme registers its fonts under a handle like twentytwenty-google-fonts, so that’s the string you’d pass in. Check the exact handle name by loading the page source and searching for fonts.googleapis.com to find what your theme actually registered.
One thing worth noting is that plugins can register their own separate Google Fonts calls independently of the theme, so removing the theme handle alone won’t always clear every request. You’ll often find Contact Form 7, WooCommerce add-ons, or page builder plugins quietly loading their own font stylesheets. Add a separate wp_dequeue_style() line for each offending handle, confirmed by inspecting the page source each time. A tool like a TTFB audit can then confirm whether those external requests have actually dropped from the waterfall, which is the only real proof that the dequeue worked.
What to Use Instead of Google Fonts
System fonts are the straightforward answer. Fonts like Georgia, Arial, and the newer system-ui stack are already on the visitor’s device, so the browser renders them instantly with no external request at all. A system font stack can look surprisingly clean on a modern site, and on most screens the difference between a system serif and a popular Google Font is genuinely hard to spot. For sites where readability and speed matter more than a distinctive typographic identity, that is usually the better trade-off.
Self-hosting is the right call when a specific typeface genuinely matters to the design. You download the font files, serve them from your own server, and remove the third-party dependency entirely. Performance-wise, a well-configured server with a low TTFB will deliver a self-hosted font quickly enough that the page speed penalty becomes very small. The honest caveat is that self-hosting takes a bit more setup, and if you skip the correct font-display settings in your CSS, you can still end up with layout shift or invisible text on slow connections. Do it properly or the gain is minimal.
How Much Difference Does It Actually Make
Disabling Google Fonts is a genuine improvement, but it sits in the middle of a much longer list of work. On its own, it might shave a few hundred milliseconds off your load time and remove one or two render-blocking requests that PageSpeed Insights flags. You will likely see small gains in First Contentful Paint and possibly Largest Contentful Paint, but the needle rarely moves far from this single change alone. Think of it as tidying one room in a house that still has damp walls and a leaking roof.
Where it does count is in a proper Core Web Vitals audit, where every marginal gain adds up. The sites that go from failing to passing Core Web Vitals almost always get there through a handful of these smaller fixes stacked together, not one dramatic intervention. If you are working through page speed fixes methodically, fonts are worth sorting early because they are quick to address and they clear the path for the heavier optimisation work ahead. Skip them and they will still be sitting in your report, nagging away, while you try to diagnose something more complicated further down the line.