WordPress Preload Fonts, Preconnect and Resource Hints
WordPress preload fonts by adding a preload hint for the one woff2 file the page needs early, then preconnect to the origins that serve your LCP image and CSS. Resource hints (preconnect, dns-prefetch, preload, prefetch) tell the browser what to fetch early, but they only help when you use a handful, not dozens.
WordPress preload fonts by adding a preload hint for the one woff2 file the page needs early, then preconnect to the origins that serve your LCP image and CSS. Resource hints (preconnect, dns-prefetch, preload, prefetch) tell the browser what to fetch early, but they only help when you use a handful, not dozens. If I were checking this on a real site, I'd start with the page that earns traffic or money, confirm whether the issue is backend, frontend, content, or layout related, then apply one fix at a time.
What are preconnect and preload resource hints in WordPress?
Resource hints are small <link> tags in your page <head> that tell the browser to do network work early, before the HTML parser would naturally reach the asset. The four you'll meet on WordPress are preconnect, dns-prefetch, preload, and prefetch, and each does a different job. Preconnect and dns-prefetch warm up a connection to a third-party origin, while preload tells the browser to actually download a specific file at high priority right now.
Here's the mental model I use on every audit. dns-prefetch just resolves a domain name to an IP. preconnect goes further and finishes the DNS lookup, TCP handshake, and TLS negotiation, so the file request that follows skips three slow round trips. preload fetches one known file (a font, the LCP image, a critical stylesheet) ahead of when the browser would discover it. prefetch grabs a low-priority asset for the next page, not this one.
PageSpeed Insights surfaces two audits tied to these hints: "Preconnect to required origins" and "Preload key requests." Both are nudges, not bugs, and you fix them with three or four lines of HTML once you know which origins and files matter. If you want the bigger picture on how these feed your scores, my WordPress Core Web Vitals guide shows where each hint moves the needle.
Why do resource hints speed up a WordPress page?
Resource hints speed up a page because they remove waiting from the front of the critical path, where every saved millisecond counts toward Largest Contentful Paint. When your hero image lives on a CDN and your font comes from a separate origin, the browser normally discovers those late, then pays for DNS, TCP, and TLS before a single byte arrives. A preconnect spends that connection cost in parallel with HTML parsing instead of after it.
The numbers are real, not theoretical. A preconnect to a busy third-party origin can shave hundreds of milliseconds, and on high-latency mobile connections I've watched it claw back closer to a full second on the waterfall. A correctly placed font preload often pulls First Contentful Paint and LCP forward by 200 to 400ms because text stops waiting on a late-discovered woff2 file.
That said, hints don't make slow assets fast. They only change when the browser starts. If your font file is 300KB or your hero image is an unoptimized 2MB PNG, fix the asset first. Preloading a bloated image just makes the bloat arrive sooner. Pair these hints with proper WordPress image optimization so you're preloading something that's actually small.
How do you preload fonts in WordPress the right way?
You preload a font in WordPress by adding one <link rel="preload"> tag for the single most critical woff2 file, with the as="font", type="font/woff2", and crossorigin attributes all present. The tag looks like this:
<link rel="preload" href="/wp-content/themes/yourtheme/fonts/inter-regular.woff2" as="font" type="font/woff2" crossorigin>
The crossorigin attribute is the one everyone forgets, and leaving it off is the costliest mistake here. Fonts are always fetched in CORS mode, so a preload without crossorigin doesn't match the real request. The browser downloads the font twice, wastes bandwidth, and delays your text instead of speeding it up. Always include it, even for fonts hosted on your own domain.
Preload only the one or two fonts that render above the fold, almost always a single regular weight, and only the woff2 format (woff2 covers every modern browser). Don't preload bold, italic, and three icon sets too. If you self-host through OMGF and want the full font workflow, my WordPress font optimization guide covers swapping in font-display: swap and subsetting so the file you preload is as small as it can be.
How do you preconnect to required origins without breaking things?
You preconnect to required origins by adding a <link rel="preconnect"> tag for each critical third-party domain the page needs in its first second, and capping the list at two or three. The PSI audit lists the origins it thinks you should warm up, but treat that list as a starting point, not a checklist to complete in full.
Pick origins by what's on the critical path: the CDN that serves your LCP image, fonts.gstatic.com if you still pull Google Fonts, and maybe one analytics or video host if it loads early. A Google Fonts preconnect needs crossorigin because fonts.gstatic.com serves the font binaries in CORS mode, like this: <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>.
Preconnect is expensive on purpose, since it opens a real socket and runs the TLS handshake. Open too many and you contend for bandwidth and CPU on exactly the devices you're trying to help. Google's own guidance is to keep it to a handful, and a connection that isn't used within roughly 10 seconds gets dropped, so that preconnect was pure waste. For low-priority domains you might touch later, use dns-prefetch instead, which is cheap enough to use more freely. If your stack runs through Cloudflare, my Cloudflare WordPress speed guide shows which origins are already warmed at the edge so you don't double up.
What does the PSI preload key requests audit want?
The "Preload key requests" audit flags files that get discovered late in the load but are needed early, usually a font referenced deep inside a CSS file or the LCP image set by inline CSS. The browser can't see those until it parses the CSS, so PSI suggests preloading them to pull the request forward in the waterfall.
The honest move here is to be picky. Open the PSI request chain or a GTmetrix waterfall, find the one or two assets that sit on the critical path and arrive late, and preload only those. The usual winners are the above-the-fold font and the LCP image. For the LCP image specifically, add fetchpriority="high" on the preload so it jumps ahead of other downloads.
Don't preload your way down the entire chain. Preload everything and you flood the connection, starve the genuinely critical files, and push Total Blocking Time up. I treat two preloads as a soft ceiling on most pages: the font and the LCP image. If you're chasing the LCP score itself, my WordPress LCP optimization guide walks through finding the exact LCP element before you preload anything.
How do you add preconnect and preload with WP Rocket, Perfmatters, or your theme?
You add resource hints three ways: a performance plugin that exposes fields for them, a small code snippet hooked into wp_head, or by editing your theme's header. Most site owners should use a plugin, because it survives theme updates and handles the crossorigin attribute for you.
WP Rocket: open the File Optimization and Preload tabs. It auto-preconnects fonts.gstatic.com when you use Google Fonts, lets you preload fonts under the Media or Fonts section, and gives you a "Prefetch DNS Requests" box for dns-prefetch origins. My WP Rocket settings guide shows the exact toggles in order.
Perfmatters: go to Options then Preloading. Add the font or image URL, pick the as type, set priority to "high" for an LCP image, and target device or location if needed. Preconnect lives under Extras then Preconnect. LiteSpeed Cache handles Google Fonts preconnect automatically and exposes preload under its optimization tab, which I cover in the LiteSpeed Cache settings guide.
Theme or snippet: if you'd rather not add a plugin, drop the <link> tags into a function hooked to wp_head with priority 1 so they land near the top of the head. Editing header.php directly works too, but use a child theme so an update doesn't wipe it.
Preconnect vs dns-prefetch: which should you use?
Use preconnect for the two or three origins that are definitely on the critical path in the first second, and dns-prefetch for everything else that's likely but not certain. Preconnect does the full DNS plus TCP plus TLS warm-up, which is powerful but costly. dns-prefetch only resolves the domain name, so it's cheap enough to list five or six origins without hurting anything.
A clean pattern that passes both PSI audits looks like this: preconnect (with crossorigin where needed) to your font origin and CDN, then dns-prefetch the rest, like analytics, a chat widget, or an embedded video host. Browsers that don't support preconnect quietly ignore it, so there's no harm in pairing a preconnect and a dns-prefetch for the same origin as a fallback.
If you self-host fonts and serve images from your own domain, you may not need preconnect at all, since there's no third-party connection to warm. That's often the fastest setup. Hosting locally removes the round trip entirely instead of just starting it earlier, which is why I reach for local hosting before I reach for a preconnect tag.
What are the most common preconnect and preload mistakes?
The mistakes are nearly always over-use or a missing attribute. The five I find most on client audits are worth memorizing before you touch a single tag.
- Preconnecting to too many origins. Five or six preconnects contend for bandwidth and slow the page. Cap it at two or three and demote the rest to dns-prefetch.
- Preloading non-critical assets. A preloaded footer script or a below-the-fold image steals priority from the LCP image and raises Total Blocking Time.
- Forgetting
crossoriginon a font. The font downloads twice and the preload is wasted. Always add it to font preloads and Google Fonts preconnects. - Preloading a font the page doesn't use early, like a bold weight that only appears below the fold. You're paying to download something the user can't see yet.
- Letting a plugin and your theme both add the same hint, which creates duplicate tags and console warnings. Pick one source of truth.
There's also the silent failure of a preconnect to an origin you've delayed with JavaScript deferral. You warm a connection the page never uses inside the 10-second window, the browser drops it, and you've spent the cost for nothing. If you delay third-party scripts, don't preconnect their origins.
How do you measure whether your hints actually helped?
You measure resource hints with a before-and-after waterfall, because that's the only place you can see a connection start earlier or a file move forward. Run the page through PageSpeed Insights or a GTmetrix waterfall, note the start time of your font and LCP image requests, add the hints, then re-test and compare those same rows.
Watch three things specifically: did the "Preconnect to required origins" and "Preload key requests" audits clear, did LCP drop, and did Total Blocking Time stay flat or improve. If TBT jumped after you added preloads, you preloaded too much, so cut back to the font and LCP image only. Use Lighthouse v8 or newer rather than older GTmetrix scoring, since the audit logic changed.
Always test on a throttled mobile profile, not just desktop, because hints help most exactly where the network is slow. If you'd rather have the analysis done for you with a prioritized fix list, you can run my free WordPress site audit and it'll flag which origins and files are worth a hint.
When should you hand resource hints to a specialist?
Hand it off when the PSI audits keep coming back after two honest attempts, when a plugin update keeps re-adding hints you removed, or when adding a preconnect somehow made LCP worse and you can't see why on the waterfall. Resource hints sit at the intersection of your theme, your cache plugin, your CDN, and your fonts, and conflicts between those four are where most people get stuck.
These hints are also rarely the whole story. If your page is slow because of a heavy theme, render-blocking CSS, or a bloated DOM, no amount of preconnecting fixes that. A specialist looks at the full critical path and decides whether a hint helps or whether the real win is removing an asset entirely.
If you'd rather skip the trial and error, that's exactly what I do day to day. My WordPress page speed optimization service handles resource hints, fonts, images, and Core Web Vitals as one job, and I tune the hints against your real waterfall instead of guessing. You get a faster page and the PSI audits cleared without breaking anything else.
My checklist for WordPress Preconnect and Preload
which third-party origins the page connects to
whether the LCP image or main font is preloaded
whether preconnect is used sparingly