Why Does My Website's Text Disappear While It Loads? Web Fonts Explained for Small Business Owners
Open your own website on a phone with a weak signal, or throttle your connection in developer tools, and you might catch it: the page loads, the layout is there, but for a second the text itself is just gone. Blank white or blank dark space where your headline and body copy should be. Then, as if someone flipped a switch, the words appear. Nothing crashed. This is a well-known, well-documented browser behavior tied to how your site loads its custom font, and it is one of the more overlooked items on a Lighthouse report because it never shows up as an error, just a delay.
What is actually happening
Most business websites do not use a font that ships with the visitor's device. They use a custom "web font", a specific typeface picked to match the brand, downloaded from a server the same way an image is. That download takes time, and browsers have to decide what to show on screen while they wait for it.
For a long stretch of the web's history, the default answer in most browsers was: nothing. Hide the text completely until the exact font file arrives, then reveal it all at once. Developers call this FOIT, Flash of Invisible Text. It was designed to avoid a different annoyance, text visibly re-flowing or "jumping" when a fallback font is swapped for the real one, but the fix created its own problem: a page that looks empty or broken for however long the font takes to download.
Why it is worse than it sounds
On a fast office Wi-Fi connection, the font file often arrives in well under a tenth of a second, so this default is invisible in practice and nobody would ever notice or complain. The problem shows up specifically where it costs you the most: a visitor on a phone, on cellular data, standing in a parking lot deciding whether to call your business or a competitor's. That is exactly the moment a slow font download turns your homepage into a blank rectangle for a second or more, and a visitor who is already impatient does not know a font is loading, they just see nothing and assume the page is broken or still buffering.
It also has a measurable cost beyond the impression it leaves. Invisible text delays when your Largest Contentful Paint fires, since the browser has not actually painted anything readable yet, and LCP is one of the three Core Web Vitals Google uses as a ranking signal. A slow font swap can single-handedly push a page that is otherwise fast into a failing LCP score.
How to check your own site
In Chrome or Edge, open developer tools (right-click anywhere on the page, choose "Inspect"), go to the Network tab, and set throttling to "Slow 3G" or "Fast 3G". Reload your homepage and watch closely in the first second or two. If the layout, images, and buttons appear but the text stays blank for a beat before snapping into view, your site has this behavior. On a normal connection it can be too fast to catch with the naked eye, which is exactly why it is easy to miss without deliberately testing for it.
That is also one of the checks in our free audit: it flags pages where text is hidden while a web font loads, using the same tooling Google's own Lighthouse reports run on, and explains it in plain language rather than a technical audit name.
The fix: font-display: swap
Modern CSS has a purpose-built setting for exactly this problem: font-display: swap, added to the @font-face rule that defines your custom font. It tells the browser to show your text immediately in a safe fallback font (whatever is already installed on the visitor's device) the instant the page loads, and quietly swap in your custom font once its file finishes downloading. The visitor never sees blank space, only a brief, usually unnoticeable, font change a moment later.
Where to add it: directly in your theme or site's CSS if you manage the font files yourself. If you load fonts through Google Fonts, add &display=swap to the end of the Google Fonts embed URL. Most WordPress themes and page builders (Elementor, Divi, Squarespace, Wix) also expose a "font display" or "font loading" toggle in their typography settings.
Preload the font file for an even faster swap
Font-display: swap solves the invisible-text problem, but the fallback-to-custom-font swap still happens whenever the file finishes. You can make that file arrive sooner by adding a <link rel="preload"> tag for your most important font file in the page's <head>, which tells the browser to start that download earlier and with higher priority than it otherwise would.
This is optional polish once the swap behavior itself is fixed. Most sites see the bigger win from font-display: swap alone.
Frequently asked questions
Why does my website look blank for a second before the text shows up?
Your site uses a custom web font, and by default many browsers hide text on the page until that font file finishes downloading, rather than briefly showing it in a fallback font. On a fast connection this happens in a blink and nobody notices. On a slow connection or a phone on weak signal, it can last a second or more, and the page looks broken or empty in that window.
Is a blank-text flash actually hurting my business?
Yes, for the same reason any slow-feeling page hurts you: a visitor who lands on what looks like an empty page is more likely to hit back before your headline and call-to-action ever appear. It also adds to your Largest Contentful Paint time, one of the Core Web Vitals Google uses as a ranking signal.
How do I fix invisible text while a font loads?
Add font-display: swap to your @font-face CSS rule (or the equivalent setting in Google Fonts, WordPress, or your page builder). It tells the browser to show your text immediately in a fallback font and swap in the custom font once it arrives, instead of hiding the text and waiting. It's usually a one-line change with no downside.
How do I check if my site has this problem?
Throttle your connection in your browser's developer tools (Chrome: Network tab, throttle to "Slow 3G") and reload your homepage. If the page stays blank for a moment before any text appears, you have it. Our free audit checks this automatically along with speed, SEO, accessibility, and security.
The cheapest way to find out
Run the free audit below. We check for this along with server speed, image weight, mobile-friendliness, and SEO basics, using the same tooling Google uses, and email you a plain-English report of exactly what is wrong and how it gets fixed. If something needs fixing, it is a flat $149 for your fixable speed/image/SEO/broken-link issue, or $299 for everything, with before-and-after proof once it is done.