How to Preload Fonts in WordPress to Reduce CLS and Improve LCP

Is your WordPress site failing Core Web Vitals checks despite having optimized images and minified code?

In some cases, slow typography loading can delay Largest Contentful Paint and cause visual instability known as Cumulative Layout Shift – but only when fonts are part of the critical rendering path.

In this guide, you will learn exactly how to preload fonts in WordPress to remove render-blocking delays and make your text appear instantly.

We will walk you through identifying the correct font files, adding the precise code snippets to your theme, and avoiding common mistakes that can actually slow your site down.

When This Guide Will Not Help

This guide will not improve your Core Web Vitals if your Largest Contentful Paint element is an image, background video, or slider. In those cases, font loading is not the bottleneck, and preloading fonts will have little or no measurable impact.

Before continuing, confirm that text (such as an H1 or hero heading) is identified as the LCP element in PageSpeed Insights or Lighthouse.

If fonts are not flagged under “Preload key requests”, this guide is not the correct fix.

Why Font Loading Causes CLS and LCP Issues in WordPress

Fonts are often the “heaviest” assets on a page after images, but browsers handle them differently than other files. In WordPress, themes frequently enqueue fonts via external requests (such as Google Fonts) or bury them deep within CSS files. This creates a “chain of delays” where the browser downloads the HTML, then the CSS, and only then realizes it needs to download a font file.

This delay exposes your site to slow server responses. If your hosting environment has a high Time to First Byte (TTFB), the browser waits even longer before starting the font download. 

How Late Font Loading Triggers Layout Shift 

Cumulative Layout Shift (CLS) occurs when elements on a page unexpectedly move. It happens in three parts:

• When a browser loads a page, it may initially display a “system font” (like Arial) while the custom font is downloading. System fonts and custom fonts rarely have identical character widths.
• Once the custom font finishes downloading, the browser swaps it in. If the new font is wider or taller, the text block expands, pushing buttons, images, and other content down the page. This movement penalizes your CLS score.
• If your server is slow to deliver the font file due to poor caching or lack of compression, the user sees the system font for longer, making the eventual shift more noticeable and jarring.

Suggested read: How to Make Fewer HTTP Requests on WordPress & Speed Up Your Site

How Font Discovery Delays Render and Impacts LCP

Largest Contentful Paint (LCP) measures how long it takes for the main content to become visible. Font preloading only helps when that element is text, such as an H1 or hero heading. If the LCP element is an image or background asset, preloading fonts will not improve this metric.

This happens in the following manner:

• Browsers are lazy by design; they won’t download a font until they build the “Render Tree” and confirm the font is actually used on the page. This means the browser parses HTML, downloads CSS, parses CSS, and then requests the font.
• Many modern browsers will hide text completely until the font file is ready. If your H1 headline is waiting on a font, the screen stays blank. Since the H1 is often the LCP element, your LCP time increases by the exact amount of time it takes the font to download.

Suggested read: How to Easily Fix Leverage Browser Caching Warning in WordPress

When Preloading Fonts Helps vs. When It Makes Things Worse

Preloading is a manual override that forces the browser to download the font immediately, skipping the “discovery chain.” However, it is a double-edged sword.

• When it Helps: Preloading is excellent for the single primary font used in your LCP element (e.g., the H1 font). It ensures the text appears instantly, stabilizing LCP.
• When it Hurts: If you preload too many files (e.g., body text, bold versions, icon fonts), you create network congestion. The browser has limited bandwidth; if it is busy downloading 5 font files, it cannot download your hero image or critical CSS. This actually worsens your page speed.

Suggested read: How To Use NGINX FastCGI Cache (RunCache) To Speed Up Your WordPress Performance

How to Preload Fonts in WordPress (Step-by-Step)

Preloading fonts is a powerful way to tell browsers to prioritize typography assets and improve Core Web Vitals. However, frontend optimizations like this work best when backed by a high-performance server environment.

Before you begin, remember that modifying site headers requires precise caching management. RunCloud’s server-level caching keeps your site fast, but you must clear the cache after applying these changes so visitors see the improvements immediately.

Step 1: Confirm Fonts Are The Problem in PageSpeed Insights and Lighthouse

Before adding code, verify that fonts are actually delaying your render time. Run a test on PageSpeed Insights or Google Lighthouse and look at the “Opportunities” section. If you see a warning labeled “Preload key requests,” expanding it will usually list specific font files that are delaying rendering.

If your fonts are not listed under “Preload key requests”, stop here. Font preloading will not improve your results; focus on server response time, image optimization, or render-blocking scripts instead.

At that point, ensure you are utilizing RunCloud’s optimized NGINX/Apache configurations.

RunCloud helps reduce Time to First Byte (TTFB) so that when the browser finally requests the font, the server delivers it instantly without lag.

Preloading changes the order in which files load, but it does not make the files smaller or the server faster.

Step 2: Identify the Exact Font File Used Above the Fold in DevTools

You should never preload every font on your site, only the ones used immediately on the screen (above the fold). To find these, open your website in Chrome, right-click, and select Inspect to open DevTools. Navigate to the Network tab, reload the page, and click the Font filter. Look for the font files that load first and are critical for your main headings or navigation.

Hover over the file name to see the full URL. You are specifically looking for .woff2 files, as these are the modern standard for compression and performance. Copy the URL of the font file you want to preload. 

Step 3: Add The Preload Tag 

Once you have the URL, you need to construct the HTML tag. The syntax for this HTML tag must be correct, or the browser will ignore it. The tag should look like this:

<link rel="preload" href="/fonts/your-font-file.woff2" as="font" type="font/woff2" crossorigin>

In the above tag, replace /fonts/your-font-file.woff2 with the path of the font that you noted down earlier. In addition to the path, make sure you include the crossorigin attribute. Even if the font is hosted on your own domain, the browser fetches it in anonymous mode. If you omit crossorigin, the browser may treat it as a different file request. 

Suggested read: NGINX Caching for WordPress – Complete Guide & Tutorial

There are two ways to add this tag to your WordPress site. The first method requires editing your header.php file in a child theme and pasting the line between the <head> tags. 

The second approach is safer and more manageable. It requires adding a code snippet to your functions.php file, using the wp_head hook, to dynamically inject the link.

Here is the code snippet to add a tag to your site header using the functions.php file and the wp_head hook. You should add this code to your child theme’s functions.php file or use a code snippet plugin.

function add_custom_code_to_head() {
    ?>
<link rel="preload" href="/fonts/your-font-file.woff2" as="font" type="font/woff2" crossorigin>
    <?php
}
add_action( 'wp_head', 'add_custom_code_to_head' );

If you prefer not to use a plugin, you must access the functions.php file through your hosting provider, as the WordPress dashboard for Block Themes often does not allow this.

1. Log in to your RunCloud dashboard and open the File Manager.
2. Navigate to the folder wp-content/themes/your-active-theme-name/.
3. Locate the functions.php file, then click it to edit it.
4. Paste the code at the bottom of the file and save.

After saving the file, it will automatically be included in the HTML head of your WordPress site. You can verify it by opening the devtools and searching for the tag that you noted in the previous step.

Warning: After adding this code, you might notice that the changes appear when you are logged in but not when you inspect the site as a visitor. This happens because the server page cache is serving old HTML. Instead of hoping a browser cache clear fixes it, go to your RunCloud dashboard and purge the RunCloud server cache. This ensures the new preloading headers are served to all users immediately.

Step 5: If using Google Fonts, add Required Preconnect Hints

If you are not self-hosting fonts and rely on Google Fonts, true font preloading is not possible because the file URLs change dynamically.

In this case, preconnect is only a partial mitigation, not an equivalent replacement for preloading. It helps reduce connection setup time, but it does not remove third-party latency entirely.

Add these lines to your header:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

While this helps, reliance on external servers introduces latency you cannot control. A better long-term strategy for performance is using RunCloud’s Redis full-page caching. By efficiently caching the rest of your database content on your own server, you give the browser more time to handle external third-party connections without affecting the user’s perceived load speed.

Suggested read: How to Create Custom NGINX Configuration Easily Using RunCloud

Step 6: Fix Common Mistakes 

After implementing the above steps, watch out for “double downloads” in your Waterfall chart, where the font loads once as a preload and again via CSS. This is almost always a cross-origin mismatch.

Another common issue is CORS errors, where the font refuses to load entirely. This is frequently a server configuration issue regarding Access-Control-Allow-Origin headers.

If you see “Cache TTL” warnings, you can fix them by using the RunCache plugin for WordPress. It uses intelligent caching rules to speed up a WordPress website without requiring code changes. If purging cache to fix these errors causes load spikes, use RunCloud’s monitoring to correlate the purges with CPU pressure and adjust your settings accordingly.

Step 7: Re-test and Verify Improvements 

Finally, return to PageSpeed Insights and WebPageTest. Look for the specific metrics: Largest Contentful Paint (LCP) should be faster, and Cumulative Layout Shift (CLS) should decrease because the text renders immediately rather than swapping fonts later.

If you still see inconsistent results where some visitors get fast speeds and others don’t, your edge caching or object caching might be fragmented.

This is where RunCache shines.

RunCache combines page, object, and edge caching into one dashboard with auto-purging logic. If you are tired of manually debugging caching layers, create a test site to experience RunCache and see how a unified caching strategy stabilizes your font loading and overall performance.

Suggested read: How To Use Redis Full-Page Caching To Speed Up WordPress

Troubleshooting: What if Preloading Doesn’t Improve CLS or LCP?

If you have implemented preloading tags but your Largest Contentful Paint and Cumulative Layout Shift scores haven’t changed, the issue is likely related to the total weight of your page or server response times.

Minimize Font Variants to Reduce File Size and Load Time

One of the most common reasons for slow LCP is loading too many font weights and styles (e.g., loading Light, Regular, Semi-Bold, Bold, and Extra Bold in both italics and normal). Each variation is a separate file that the browser must download, and preloading five or six files will clog your network bandwidth, blocking other critical assets like your logo or hero image.

• Audit your typography: Check your CSS to see which weights are actually being used on the site.
• Remove unused variants: If your specific theme only uses “Regular (400)” and “Bold (700),” remove all other weights from your request.
• Update the preload tags: Ensure you preload only the single most important variant (usually the body text or main heading weight), not the entire family.

Implement ‘font-display’ Strategies to Prevent Layout Shifts

If your LCP is good but your CLS is poor, it is likely because the text is “swapping” and changing size after the font loads. You can control this behavior using the font-display property in your CSS @font-face declaration.

• Use font-display: swap: This tells the browser to display a fallback system font immediately (improving LCP) and swap to your custom font once it downloads. This prevents the “invisible text” phenomenon.
• Use font-display: optional: For maximum speed, this setting tells the browser to use the custom font only if it is already cached or loads instantly. If it takes too long, the browser sticks with the system font for that page view, resulting in zero layout shift.

Suggested read: Cloudflare DNS for RunCloud (Security & Performance)

Self-Host Fonts to Eliminate Third-Party Latency

Relying on Google Fonts or Adobe Fonts introduces external variables you cannot control, such as DNS lookups and connection latency to their servers. If their server is slow, your site is slow. Self-hosting the font files (uploading them to your own /wp-content/uploads/ folder) places the control back in your hands.

When you self-host, you benefit directly from RunCloud’s high-performance NGINX/Apache configurations. RunCloud ensures that static assets hosted on your server are served with optimized compression standards. By removing the external “round trip” to Google’s servers, you stabilize your LCP scores and ensure consistent site performance regardless of external network conditions.

Wrapping Up

While preloading fonts can improve perceived load speed when fonts are the bottleneck, it is only one part of a broader performance strategy.

If fonts are not delaying your render path, preloading will not change your Core Web Vitals scores.

RunCloud helps you manage server-level caching, including Redis and optimized NGINX configurations, ensuring your site loads instantly even if a user has a stale browser cache.

RunCache is a completely free, vendor-independent caching solution that works on any hosting provider. It lets you unify page, object, and edge caching without migrating your site or changing hosts.

If font preloading alone does not stabilize your Core Web Vitals, RunCache gives you a practical next step without committing to new infrastructure.

Create a test site to experience RunCache.

FAQs on Preloading Fonts in WordPress