Your homepage looks perfect on your laptop — then PageSpeed Insights flags it: “Preload key requests”, with your fonts listed as the culprit. The text your visitors read first is the very thing holding your page back.
Learning how to preload fonts in WordPress takes about 15 minutes and can shave a visible chunk off your Largest Contentful Paint (LCP) — the Core Web Vital measuring how fast your main content appears. Below: the complete WordPress preload key requests fix — copy-paste code, self-hosting, and the mistakes to avoid.
Key takeaway: preload only the one or two fonts your visitors see above the fold — preload everything and your site gets slower, not faster.
Why Fonts Slow Down Your WordPress Site
Fonts are sneaky performance killers. Unlike an image, which the browser downloads the moment it sees it, a font file hides behind your CSS — the browser must download the stylesheet, parse it, find the @font-face rule, and only then request the font. That chain of delays is exactly what “Preload key requests” flags.
It gets worse when your largest content element — the LCP element — is text. On most blogs the hero headline is the LCP element, so a late font means a late headline and a worse LCP score. Google’s web.dev guide on optimizing web fonts says fonts hurt performance at both load time and rendering time.
Step 1: Confirm Fonts Are the Problem in PageSpeed Insights
Measure first — preloading only helps when fonts are the bottleneck:
- Run your URL through PageSpeed Insights and open the mobile results.
- Look for “Preload key requests.” If your
.woff2files are listed, fonts are delaying your page. - Check the Largest Contentful Paint element — if it’s a text node (usually your H1), fonts are directly hurting your score.
No warnings? Your fonts are fine — see our pillar guide on how to speed up your WordPress site in 2026 instead.
Step 2: Find the Exact .woff2 File in Chrome DevTools
- In Chrome, press F12, open the Network tab, reload the page, and click the Font filter.
- Note the fonts that load first — your heading font (often weight 700) and body font (weight 400).
- Click a font file and copy its full URL — including the exact filename, like
poppins-latin-700-normal.woff2.
Why this step matters: the preload URL must match your @font-face URL exactly. One character off and the browser downloads the font twice. This is the single most common preloading mistake.
Real-world example: a food blog’s hero headline “30-Minute Dinners” renders in Poppins Bold. PageSpeed flags its Poppins 700 .woff2 file; the owner preloads just that one file, and the headline appears with the rest of the hero.
Step 3: How to Preload Fonts in WordPress Without a Plugin
To preload fonts in WordPress without a plugin, add a small snippet to your child theme’s functions.php, hooked into wp_head. Never edit your parent theme directly.
Add this code, swapping in your Step 2 URL:
function techcoff_preload_fonts() {
echo '<link rel="preload" href="https://techcoff.com/wp-content/uploads/fonts/poppins-latin-700-normal.woff2" as="font" type="font/woff2" crossorigin>';
}
add_action( 'wp_head', 'techcoff_preload_fonts', 1 );
Every attribute earns its place:
rel="preload"— tells the browser to download this file immediately, at high priority.as="font"— tells the browser the file type, so it can prioritize correctly.type="font/woff2"— narrows the preload to WOFF2 — about 30% better compression than WOFF. Web.dev recommends WOFF2 only.crossorigin— non-negotiable: fonts are always fetched in CORS mode, even from your own domain — without it, the browser downloads the font twice.
How many? One or two — your heading font and body font, and only if both appear above the fold.
Clear your cache and re-run PageSpeed Insights — the warning should be gone. Fighting render-blocking CSS too? See how to fix render-blocking resources in WordPress.
Step 4: Self-Host Google Fonts in WordPress
Preloading helps, but fonts from Google’s servers still cost extra DNS lookups and a third-party connection on every visit. Self-hosting Google Fonts in WordPress removes that round trip — the best way to preload Google Fonts in WordPress is to self-host them first.
Option A: the OMGF plugin (easiest). OMGF is the original Google Fonts self-hosting plugin, trusted by over 300,000 WordPress sites. It detects your theme’s Google Fonts, downloads them to your server, and points requests locally — and it can force font-display: swap.
Option B: Elementor’s built-in local fonts. Check Elementor → Settings → Performance → Load Google Fonts Locally — since Elementor 3.27, the builder can serve your Google Fonts from your server. Caution: since version 3.32.1 the default is Disabled — switch it on. Elementor downloads all variants of a family, so remove unused weights afterward.
Option C: manual self-hosting. Download the WOFF2 files, upload them to /wp-content/uploads/fonts/, and write your own @font-face rules with font-display: swap. More work, full control.
Either way: self-host first, then preload only the one or two above-the-fold files.
Step 5: Add font-display: swap So Text Never Goes Invisible
Preloading gets the font there faster. font-display: swap makes sure visitors can read your text while they wait — without it, browsers hide text until the web font arrives.
With font-display: swap in WordPress, the browser shows your fallback font (like Arial) immediately, then swaps in your web font when it downloads. Readers start reading at once.
To set font-display swap WordPress-wide: Google Fonts users add &display=swap to the stylesheet URL; self-hosted fonts add font-display: swap; to each @font-face rule; OMGF users enable it in settings.
One trade-off: if your fallback and web font differ a lot in width, the swap can shift your layout, hurting Cumulative Layout Shift (CLS) — Google’s target is 0.1 or less. Pick a similar-proportioned fallback and the shift becomes invisible. If stability matters more, font-display: optional is stricter.
Preload vs Preconnect vs font-display: swap — What’s the Difference?
These three get confused constantly — most fast sites use all three:
| Technique | What it does | When to use it |
|---|---|---|
| Preload | Downloads one font file immediately, at high priority | 1–2 above-the-fold fonts |
| Preconnect | Opens an early connection to Google’s servers | External Google Fonts only |
| font-display: swap | Shows fallback text instantly, swaps web font in when ready | Every @font-face rule, always |
Not self-hosted yet? Add these near the top of your <head>:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Once you self-host, drop preconnect entirely.
How to Preload Fonts in WordPress — When NOT to Bother
Don’t preload when:
- The font appears below the fold. A footer-only font gains nothing from an early download.
- You’d need to preload more than two files. Four families above the fold means you need a simpler font stack, not more preloads.
- Your LCP element isn’t text. If it’s a hero image, preloading fonts won’t move your score — fix the image with our guide on reducing image size without losing quality in WordPress.
- The URL doesn’t match exactly. One wrong character triggers a double download — verify it in DevTools (Step 2) first.
The honest summary: preloading is a scalpel, not a hammer.
FAQ
Should I preload Google Fonts?
Yes — but only the one or two Google Fonts that render above the fold, and ideally after self-hosting them. A Google-hosted preload still helps, but the full benefit comes when the font lives on your own server.
How many fonts should I preload?
One or two, maximum. Preload diverts browser resources from other critical assets, so reserve it for the fonts your first screen genuinely needs. Preloading three or more usually slows the page down.
What is font-display: swap?
font-display: swap is a CSS instruction inside an @font-face rule: show text immediately in a fallback font, then swap in the web font once it downloads. It kills the flash of invisible text browsers cause while waiting for a font.
Does preloading fonts improve LCP?
Yes, when fonts are the reason your LCP is slow. If your largest content element is text — usually your H1 — and PageSpeed Insights flags your fonts under “Preload key requests,” preloading that headline’s font cuts a meaningful delay. If it’s an image or video, preloading fonts won’t help — optimize the image instead.
The Takeaway
Fonts should be invisible to your visitors — they should just read. When a font file holds your headline hostage, one preload tag, a font-display: swap rule, and a self-hosted WOFF2 file set it free. That’s how to preload fonts in WordPress the right way.
Rather have a professional handle the whole speed audit? See our WordPress speed optimization services or get in touch.
