Why Your WordPress Site Downloads Fonts It Never Renders (and How to Fix It)

Short answer: a WordPress theme will happily download every font family and weight named in its wp_enqueue_style Google Fonts request — even the ones that never paint a single character. On this site that was three families and seventeen weight files (594 KB), when only one family ever rendered. Trimming the request to the five weights actually used cut it to 133 KB — a 460 KB saving on every page load.

What you’ll learn

• Why a font listed in your CSS font-family stack does not need to be downloaded
• How to prove which font weights your CSS actually uses (two grep commands)
• How to load right-to-left/Arabic fonts only when they’re needed
• Why this is a bandwidth win, not necessarily a Largest Contentful Paint win — and how to tell the difference

This is based on a real change I made to this site’s theme on 1 August 2026, verified against the live font requests. No secrets or private details are involved — Google Fonts URLs are public.

The symptom

Every page on this site was requesting Google Fonts like this from the theme’s enqueue file:

// inc/enqueue.php — before
wp_enqueue_style(
  'mca-google-fonts',
  'https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@300;400;500;600;700;800'
  .'&family=Inter:wght@300;400;500;600;700'
  .'&family=Cairo:wght@300;400;500;600;700;800&display=swap',
  [], null
);

Three families, all weights: Plus Jakarta Sans (six weights), Inter (five), and Cairo (six). That’s a stylesheet request that pulls seventeen separate woff2 files for the Latin subset alone. The problem is that only one of those families was ever drawn on screen.

What I found

Two things were quietly wasting bandwidth on every request.

1. A fallback font name is not a font you download

The theme’s font token looked like this:

--mca-font: 'Plus Jakarta Sans', 'Inter', -apple-system, sans-serif;

Inter is in there as a fallback name. Because Plus Jakarta Sans always loads first, the browser never falls through to Inter — and even if it did, it would use a locally installed copy before reaching for a download. Listing a family in your font-family stack does not oblige you to enqueue it from Google. We were downloading five weights of Inter that could never render a glyph.

2. The Arabic font was loading on English pages

Cairo is an Arabic typeface. A quick grep showed it appeared in exactly one place:

grep -rniE 'Cairo' assets/css/*.css
# rtl.css:  --mca-font: 'Cairo', 'Plus Jakarta Sans', ...

Cairo is only referenced inside rtl.css — the right-to-left stylesheet WordPress loads via is_rtl(). On an English (left-to-right) site it renders nothing, yet six weights of it were being downloaded on every page.

3. Confirming which weights are actually used

Before trimming, I checked which font-weight values the CSS actually asks for:

grep -ohiE 'font-weight: ?[0-9]{3}' assets/css/main.css assets/css/home-newsroom.css \
  | grep -oE '[0-9]{3}' | sort | uniq -c
#   2 400
#   2 500
#  30 600
#  65 700
#  30 800
#   1 900

So the design uses 400, 500, 600, 700 and 800. There was no 300 (light) anywhere, and the single 900 rule falls back harmlessly to 800 because Plus Jakarta Sans doesn’t ship a 900 weight. Five weights, one family — that’s the whole requirement.

The fix

Reduce the request to the one face that renders, and move the Arabic font behind the RTL check where it belongs:

// inc/enqueue.php — after
$mca_fonts_url = 'https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@400;500;600;700;800&display=swap';
if ( is_rtl() ) {
  $mca_fonts_url = 'https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:wght@400;500;600;700;800&family=Cairo:wght@400;500;600;700;800&display=swap';
}
wp_enqueue_style( 'mca-google-fonts', $mca_fonts_url, [], null );

Inter stays in the CSS font-family stack as a fallback name — it just isn’t downloaded any more. Cairo now loads only when the locale is actually right-to-left.

The measurement

To quantify it honestly I fetched the old and new Google Fonts CSS with a normal browser user-agent and summed the Content-Length of the Latin-subset woff2 files each one pulls — the subset an English page actually downloads:

	Font requests	Font transfer (Latin subset)
Before	17 files	594.0 KB
After	5 files	133.5 KB
Saved	−12 requests	−460.5 KB

460 KB is larger than many homepages’ entire image budget, gone from every single page load.

The honest part: this is a bandwidth win, not automatically an LCP win

It’s tempting to claim a Largest Contentful Paint improvement here, but I won’t, because the request used display=swap. With swap, text paints immediately in a fallback font and the web font is applied when it arrives — so fonts never block first paint, and they’re rarely the LCP element. On this homepage the LCP element is the eagerly-loaded featured image, not text. Cutting font weight doesn’t move that number directly.

Where it does help is the pipe: 460 KB of fonts no longer competes with your images for bandwidth, which matters most on slow or metered mobile connections, and it’s 460 KB less data for every visitor on every page. If your fonts render without display=swap, or your LCP element is a heading, the effect on LCP will be more direct — measure your own site with Lighthouse to see which case you’re in.

A reusable checklist

1. List what you enqueue. Open your theme’s Google Fonts request and write down every family and weight.
2. Grep for the weights you actually use: font-weight: ?[0-9]{3} across your CSS. Drop any weight that never appears.
3. Treat fallback names as free. A family in your font-family stack for graceful degradation does not need to be downloaded.
4. Gate RTL/CJK faces. Arabic, Hebrew or CJK fonts should load behind is_rtl() or the relevant locale check, not globally.
5. Verify on the live page. curl the page and confirm the font request now lists only what you meant to ship.

Takeaway

Font bloat hides in plain sight because the request “works” — the site looks right, so nobody checks. But a font-family stack is a list of fallbacks, not a shopping list of downloads, and a weight you never style is pure waste. Ten minutes with grep took this site from 594 KB of fonts per page to 133 KB, with no visible change at all.