Why font loading deserves its own analyzer
Web fonts make a site look like itself, but they are also one of the sneakiest performance problems on the modern web. A font file has to be downloaded before the browser can paint text in that typeface, and how the browser behaves during that download decides whether your visitor sees readable words immediately or stares at a blank space. This font loading analyzer inspects a page's font setup, detects custom fonts declared without a font-display rule, and flags font loads that block rendering. The aim is to make sure your text appears fast and stays stable, instead of flashing, jumping, or disappearing while a font downloads.
Fonts are easy to overlook because they usually work fine on a fast connection in your office. The trouble shows up on a slow mobile network, where a poorly configured font can leave the page wordless for a second or more, or cause the whole layout to lurch when the custom font finally swaps in. The analyzer surfaces these issues so you can fix them before real users on real networks feel them.
The font-display rule and what each value does
The single most important setting for font performance is font-display, a descriptor you add inside an at-font-face rule. It tells the browser what to do with the text while the custom font is still downloading. The analyzer checks every custom font for this descriptor because its absence is the most common font mistake on the web, and the default behaviour without it is one of the worst options for the user.
The value swap tells the browser to show text immediately in a fallback system font and then swap to the custom font once it loads. This guarantees readable text from the first paint, at the cost of a brief style change, and it is the safe default for body copy. The value optional tells the browser to use the custom font only if it loads almost instantly, otherwise stick with the fallback for the whole page view, which is excellent for performance and avoids any late swap. The value block hides the text for a short blocking period, hoping the font arrives, which risks invisible text. The value fallback sits in between. When the analyzer finds a font with no font-display at all, it is warning you that the browser will fall back to its default behaviour, which can leave text invisible for up to three seconds on slow connections.
FOIT, FOUT, and the flashes you are trying to avoid
Two acronyms describe the visible symptoms. FOIT, the Flash of Invisible Text, is when the browser hides text entirely while the font loads, so the user sees empty space where words should be. FOUT, the Flash of Unstyled Text, is when the browser shows the text in a fallback font first and then swaps to the custom one, so the user sees a quick style change. FOUT is almost always the better trade because the visitor can start reading immediately, which is exactly the behaviour font-display swap produces.
The analyzer helps you choose deliberately rather than accept whatever the browser defaults to. For most sites the right call is to accept a small, well-managed FOUT, keep text visible at all times, and reduce how jarring the swap looks by choosing a fallback font with similar metrics. Invisible text, the FOIT, is the outcome to eliminate, because text that cannot be read is worse than text in a slightly different typeface.
Render-blocking fonts and how to stop them
A font becomes render-blocking when the browser will not paint until the font file arrives, which is what an aggressive font-display or a slow-loading font file can cause. The analyzer flags these because they delay First Contentful Paint and, when the blocked text is your main heading, Largest Contentful Paint too. The chain is often longer than people realise: the browser has to download the HTML, then the CSS, then discover the font reference inside the CSS, then fetch the font. Each step adds delay before any custom-font text can appear.
The most effective fix is to preload your critical fonts. A preload link in the page head tells the browser to start fetching the font immediately, in parallel with the CSS, instead of waiting to discover it later. Preload only the one or two fonts actually used above the fold, because preloading too many fonts floods the connection and slows down everything else. Self-hosting fonts rather than pulling them from a third-party domain also helps, since it removes an extra DNS lookup and connection setup, and lets the font ride the same fast, cached connection as the rest of your assets.
How to read the analyzer output
Begin with the list of custom fonts and their font-display status. Any font marked as missing font-display is your first priority, because it is gambling with whether text shows at all on slow networks. Add swap or optional to those at-font-face rules and the warning clears. Next, look at how many distinct font files and weights the page loads. Each extra weight and style is a separate download, and many sites load four or five weights when they actually use two. Trimming unused weights is often the biggest single win the analyzer reveals.
Also watch for fonts loaded from external domains and for fonts that are not preloaded but clearly drive the first paint, such as the font of your main headline. The analyzer flags these so you can decide whether to self-host, to preload, or to drop a weight entirely. A clean result is a short list of fonts, each with an explicit font-display value, the critical one or two preloaded, and no surprise external dependencies.
Fonts, Core Web Vitals, and AI search in 2026
Font behaviour touches two Core Web Vitals directly. It affects Largest Contentful Paint whenever your largest text element waits on a custom font, and it affects Cumulative Layout Shift when the swap from a fallback font to the custom font changes line heights and widths, pushing content around. Choosing a fallback font with metrics close to your web font, and using the size-adjust and related descriptors to match them, keeps the swap nearly invisible and protects your layout-shift score. Fast, stable text is a quiet but real ranking advantage.
For AI search the link is indirect but worth noting. AI crawlers read the underlying HTML text, not the rendered typeface, so a missing font-display does not stop them from reading your words. What does matter is total page speed: a page burdened with many heavy, render-blocking fonts is slower to load and parse, which works against you when an AI crawler is deciding how much of the page to fetch within its time budget. Lean font loading keeps the page light for both humans and machines.
System fonts, variable fonts, and subsetting
The fastest font is the one you never download. A system font stack, which uses whatever sans-serif or serif typeface the visitor's device already has installed, costs zero bytes and paints instantly, with no font-display question to worry about because there is nothing to wait for. Many products choose this deliberately for body text and reserve a custom font only for headings or branding. The analyzer helps you see how many custom fonts you are actually pulling in, and sometimes the honest answer is that one or two of them could be a system font instead, removing the request entirely.
When you do need a custom typeface, two techniques cut its weight dramatically. A variable font packs many weights and styles into a single file, so instead of downloading separate files for regular, medium, bold, and their italics, the browser fetches one file and derives every weight from it. That often replaces four or five downloads with one. Subsetting goes further by stripping out the characters you do not use, such as scripts for languages your site never serves, which can shrink a font file by more than half. A Latin subset alone is enough for most English-language sites.
Modern font formats matter too. WOFF2 is the smallest widely supported format, compressing better than the older WOFF and far better than raw TTF or OTF files. If the analyzer or your own inspection shows fonts served as TTF or OTF, converting them to WOFF2 is a quick, lossless size win. Combine WOFF2 with a variable font, a tight character subset, and an explicit font-display value, and a typeface that once cost several hundred kilobytes across multiple files can shrink to a single small download that paints quickly and never blocks your text.
What to do after you run it
Add an explicit font-display value to every custom font, choosing swap for body text and optional where you can tolerate the fallback sticking. Preload only the one or two fonts used above the fold, and remove font weights and styles the page does not actually use. Self-host your fonts where practical, and pick a fallback font with similar proportions, tuned with size-adjust, so the swap barely shows. These changes are small edits to your CSS and head, not a redesign.
After making the changes, re-run the analyzer to confirm every font now reports a font-display value and that the critical fonts are preloaded. Pair it with a page-speed test to watch First Contentful Paint and Largest Contentful Paint improve, and check the layout-shift number to confirm the font swap is not moving content. Done well, font loading becomes invisible: text appears instantly, the brand typeface arrives without a jolt, and your performance scores quietly climb.