Web Fonts and Core Web Vitals: 7 Powerful Fixes for FOIT, FOUT and CLS

Introduction

Web fonts and Core Web Vitals are closely connected because font loading can affect how quickly text appears and whether page elements shift during rendering. FOIT (Flash of Invisible Text) and FOUT (Flash of Unstyled Text) describe different font-loading behaviors, while poorly matched fallback fonts can contribute to Cumulative Layout Shift (CLS). Choosing suitable font formats, configuring font-display, optimizing font files, and using font preloading selectively can improve the reading experience without adding unnecessary loading delays.

Web fonts can make a website look dramatically better, but they also introduce another resource into the browser’s loading process.

Before the preferred font is available, the browser has to decide what to display. Should it show a fallback font? Should it temporarily hide the text? Should it swap fonts when the web font arrives?

Those decisions affect what visitors see and, in some situations, how much the page moves while loading.

This is where terms such as FOIT and FOUT become useful. They describe two different font-loading behaviors, and understanding the difference makes it easier to diagnose font-related performance problems.

For Core Web Vitals, the biggest concern is usually not simply whether a font loads quickly. It is whether font loading delays useful content, changes the dimensions of text, or causes the surrounding layout to move.

Quick Answer

Web fonts can affect Core Web Vitals in several ways:

• FOIT (Flash of Invisible Text) occurs when text is temporarily invisible while the browser waits for a font.
• FOUT (Flash of Unstyled Text) occurs when fallback text is displayed before the preferred font loads.
• FOUT is generally more visible but allows users to see text sooner.
• A font swap can cause layout shifts if the fallback and final fonts have significantly different metrics.
• font-display controls how the browser handles font loading and swapping.
• Preloading a critical font can help in some situations, but unnecessary preloads can compete with more important resources.
• Reducing font files, weights, and character sets can reduce the amount of font data the browser needs to download.
• Metric-compatible fallback fonts can reduce layout movement during a font swap.
• A font-related CLS problem should be diagnosed in the actual page rather than assumed from the presence of web fonts.

The goal is not simply to make fonts load faster.

The goal is to make text visible quickly and keep the layout stable while the final font becomes available.

What Are FOIT and FOUT?

The browser cannot use a web font before it has downloaded enough information to render it.

That creates a decision point.

Depending on the font-loading strategy and browser behavior, visitors may temporarily see invisible text or text rendered using another font.

FOIT: Flash of Invisible Text

FOIT stands for Flash of Invisible Text.

The text exists on the page, but it is temporarily not visible while the browser waits for the web font.

A simplified sequence looks like this:

1. HTML arrives.
2. The browser discovers text using a web font.
3. The font is not available yet.
4. Text is temporarily hidden.
5. The font becomes available.
6. The browser renders the text.

The visitor may perceive this as a blank area where text should be.

That is especially undesirable for important content such as:

• navigation
• headings
• article text
• buttons
• product information

FOUT: Flash of Unstyled Text

FOUT stands for Flash of Unstyled Text.

Instead of hiding the text, the browser initially renders it using a fallback font.

Later, when the web font becomes available, the browser swaps to the intended typeface.

The sequence becomes:

1. HTML arrives.
2. Fallback font renders.
3. Visitor can read the content.
4. Web font downloads.
5. Text switches to the preferred font.

This is often a better perceived-loading experience because users can see and read the content sooner.

But there is a catch.

If the fallback font has substantially different dimensions from the final font, the text can reflow.

That can contribute to layout instability.

FOIT vs FOUT

Behavior	What the visitor sees	Main concern
FOIT	Text temporarily invisible	Content is unavailable visually
FOUT	Fallback text appears first	Font swap may change layout
Metric-compatible fallback	Fallback looks dimensionally similar	Smaller visual/layout difference
Final font from the start	Intended font renders immediately	Requires the font to become available quickly

There is no universal rule that one strategy is always best.

The correct choice depends on:

• the importance of the text
• font size
• fallback compatibility
• font file size
• network conditions
• page design
• whether the font is essential to the brand or interface

How Web Fonts Can Affect Core Web Vitals

Font loading is most closely associated with CLS, but it can influence the loading experience more broadly.

Fonts and LCP

If the Largest Contentful Paint element is text, font loading can become part of the path to displaying that content.

For example, an important heading might be the LCP element.

If the browser delays rendering the heading while waiting for a font, that can affect when the element becomes visually complete.

However, not every slow font creates a poor LCP.

If the LCP element is an image and the font is used elsewhere on the page, optimizing the font may have little effect on LCP.

This is why the actual LCP element should be identified before deciding that fonts are responsible.

Fonts and INP

Fonts are generally less directly connected to INP than JavaScript or main-thread work.

However, font loading and rendering can still contribute to browser work under certain circumstances.

The important distinction is that simply having several font files does not automatically mean the page will have poor INP.

If interaction responsiveness is the problem, investigate the main-thread work associated with the interaction rather than blaming font loading by default.

Fonts and CLS

CLS is where font problems become especially interesting.

Suppose the fallback font renders a heading across two lines.

The final font is narrower, so the same heading fits on one line.

The heading becomes shorter.

Everything below it moves upward.

The opposite can also happen.

That movement may contribute to layout instability.

Why Font Swapping Can Cause Layout Shift

The root problem is usually font metric differences.

Two fonts can display the same words at the same nominal font size while occupying noticeably different amounts of space.

Differences can occur in:

• character width
• x-height
• ascent
• descent
• line gap
• glyph dimensions

Consider a heading:

Improve Website Performance

With one font, it might fit on one line.

With another, it might wrap onto two.

If the browser switches between those fonts after the page has already been laid out, the dimensions of the text block can change.

That can move surrounding content.

The problem is therefore not simply:

“The font loaded late.”

It is:

“The layout changed when the font became available.”

That distinction is important when troubleshooting CLS.

What Does font-display Do?

The CSS font-display descriptor lets you control how a font face should behave while the font resource is loading.

A typical declaration looks like:

@font-face {

  font-family: “Example Sans”;

  src: url(“/fonts/example-sans.woff2”) format(“woff2”);

  font-display: swap;

}

The commonly used values include:

• auto
• block
• swap
• fallback
• optional

They provide different trade-offs between showing fallback text, waiting for the web font, and using the web font when it becomes available.

font-display: swap

With swap, the browser can display fallback text and then swap to the web font when it is ready.

This makes text available quickly.

The downside is that the final font can change text dimensions and potentially cause layout movement.

font-display: block

block gives the web font a short block period during which text may remain invisible before the browser falls back to another strategy.

This can reduce the visible font swap in some situations, but it can also delay visible text.

It is not automatically a better choice for Core Web Vitals.

font-display: fallback

fallback provides a relatively short opportunity for the web font to load before the fallback becomes more important.

It can be useful when the font is desirable but not worth delaying the user’s experience for.

font-display: optional

optional gives the browser significant freedom to decide whether the web font should be used.

On slower connections, the browser may choose not to swap to the font at all.

That can produce a very stable experience when the fallback is well chosen.

But if the custom font is essential to the site’s visual identity, it may not provide the desired result.

Which font-display Value Should You Use?

There is no universal setting that guarantees the best Core Web Vitals.

A practical decision looks like this:

Use swap when:

• the font is important
• text should appear immediately
• a temporary fallback is acceptable
• the fallback font is reasonably compatible

Consider optional when:

• the font is nonessential
• the fallback is perfectly acceptable
• you prioritize a stable, fast experience over guaranteed font usage

Be cautious with block when:

• important text depends on the font
• invisible text would create a poor user experience

The right choice should be based on the role of the font, not on a blanket performance rule.

Choose a Better Fallback Font

One of the simplest ways to reduce font-related layout shifts is to choose a fallback font with similar metrics.

For example:

body {

  font-family: “Example Sans”, Arial, sans-serif;

}

If “Example Sans” and Arial have very different dimensions, a font swap may cause noticeable reflow.

A more compatible fallback can reduce that difference.

Modern CSS also provides font metric adjustment descriptors that can help tune fallback behavior.

These include:

• size-adjust
• ascent-override
• descent-override
• line-gap-override

For example:

@font-face {

  font-family: “Example Fallback”;

  src: local(“Arial”);

  size-adjust: 95%;

}

These features allow developers to make the fallback font’s metrics more closely resemble the target font.

This can be particularly useful when a branded typeface is important but loading it immediately is not guaranteed.

The exact values should be derived from the fonts involved rather than copied blindly.

Reduce the Number of Font Files

A website can accidentally load far more font data than visitors actually need.

For example, a design might include:

• regular
• medium
• semibold
• bold
• extra bold
• italic
• bold italic
• several language subsets

If only regular and bold are used, loading every variation creates unnecessary work.

Audit the actual fonts used by the page.

Remove:

• unused weights
• unused styles
• duplicate files
• unnecessary families
• unused character sets

Fewer resources can mean less downloading and fewer opportunities for font-loading behavior to interfere with rendering.

Prefer WOFF2 for Modern Web Delivery

WOFF2 is the standard choice for modern web font delivery.

It provides efficient compression compared with older web font formats and is widely supported by modern browsers.

A typical declaration is:

@font-face {

  font-family: “Example Sans”;

  src: url(“/fonts/example-sans.woff2”) format(“woff2”);

}

This does not mean format alone solves font performance.

A tiny WOFF2 file can still be unnecessary if the font isn’t needed.

Likewise, a large WOFF2 file can still be expensive to download.

The better approach is to reduce the amount of font data required in the first place.

Subset Fonts When Appropriate

If a website only needs a particular character set, font subsetting can significantly reduce file size.

For example, a site targeting primarily English-language content may not need every glyph contained in a full Unicode font.

Subsets can be created for:

• Latin
• Cyrillic
• Greek
• other language groups

However, multilingual websites need to handle this carefully.

Removing characters that users actually need can result in missing glyphs or unexpected fallback behavior.

Font subsetting is useful when it reflects the site’s actual content requirements.

Don’t Load Every Font Weight Up Front

A common implementation mistake is loading all font weights on every page.

The browser may have to download fonts that never get used.

Instead, identify which weights are actually required by the page.

For example:

font-weight: 400;

font-weight: 700;

If the design does not use 500, 600, and 800, there may be little reason to load those files.

This is especially important on mobile connections.

Should You Preload Web Fonts?

Preloading can make a critical font available earlier:

<link

  rel=”preload”

  href=”/fonts/example-sans.woff2″

  as=”font”

  type=”font/woff2″

  crossorigin

>

This can help when the font is genuinely critical to the initial viewport.

But preload is not a general-purpose speed button.

Every preloaded resource competes for early network bandwidth.

If the browser needs to download an important LCP image, CSS, or other critical resource, an unnecessary font preload can compete with those resources.

Use preload selectively.

A good candidate is a font that:

• is required for above-the-fold content
• is actually used immediately
• would otherwise be discovered late
• has a meaningful effect on the initial rendering experience

Don’t preload every font simply because it exists.

Font Preload and crossorigin

When preloading cross-origin fonts, the request needs to use the appropriate CORS mode.

For example:

<link

  rel=”preload”

  href=”https://fonts.example.com/example.woff2″

  as=”font”

  type=”font/woff2″

  crossorigin

>

If the preload and the eventual font request do not match appropriately, the browser may perform another request instead of reusing the preloaded resource.

That defeats the purpose of the preload.

Self-Hosted Fonts vs Third-Party Fonts

Web fonts can come from your own server or from a third-party provider.

Neither approach is automatically faster.

With self-hosted fonts, you have more control over:

• caching
• file selection
• subsetting
• preload decisions
• request timing
• hosting location

Third-party font services can simplify delivery and font management, but they add another external dependency.

The right decision depends on the site’s architecture and requirements.

Don’t move fonts to another provider solely because a performance tool identifies them as third-party resources.

Measure the actual effect.

Don’t Load Fonts That Aren’t Needed

One of the easiest font optimizations is also one of the most overlooked:

Don’t download what the page doesn’t use.

A page may load a custom display font even though the font is only used in a footer logo.

Or it may load several font weights because a theme declares them globally.

Or a page builder may enqueue fonts used by components that are not present on the current page.

Audit the network requests.

If a font has no meaningful role in the current page, consider removing it from that page’s loading path.

Use Font Loading Strategically for LCP Text

If the LCP element is a large heading or block of text, font loading deserves closer attention.

Suppose:

• the heading is the LCP element
• the preferred font is discovered late
• the browser initially hides the text
• the font loads after the critical rendering path has progressed

The font may become part of the reason the heading appears late.

Possible improvements include:

• making the font discoverable earlier
• reducing the font file size
• removing unused font variants
• using an appropriate font-display strategy
• selecting a compatible fallback
• avoiding unnecessary font dependencies for critical text

But first confirm that the font is actually involved in the LCP delay.

If the LCP problem is caused by server response time or a hero image, changing fonts won’t solve it.

How to Diagnose Font-Related CLS

When you see poor CLS, don’t assume fonts are responsible.

Look for evidence.

A useful process is:

Step 1: Identify the shifting element

Find the element that moved.

If the affected element is a heading, navigation item, button, or text block, fonts become a stronger suspect.

Step 2: Check whether the font changes

Use DevTools to inspect the page while loading.

Look for:

• fallback text
• font requests
• late font completion
• changes in text wrapping
• changes in element dimensions

Step 3: Compare the fonts

Check whether the fallback and final fonts have significantly different metrics.

Pay particular attention to large headings and tightly constrained components.

Step 4: Test with the custom font disabled

Temporarily remove the web font in a development environment.

If the layout remains stable without it but shifts when the font is introduced, you have stronger evidence that font metrics or font-loading behavior are involved.

Step 5: Test the fix

Try:

• a better fallback
• adjusted font metrics
• a different font-display strategy
• fewer font variants
• earlier font discovery

Then test again.

A Simple Example of Font-Related CLS

Imagine a blog article with this heading:

How to Improve Website Performance

The fallback font renders the heading across two lines.

The custom font arrives later and fits the same text onto one line.

The heading becomes shorter.

The article content below moves upward.

That is a layout change caused by the font swap.

Now imagine the fallback font has been carefully selected to have similar metrics.

The heading remains two lines in both fonts.

The visual appearance changes when the custom font arrives, but the surrounding layout barely moves.

The second implementation is much more resilient.

Web Fonts and CLS: What Developers Often Get Wrong

Mistake 1: Assuming font-display: swap fixes CLS

swap helps make text visible sooner, but it does not guarantee layout stability.

If the fallback and final fonts have different metrics, the swap can still cause movement.

Mistake 2: Preloading every font

Preloading too many fonts can consume early bandwidth and compete with more important resources.

Mistake 3: Loading every font weight

Unused font files are still network requests and can increase page weight.

Mistake 4: Using a poor fallback

A generic fallback may have very different dimensions from the custom font.

Mistake 5: Optimizing fonts without checking the LCP element

A font may look suspicious in a performance audit while having nothing to do with the actual LCP problem.

Mistake 6: Treating all font shifts as equally important

A tiny change in a footer is very different from a large movement of an article heading near the top of the viewport.

Focus on meaningful instability.

Web Fonts and Core Web Vitals: Practical Checklist

Font loading

• Use efficient modern font formats.
• Remove unused font families.
• Remove unused weights and styles.
• Subset fonts where appropriate.
• Avoid unnecessary font requests.
• Make critical fonts discoverable at the right time.

CLS

• Choose a compatible fallback font.
• Check font metric differences.
• Test large headings separately.
• Avoid layout changes caused by font swapping.
• Consider size-adjust and metric overrides where appropriate.
• Test mobile and desktop layouts.

font-display

• Decide whether immediate text visibility matters.
• Use swap when a fallback-first experience makes sense.
• Consider optional for nonessential fonts.
• Avoid delaying important content unnecessarily.

Preload

• Preload only genuinely critical fonts.
• Don’t preload every font.
• Make sure the preload matches the actual font request.
• Check whether the font is competing with the LCP resource.

Diagnosis

• Identify the actual CLS element.
• Check whether a font swap occurred.
• Inspect font requests in DevTools.
• Compare fallback and final text dimensions.
• Validate the fix with lab testing.
• Monitor field data when available.

Final Verdict

Web fonts are not inherently bad for Core Web Vitals.

The problem starts when font loading is treated as an isolated design decision rather than part of the page’s rendering process.

FOIT prioritizes waiting for the font.

FOUT prioritizes showing fallback text.

Neither approach is automatically perfect.

For most websites, the better strategy is to make the choice deliberate: show useful text quickly, keep fallback and final font metrics reasonably compatible, load only the fonts the page actually needs, and avoid spending early bandwidth on fonts that are not critical.

When a font-related CLS problem appears, don’t start by changing font-display and hoping the score improves.

Find the element that moved.

Find out whether the font swap changed its dimensions.

Then fix the relationship between font loading and layout stability.

That is the real goal.

A well-optimized font setup should make the page feel like the typography was there from the beginning—even when the browser is still working in the background to load the final font.

Related Guides

• What Is CLS? Cumulative Layout Shift Explained
• How to Fix Cumulative Layout Shift
• What Is LCP? Largest Contentful Paint Explained
• How to Fix Poor LCP: A Practical Troubleshooting Guide
• Third-Party Scripts and Core Web Vitals
• How to Eliminate Render-Blocking Resources
• Image Optimization: WebP, AVIF, Sizing and Lazy Loading
• Lighthouse vs CrUX: Lab Data vs Real-World Data
• Website Speed Optimization Checklist

Recommended Resources

For further reading on font loading and performance optimization, explore these authoritative resources:

• web.dev: Optimize Web Fonts: Learn how font loading strategies affect rendering and performance.
• MDN: The font-display Descriptor: Understand how browsers handle text while web fonts are loading.
• Google Fonts Knowledge: Explore font delivery and implementation guidance.
• Google Search Central: Core Web Vitals: Review Google’s guidance on loading, responsiveness, and visual stability metrics.
• web.dev: Optimize Cumulative Layout Shift: Learn how to identify and reduce unexpected layout shifts.