Because the browser is waiting for a font file it does not have yet. Until that file arrives, the browser either hides the text completely or shows a fallback typeface and swaps it later. Both behaviours are controlled by one CSS property, and most sites never set it deliberately.
This is one of the most visible performance problems on the web and one of the least discussed. Everyone notices it. Almost nobody files it as a bug.
It also costs you real metrics. Hidden text delays your Largest Contentful Paint. Swapped text causes layout shift. Both are Core Web Vitals, so a font decision made for visual reasons quietly becomes a measurement problem.
They add a request that blocks what the user came for. The browser has to download the CSS, discover the font reference, request the font file, wait for it, then render your text. Every step adds delay, and text is usually the thing people came to read.
The scale of this is easy to underestimate because font files look small. According to the HTTP Archive Web Almanac in 2025, the median web font weighs in the mid to upper thirty kilobyte range once compressed. At the 90th percentile it climbs to roughly 115 kilobytes. That is per file, and most sites load several.
Multiply that across a regular weight, a bold, an italic, and an icon font and you are into a few hundred kilobytes of pure typeface. The Web Almanac also found in 2025 that 88% of websites use web fonts, up slightly from 87% the year before, so this is nearly everyone''s problem.
The cost is not only bytes. It is the position of those bytes in the loading sequence. A font request discovered late blocks text late, which is worse than a larger file requested early.
They are the two ways a browser handles a missing font. FOIT is a flash of invisible text, where the browser hides your words until the font arrives. FOUT is a flash of unstyled text, where it shows a fallback typeface first and swaps in the real one later.
Neither is objectively correct. They trade different costs. FOIT protects the visual design and punishes the reader, who stares at a blank space. FOUT serves the reader immediately and punishes the design, because the page visibly reflows when the real font loads.
Our position is that FOUT is almost always the better trade on a business site. A visitor can read a fallback typeface. They cannot read nothing. The reflow is ugly for a moment; invisible text is useless for as long as it lasts.
The exception is a brand where the typeface genuinely carries the identity, and even then the answer is to make the font arrive fast rather than to hide the text while waiting.
The font-display property tells the browser how long to wait and what to do meanwhile. Google''s font best practices documentation describes five values with different block and swap periods. Block waits two to three seconds with invisible text. Swap shows the fallback immediately. Fallback and optional both block for only 100 milliseconds.
The difference between them is the swap period, which is how long a late font is still allowed to replace the fallback. With swap, the swap period is infinite, so the font always gets applied whenever it turns up. With fallback, the swap period is three seconds. With optional, there is no swap period at all, so a slow font is simply not used on that page view.
Google frames the choice by priority. If performance matters most, use optional, because it produces minimal delay and no layout shift, at the cost of sometimes not showing your web font at all. If you want a balance, use swap and make sure the font is delivered early. If the typeface really matters, use block and deliver it early enough that the block period barely triggers.
Most sites already land near the right answer by accident. The 2025 Web Almanac found roughly half of sites use font-display: swap, about a quarter use block, and around 9% use auto. Our default is swap for body text, and optional when we are chasing a performance number and the fallback is close enough that nobody would notice.
Two families and four files is a sensible ceiling for most sites. One family for headings, one for body, in the weights you actually use. Every additional weight is another file, another request, and another chance for text to arrive late.
The usual bloat comes from loading weights nobody designed with. A stylesheet that pulls in nine weights of a family when the design uses three is wasting most of what it downloads. It is worth auditing this against the actual design rather than the design system''s ambitions.
Icon fonts deserve their own scrutiny. The 2025 Web Almanac found Font Awesome on around 9% of pages, making it one of the most commonly loaded font resources on the web. If you are loading an entire icon font to show six icons, inline SVG will be smaller and will not block text.
The design side of this decision matters too, and picking the right typeface in the first place changes how much you need to load. We covered that separately in our guide to choosing the right fonts for a website.
Self-host when you can. Serving fonts from your own domain removes a connection to a third-party origin, which removes a DNS lookup and a TLS handshake before the font can even be requested. That is often the single biggest font win available.
The web is split on this. The 2025 Web Almanac found roughly 34% of sites self-host exclusively, about 36% use a mix of self-hosting and Google Fonts, and around 12 to 13% use Google Fonts alone. Google Fonts in some form appears on roughly half of sites.
Google Fonts is a good service and it is not the villain here. The issue is structural: any third-party origin means the browser must establish a new connection before it can start downloading, and that happens at exactly the moment your page is trying to render text.
There is a second reason we prefer self-hosting. It gives you control over the file format, the subset, and the font-display value. When the font is served by someone else''s stylesheet, you are accepting their defaults, and the defaults are rarely tuned for your page.
They help when you need several weights and hurt when you need one. A variable font packs a whole range of weights into a single file, so it replaces four requests with one. If your design only uses regular and bold, two static files are usually smaller.
Adoption has grown quickly. The 2025 Web Almanac reported variable fonts on about 39% of desktop sites and about 41% of mobile sites. That is a large share for a technology many teams have never consciously chosen.
The decision rule we use is simple arithmetic. Count the weights and styles the design genuinely uses. If it is three or more, the variable file almost always wins. If it is two, compare the actual file sizes before assuming.
Subsetting means shipping only the characters you need. A full font contains glyphs for languages and symbols your site will never render. Cutting them out shrinks the file, sometimes dramatically, with no visible difference to the reader.
Google''s guidance points out how extreme this gets with CJK typefaces, which can contain over 10,000 characters. For Chinese, Japanese, and Korean sites, subsetting is not an optimisation, it is a requirement.
For an English-language site the gain is smaller but still real, because most fonts ship with Cyrillic, Greek, and extended Latin ranges you are not using. If you run a multilingual site, subset per language rather than shipping one enormous file to everyone.
Format matters alongside this. Google''s documentation notes that WOFF2 compresses about 30% better than WOFF and now has universal browser support. The 2025 Web Almanac found WOFF2 accounts for 65.2% of desktop font requests, with WOFF still at 16% and TTF at 6.7%. If you are serving anything other than WOFF2, you are paying for compatibility you no longer need.
Sometimes, and carefully. Preloading tells the browser to fetch a font before it discovers the reference in your CSS, which removes a round trip. Google warns that preload bypasses some of the browser''s built-in content negotiation and can consume bandwidth needed elsewhere, so it is not a free win.
Preload the one font that renders your headline and nothing else. That single file is usually on the critical path for Largest Contentful Paint. Preloading four fonts means competing with your own images for bandwidth at the worst possible moment.
Adoption suggests most teams are appropriately cautious. The 2025 Web Almanac found preload on about 12% of sites, preconnect on around 18%, and dns-prefetch on roughly 15%. If you are using a third-party font host, preconnect is the cheaper first step, because it opens the connection without committing to a download.
This sits alongside the wider question of what is holding up your first render, which we covered in our article on render-blocking resources.
Open your site, count the font files it loads, and delete the weights the design does not use. Then set font-display explicitly rather than leaving it to the browser. Then convert anything that is not WOFF2. Those three changes take an afternoon and fix most font performance problems.
After that, look at where the fonts are served from. Moving from a third-party host to your own domain is a bigger job, but it removes a connection from the critical path, and on a site where text is the main content that is worth doing properly.
Font loading is one of the reasons our builds hold a 98 average PageSpeed score, and it is also one of the easiest things to get wrong when a design changes late. It is worth checking how these choices feed into your Core Web Vitals before you assume the problem is elsewhere.
If your text is flashing, shifting, or arriving late and you would rather not debug it yourself, let''s talk. We are happy to take a look and tell you what we would change. You can reach us at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.