Set fonts to display a fallback immediately and swap when they arrive. Without that, a browser hides the text for up to three seconds.

What the browser does by default

When a page uses a font that has to be downloaded, the browser has a choice: show the text in something else immediately, or wait.

By default it waits, on the reasoning that showing the wrong font briefly is worse than showing nothing.

That wait is up to about three seconds, after which it gives up and shows a fallback anyway.

So a slow font produces a page that has arrived, is laid out, and has no visible words in it.

Why this is the wrong default for a business

The last is the point. Somebody reading your service page has no idea what typeface you intended, so showing them the text immediately in something similar costs you nothing and gains them the content.

The setting that fixes it

A single property applied to each font, and it is one line.

Setting the fonts to swap tells the browser to show the fallback immediately and replace it when the real font arrives.

The text is readable from the moment the page renders, which is the outcome that matters.

There is a variant that gives the font a very short window and otherwise abandons it entirely, which avoids any visible change at the cost of sometimes not using your font at all.

For most business sites, swapping is the right choice, since the content appearing quickly is worth more than typographic consistency in the first second.

Ask whoever maintains the site whether it is set, since it is a one-line change and is frequently absent.

The trade-off is a visible change

Worth stating honestly, since swapping is not free.

The text appears in a fallback and then changes when the real font arrives, which is visible and slightly jarring.

If the two fonts have different proportions, the text also reflows as it swaps, which moves the content somebody is reading.

That is reduced by choosing a fallback with similar proportions to your chosen font, which most systems can be told to do.

Adjusting the fallback's size and spacing to match more closely is a further refinement and is worth doing on a text-heavy site.

Even without that, a brief change is better than three seconds of nothing.

A worked example

A business had a site where, on a phone on mobile data, the page appeared with images and no text for two or three seconds.

Everybody assumed the site was slow generally.

The actual cause was two font files loading from an external service, with no display setting, so the browser was hiding all the text until they arrived.

Adding the swap setting made the text appear immediately, and self-hosting the fonts removed most of the delay before the swap happened.

Measured load time barely changed, and the experience changed completely.

Which is the useful lesson: the number and the experience are different things.

Reduce what you are loading

Since the best fix is needing less.

Count the font files being downloaded, which is usually more than anybody intended: several weights, several styles, and sometimes a second family from a plugin.

Most sites need two weights of one family, and load six of two.

Each unused weight is a file being downloaded for nothing.

Remove the ones not used, which is a settings change on most platforms, and the remaining delay shrinks proportionally.

A site using only the system fonts already installed on the device has no delay at all, which is a legitimate and increasingly common choice.

Serve them from your own site

Where you do use custom fonts.

A font loaded from an external service requires a connection to another domain before the file can even be requested, which adds delay before anything begins.

Hosting the files yourself removes that step and usually makes the fonts arrive noticeably sooner.

It also removes a dependency on somebody else's service being available.

Check the licence allows it, which most do, and ask whoever maintains the site to make the change.

That combined with the swap setting resolves almost every case of this.

Test it under a slow connection

Because at full speed the problem is invisible.

On a fast connection the font arrives in under a hundred milliseconds and nobody sees the blocking at all.

Throttle the connection in your browser's tools and reload, watching whether the text appears immediately or after a pause.

That takes a minute and is the only way to see what a customer on mobile data experiences.

Do the same check after any redesign, since font settings are commonly lost in one.

Icon fonts have the same problem and worse

Worth checking separately, since they behave identically and fail more visibly.

Where icons are drawn from a font file, the same blocking applies, and the fallback for a missing icon is not a different icon but a random character or an empty box.

So a page can render with rectangles where the telephone and menu symbols should be, which reads as broken rather than as unstyled.

The better answer is to stop using an icon font at all and use individual image files for the handful of icons a small site needs.

That removes an entire download, removes the failure mode, and is usually less code than the font was.

The counter-case

Some sites should not swap.

Where the typeface is genuinely part of the brand and a visible change would be jarring, the short-window option is defensible.

Very short pages also give the fallback little chance to be seen either way.

And on a fast site with self-hosted fonts, the default behaviour rarely produces a visible problem.

Set the fonts to swap, remove the weights you do not use, host them yourself, and test on a throttled connection.

What to check

  1. Throttle the connection and reload.
  2. Watch whether text appears immediately.
  3. Set the fonts to swap.
  4. Count the weights being loaded.
  5. Remove the unused ones.
  6. Host the files yourself.
  7. Recheck after any redesign.

Step three is a one-line change that converts three seconds of invisible text into immediate readability, which is the best ratio available anywhere in this subject.

Where they are coming from is covered in fonts loading from three different places.


Frequently asked questions

What does the browser do by default?

It waits for the font rather than showing the text in something else, for up to about three seconds, on the reasoning that the wrong font briefly is worse than nothing.

Why is that wrong for a business?

Because the words are why somebody came, three seconds is long enough to leave, the page looks broken rather than slow, and nobody knows what typeface you intended.

What is the fix?

A single property telling the fonts to swap, so the browser shows a fallback immediately and replaces it when the real font arrives. It is one line and frequently absent.

What is the trade-off?

A visible change when the font arrives, and reflow if the two have different proportions. Choosing a similar fallback reduces it, and a brief change beats three seconds of nothing.

How do I reduce the delay itself?

Count the font files being downloaded, remove the weights you do not use, and host the files on your own site rather than loading them from an external service.

How do I test it?

Throttle the connection in your browser's tools and reload, watching whether text appears immediately. At full speed the problem is invisible.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Page appearing with images and no text?

That is the font blocking, not the site being slow. One line of setting fixes it.

Start a Conversation