Slow font loading makes text either “flash” or “stay blank for a long time” — hurting both the experience and the two core metrics LCP and CLS directly. How you set font-display, how you trim fonts, and how you preload them are all hard metrics tied directly to above-the-fold speed.
Many sites pull in a whole font family with dozens of weights, only to use two of them, and above-the-fold text gets stuck in the download queue. This article breaks down font-loading pitfalls and fixes one by one, so you can be fast and stable. For a more systematic look at frontend performance, see the technical SEO handbook.
Fonts are actually a frequently overlooked culprit behind LCP and CLS, because setting font-display wrong makes text invisible for a long time or suddenly reflow. The fix isn’t complicated: use font-display: swap so text shows with a fallback first and then swaps in, avoiding blank screens — be careful with block and auto; then trim unused weights, use woff2, and only include the character sets you need to shrink font size to the minimum; finally, preload the critical above-the-fold fonts. Do these three things and above-the-fold text basically won’t be held back by fonts anymore.
Why fonts slow pages down
When the browser meets an @font-face, it defaults to waiting for the font to download before showing text (FOIT); during that time text is invisible, sometimes a blank screen for seconds. Or it swaps in wholesale after download (FOUT), and text suddenly changes appearance, causing layout shift. Both hurt the experience and directly raise LCP and CLS.
More subtle: fonts are often critical blocking resources. When HTML reaches the CSS referencing a font, it must get the font before rendering text, stretching the critical rendering path. Quite a few small sites pull in the whole family plus a full multi-language set, exploding the size — pure waste of bandwidth and above-the-fold time, and rankings suffer along with it.
The four font-display values
font-display controls “how text shows when the font hasn’t finished downloading.” swap shows text with a system font first and swaps in when the font arrives — most user-friendly; fallback gives a very short invisible period; optional barely waits; block is a long blank screen, worst for both SEO and experience — try to avoid it.
The vast majority of sites should use swap. auto and block tend to create blank screens; don’t touch them without a strong reason. With swap, text appears instantly — even if the font arrives late, above-the-fold readability isn’t affected, LCP stays steadier, and users don’t bounce off a blank screen. Lower bounce rates give rankings something to stand on.
Shrink the font size
First trick: use woff2 format, over 20% smaller than ttf/woff. Second: only reference the weights you use (like 400 and 700), not the whole family. Third: subset — package only the characters that actually appear on the page; Chinese sites especially should cut out rarely-used glyphs to save a lot of size.
Chinese has many characters, so a full package easily runs several MB, and subsetting has the biggest payoff — generate a subset based on the characters used on the page, and the size can drop to a fraction. Size down, download speeds up, fonts stop being the LCP bottleneck, and above-the-fold text becomes nearly instantly visible. Same logic as crawl budget optimization: spend resources where they matter.
Preload critical fonts
For fonts required on the above-the-fold, use <link rel=”preload”> to download them early, avoiding being queued behind big resources like images. Pair preload with font-display: swap so the font arrives early and text isn’t blank — together they push above-the-fold text latency to the minimum, and the speed users perceive improves noticeably.
But don’t overuse preload — give it only to the one or two fonts that truly block the above-the-fold; too many just compete for bandwidth and crowd out other critical requests. It’s the same idea as preconnect/preload in resource hints: put critical resources first so the above-the-fold forms early, instead of letting fonts fall behind in the queue.
Common mistakes
Mistake one: using block/auto causes blank screens and LCP spikes. Mistake two: pulling in the whole family plus a full multi-language set, exploding the size. Mistake three: preloading a font you never use — it still consumes bandwidth and logs alerts. Mistake four: a local font path returning 404, so text jumps around with fallbacks and confuses users.
Mistake five: frequently changing fonts, invalidating the cache, so users re-download every time. These pitfalls aren’t hard to fix — put font size and font-display into the release checklist and you’ll block most of the problems, avoiding an above-the-fold experience being dragged down by one font. With core metrics stable, indexing and rankings have confidence behind them.
How to verify font impact
In DevTools’ Performance panel, watch when text goes from “invisible” to “visible,” comparing blank duration before and after setting swap; the Network Waterfall shows font request time and whether it blocks critical rendering at a glance, letting you pinpoint exactly which step is dragging things down.
For field data, check GSC’s Core Web Vitals to confirm LCP and CLS improve with the font optimization. Font optimization is fine work — you need to look at both lab and real users to confirm the blank screen and shift really disappear, not just look nice in local speed tests. The real weak-network environment is the ultimate standard.
Connecting to overall performance
Fonts are just one piece of the above-the-fold performance puzzle; together with image compression, the critical rendering path, and server response, they decide LCP. Point optimization helps, but only looking at the whole chain gives stable results — consider folding it into the site-wide performance budget for unified management.
If you haven’t done a site-wide performance review yet, start with the frontend performance chapter of the technical SEO handbook, rank fonts, images, and scripts by priority, then optimize item by item. That’s more effective than flailing around, and easier to explain the ROI to your team.
Where to host fonts: CDN or same origin
Where you host fonts matters too: same-origin hosting saves one DNS lookup, while preconnect to a CDN domain speeds things up asynchronously. Either works — the key is not letting font requests queue behind big images, and keeping them near the front of the critical rendering path.
If you use a third-party font service, confirm it supports woff2 and swap, and that its nodes are close enough to your users. Fonts seem like a small thing, but they load on every page — the accumulated impact on site-wide speed outlasts any single article’s big image, so it’s worth getting right.
Figure: Font Loading and SEO — Core Points (compiled by YunyingGO)
| Value | Behavior | Suggestion |
|---|---|---|
| swap | Shows system font, then swaps | First choice |
| fallback | Very brief blank | Usable |
| optional | Barely waits | Data-saving scenarios |
| block | Long blank | Avoid |
When you get to work, first set font-display: swap across the whole site and remove block/auto; then switch to woff2, only reference the weights you use, and subset the Chinese; preload the above-the-fold critical fonts, keeping it to 1-2 max. After the changes, check with both DevTools and GSC to confirm the blank screen and shift are truly gone. Finally, put font size and font-display into every release checklist — these steps look trivial, but their impact on above-the-fold experience and core metrics is often much bigger than you’d think.
