Why Web Fonts Cause Layout Shift (and how to avoid it)

Why web fonts cause layout shift becomes much easier to understand once you stop thinking of a font as a purely visual asset. A web font also has measurable geometry: glyph widths, ascent, descent, line gaps, x-height and other metrics that directly influence how much space text occupies.

When the browser first renders a page, the intended web font may not be available yet.

The browser therefore has to decide what to display while that font downloads.

Depending on the font-loading strategy, visitors may briefly see:

• invisible text;
• a fallback system font;
• text that suddenly changes appearance;
• headings that reflow onto different lines;
• buttons that change width;
• navigation items that move;
• content below a paragraph being pushed downward.

That last group of effects is where web fonts can contribute to Cumulative Layout Shift, usually abbreviated as CLS.

The simplified sequence is:

HTML arrives
↓
CSS identifies custom font
↓
font is not available yet
↓
fallback font renders
↓
web font downloads
↓
browser swaps fonts
↓
text metrics change
↓
lines reflow
↓
surrounding layout moves

The solution is not simply to remove web fonts.

It is to understand how fonts load, reduce unnecessary font resources, choose sensible fallback metrics and make the transition between fallback and final typography as geometrically stable as possible.

For the wider performance context around fonts, CSS, scripts and other frontend resources, see Reducing WordPress Front-End Page Weight.

What is layout shift?

Layout shift occurs when visible content changes position without the user causing that movement.

Imagine reading a paragraph when another resource finishes loading.

The content suddenly moves.

Your eyes were following:

this line

and a moment later that same line is somewhere else.

That is a layout shift.

A single small movement may be barely noticeable.

Multiple shifts during page loading can make the interface feel unstable.

Google’s guide to optimizing Cumulative Layout Shift identifies web fonts alongside images, embeds, ads and dynamically injected content as common sources of unexpected movement.

What is Cumulative Layout Shift?

Cumulative Layout Shift is a Core Web Vitals metric concerned with visual stability.

It measures unexpected movement of visible page elements during the lifetime of a page.

Typical causes include:

• images without reserved dimensions;
• iframes without reserved space;
• advertising containers that expand after loading;
• dynamically injected content;
• late-loading banners;
• web-font replacement.

Fonts are particularly interesting because the movement may initially look mysterious.

Nothing obvious was inserted into the page.

Only the typeface changed.

But typography directly participates in layout.

For sites with several other external resources competing with fonts during initial rendering, also review Why Third-Party Embeds Slow Down WordPress.

A font has dimensions

Consider two typefaces rendered at:

font-size: 48px;

That does not mean every character occupies the same amount of space.

One font might render:

Build better WordPress sites

within 620 pixels.

Another might require:

680 pixels

for exactly the same text at the same CSS font-size.

Typography has measurable geometry.

Different fonts have different:

• glyph widths;
• x-heights;
• cap heights;
• ascenders;
• descenders;
• line gaps;
• kerning;
• letter shapes;
• weight characteristics.

Those differences affect layout.

The complete CSS mechanism behind downloadable fonts is defined by the MDN documentation for @font-face.

Why changing fonts can change line wrapping

Suppose a hero heading has a container width of:

720px

The fallback font renders:

Build faster WordPress
websites

The final font may instead render:

Build faster
WordPress websites

The heading still contains exactly the same words.

But the line breaks changed.

If the second version occupies three lines instead of two, everything below it moves downward.

The browser has just performed a layout change because the font metrics changed.

Font loading creates a timing problem

A system font may already exist on the visitor’s device.

A custom web font normally has to be downloaded.

The browser might encounter:

font-family:
    "Brand Sans",
    Arial,
    sans-serif;

but Brand Sans is not yet available.

The browser must therefore decide whether to:

• wait;
• temporarily hide the text;
• render Arial;
• later replace Arial with Brand Sans;
• keep the fallback if the font arrives too late.

That behavior is heavily influenced by font-display.

Google’s web font performance best practices cover the relationship between font loading, rendering, FCP, LCP and CLS in more detail.

FOIT and FOUT

Two abbreviations frequently appear in discussions about web-font loading:

FOIT
Flash of Invisible Text

FOUT
Flash of Unstyled Text

They describe different compromises.

FOIT

With Flash of Invisible Text, the browser temporarily hides text while waiting for the requested web font.

The user may see:

heading area
[blank]

paragraph area
[blank]

followed by the final typography.

This avoids immediately displaying a visually different fallback, but it delays readable text.

FOUT

With Flash of Unstyled Text, the browser displays a fallback immediately.

For example:

Arial
↓
font downloads
↓
Brand Sans

Users can read the content sooner.

However, replacing the fallback can produce movement if the two fonts have significantly different metrics.

font-display controls font-loading behavior

The font-display descriptor belongs inside @font-face.

A common declaration is:

@font-face {
    font-family: "Brand Sans";
    src: url("/fonts/brand-sans.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

The available values include:

• auto;
• block;
• swap;
• fallback;
• optional.

The MDN font-display documentation explains how the block and swap periods determine what the browser displays while the font is loading.

font-display: swap

A widely used strategy is:

font-display: swap;

The idea is:

web font unavailable
↓
show fallback immediately
↓
web font arrives
↓
swap to web font

This is generally preferable to leaving important content unreadable for an extended period.

But there is an important detail.

font-display: swap does not eliminate layout shift

It solves one problem:

invisible text

but can expose another:

fallback font
↓
font swap
↓
different metrics
↓
layout movement

Suppose the fallback heading occupies:

2 lines
140px total height

and the final web font occupies:

3 lines
205px total height

When the swap happens, approximately 65 pixels of additional vertical space may suddenly be required.

Everything below the heading moves.

The issue is not swap itself.

The issue is the geometric difference between the two fonts.

font-display: block

With:

font-display: block;

the browser gives the web font a block period during which text may use an invisible fallback.

If the font arrives, it can then be displayed.

The advantage is that users may avoid seeing a dramatic fallback-to-web-font transition.

The disadvantage is that text may temporarily remain invisible while the font is loading.

Even invisible fallback text still participates in layout, so a metric difference can still produce movement when the final font becomes available.

font-display: fallback

fallback uses a short block period followed by a limited swap period.

Conceptually:

brief wait
↓
fallback becomes visible
↓
font may replace it
for a limited period
↓
otherwise fallback remains

This can provide a compromise between immediate fallback rendering and unlimited late font swapping.

font-display: optional

With:

font-display: optional;

the browser may decide not to perform a late swap at all.

That can be useful when visual stability and immediate rendering are more important than guaranteeing that the custom font appears during every first visit.

A slow connection may therefore produce:

fallback font for this navigation

while a later visit can use the cached web font.

That is not necessarily a failure.

It is a performance tradeoff.

There is no universal font-display value for every website

A branding-heavy landing page and a documentation website do not necessarily have the same priorities.

Consider:

Brand-critical display heading
→ custom font may matter greatly

Long technical article
→ immediate readable text may matter more

Navigation
→ stability and usability matter heavily

Decorative label
→ late swap may be unnecessary

Choose loading behavior deliberately rather than mechanically adding swap everywhere.

The fallback font is part of your performance strategy

A common declaration is:

font-family:
    "Brand Sans",
    sans-serif;

That technically provides a fallback.

But sans-serif tells the browser to choose an available generic sans-serif font.

Its dimensions may be very different from Brand Sans.

A more deliberate strategy is:

font-family:
    "Brand Sans",
    Arial,
    Helvetica,
    sans-serif;

Whether Arial is actually a good metric match depends on the target font.

The important principle is:

fallback selection
should consider geometry,
not only visual category

Metric compatibility matters

Imagine two fallback candidates.

Fallback A looks stylistically similar but is 12% wider.

Fallback B looks slightly less similar but has nearly identical character widths and vertical metrics.

During a short loading period, B may create the more stable experience.

What matters during the transition is not only:

Does this look similar?

but:

Does this occupy similar space?

This is one reason font optimization needs to be evaluated as part of the complete frontend rather than as an isolated design decision. See Reducing WordPress Front-End Page Weight for the broader asset-loading perspective.

Modern CSS can adjust fallback font metrics

CSS provides several @font-face descriptors that can help align fallback typography with a web font.

These include:

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

The MDN @font-face reference documents these metric controls alongside descriptors such as font-display, font-weight and unicode-range.

Using size-adjust

The size-adjust descriptor scales glyph outlines and the metrics associated with a font.

For example:

@font-face {
    font-family: "Adjusted Arial";
    src: local("Arial");
    size-adjust: 98%;
}

Then:

body {
    font-family:
        "Brand Sans",
        "Adjusted Arial",
        sans-serif;
}

The exact percentage should be based on the fonts being matched.

The MDN size-adjust reference explains how the descriptor scales glyph outlines and associated metrics, making it useful when harmonizing fallback and primary fonts.

Using ascent-override

Fonts also have different ascent metrics.

CSS can override them:

@font-face {
    font-family: "Adjusted Fallback";
    src: local("Arial");
    ascent-override: 92%;
}

The MDN ascent-override documentation explains how the descriptor changes the ascent metric used when laying out line boxes.

This can help align the vertical space occupied by fallback and final fonts.

Using descent-override

The same concept applies below the baseline:

@font-face {
    font-family: "Adjusted Fallback";
    src: local("Arial");
    descent-override: 24%;
}

The values need to reflect the target font’s metrics.

The objective is:

fallback line box
≈
final font line box

not merely:

fallback looks vaguely similar

Using line-gap-override

Line gaps can also differ between fonts.

For example:

@font-face {
    font-family: "Adjusted Fallback";
    src: local("Arial");
    line-gap-override: 0%;
}

See the MDN line-gap-override documentation for the CSS definition and compatibility information.

Together, the metric overrides can reduce vertical changes when the final font becomes available.

A complete metric-adjusted fallback

Conceptually, a fallback declaration might look like:

@font-face {
    font-family: "Brand Fallback";
    src: local("Arial");
    size-adjust: 101%;
    ascent-override: 91%;
    descent-override: 23%;
    line-gap-override: 0%;
}

@font-face {
    font-family: "Brand Sans";
    src: url("/fonts/brand-sans.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

body {
    font-family:
        "Brand Sans",
        "Brand Fallback",
        sans-serif;
}

Those percentages are illustrative.

Real values should be calculated from the actual fonts being used.

The goal is to make the fallback occupy approximately the same space as the final font.

font-size-adjust is another useful tool

The CSS font-size-adjust property can help maintain comparable perceived sizing when a fallback font is used.

For example:

body {
    font-family:
        "Brand Sans",
        Arial,
        sans-serif;

    font-size-adjust: 0.52;
}

The MDN font-size-adjust reference explains how the property can adjust sizing according to font metrics such as x-height.

Horizontal metrics can create vertical layout shift

This sounds contradictory until text wrapping is considered.

Suppose:

fallback text width:
680px

container:
700px

final font text width:
730px

The fallback fits on one line.

The final font does not.

The result becomes:

1 line
↓
font swap
↓
2 lines

A horizontal metric difference just created vertical movement.

This is why headings are common sources of font-related CLS.

Large headings amplify font differences

Consider:

font-size: 72px;
font-weight: 700;

A small percentage difference in glyph widths can become substantial across a long heading.

The result may change from:

two lines

to:

three lines

and push an entire hero section downward.

Large display typography deserves particular attention during performance testing.

Responsive typography can make the problem worse

Suppose a heading uses:

font-size: clamp(
    2.5rem,
    6vw,
    6rem
);

At some viewport widths, the fallback and final font may wrap identically.

At others, they may differ by an entire line.

Therefore:

desktop looks stable

does not prove:

mobile is stable

or vice versa.

Test font swapping across intermediate viewport widths.

Navigation is especially sensitive

Navigation items often live inside tightly constrained horizontal layouts.

For example:

Services
About
Resources
Pricing
Contact

A wider final font can cause:

• different spacing;
• items to wrap;
• the navigation to overflow;
• buttons to move;
• a breakpoint to behave unexpectedly.

A seemingly tiny typographic difference can therefore affect the entire header.

Buttons can shift too

Consider:

Get Started

If the button width depends on text plus padding:

width =
text width
+
left padding
+
right padding

then changing the font changes the button width.

That can move adjacent elements.

This matters particularly in:

• hero CTA groups;
• navigation;
• pricing cards;
• forms;
• toolbars.

Font weight is another network resource

A site might use:

400
500
600
700
800

If each weight is a separate file, the browser may need several resources.

For example:

brand-regular.woff2
brand-medium.woff2
brand-semibold.woff2
brand-bold.woff2
brand-extrabold.woff2

Loading five files because a design system uses every available weight is not free.

The same principle applies to the rest of the WordPress frontend. Unnecessary assets should be identified and removed rather than downloaded on every page. See How to Remove Unused WordPress Scripts for the corresponding script-loading problem.

Do not declare font weights you do not use

If the site only uses:

400
700

you may not need:

100
200
300
500
600
800
900

Fewer resources mean:

• less data;
• fewer font requests;
• simpler preload decisions;
• less font-loading complexity.

Google’s guide to reducing web font size covers techniques such as reducing unnecessary font data and splitting fonts according to the character sets a page actually needs.

Use WOFF2 for modern web-font delivery

For modern browser delivery, WOFF2 is normally the format to evaluate first.

A typical declaration is:

@font-face {
    font-family: "Brand Sans";
    src: url("/fonts/brand-sans.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

Avoid shipping unnecessarily large font resources when a properly prepared web font can provide the same typography more efficiently.

Variable fonts can reduce the number of files

A variable font can represent a range of weights inside one resource.

Instead of:

400.woff2
500.woff2
600.woff2
700.woff2

you might use:

brand-variable.woff2

with:

@font-face {
    font-family: "Brand Sans";
    src: url("/fonts/brand-variable.woff2")
        format("woff2");
    font-weight: 400 700;
    font-style: normal;
    font-display: swap;
}

That can simplify delivery.

But one variable font is not automatically smaller than every possible static-font configuration.

If the site uses only one weight, a variable font containing a large range may be unnecessary.

Measure the actual resources required by the design.

Subsetting can reduce font size

Fonts may contain glyphs for:

• Latin;
• Latin Extended;
• Cyrillic;
• Greek;
• Vietnamese;
• other writing systems.

If a site genuinely requires only a subset, serving every glyph in the complete family may waste bandwidth.

Font subsetting can reduce file size.

But do not remove characters your content actually needs.

A multilingual site needs a multilingual strategy.

unicode-range can split font resources

The unicode-range descriptor can tell browsers which characters a particular font resource covers.

For example:

@font-face {
    font-family: "Brand Sans";
    src: url("/fonts/brand-latin.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
    unicode-range:
        U+0000-00FF;
}

More sophisticated configurations can divide a family into language-specific resources.

The browser can then avoid downloading subsets that are not needed by the page.

Self-hosting gives you more control

A remotely hosted font may involve:

HTML
↓
third-party stylesheet
↓
font declaration discovered
↓
third-party font request
↓
font becomes available

A self-hosted configuration can be:

HTML
↓
your CSS
↓
your WOFF2 file

Self-hosting can give you direct control over:

• font files;
• cache headers;
• preloading;
• subsets;
• font-display;
• resource URLs;
• versioning.

For the practical WordPress implementation, see Self-Hosting Google Fonts in WordPress.

Self-hosting does not automatically eliminate layout shift

This is an important distinction.

Changing:

remote font provider
↓
local /fonts/ directory

does not make font metrics disappear.

The local font still needs to become available.

If the browser renders a metrically different fallback first, the eventual swap can still move the layout.

Self-hosting improves control.

It does not automatically guarantee visual stability.

For the wider architectural comparison, see Self-Hosted Fonts vs. Google Fonts in WordPress.

Self-hosting can also reduce third-party dependencies

When a font comes from another origin, the browser may need additional connection work and the website depends on an external provider for part of its visual presentation.

This overlaps with a broader WordPress architectural question: which assets should remain under site control and which should be delivered by third parties?

See CDN vs. Self-Hosted Assets in WordPress for that wider comparison.

Third-party resources can also have privacy implications beyond raw performance. See WordPress Privacy and Third-Party Requests when evaluating externally hosted fonts and other external assets.

Preloading can make critical fonts available sooner

A font is often discovered only after:

HTML downloaded
↓
CSS downloaded
↓
CSS parsed
↓
@font-face discovered
↓
font requested

A preload can move discovery earlier.

For example:

<link
    rel="preload"
    href="/fonts/brand-regular.woff2"
    as="font"
    type="font/woff2"
    crossorigin
>

This tells the browser that the resource should be discovered early.

The MDN preload documentation explains how rel="preload" allows resources required soon after page load to be fetched earlier.

Preload only genuinely critical fonts

Do not transform:

preload important font

into:

preload every font file

Early network bandwidth is limited.

Preloading:

regular
medium
semibold
bold
italic
bold italic
display regular
display bold

can compete with:

• critical CSS;
• the LCP image;
• essential JavaScript;
• other high-priority resources.

Usually only fonts required immediately above the fold deserve consideration for preload.

A preload must match the actual font request

If you preload:

/fonts/brand.woff2

but CSS later requests:

/assets/fonts/brand.woff2?v=2

the browser may not reuse the preload as intended.

Likewise, incorrect:

• URLs;
• CORS configuration;
• resource types;
• credentials modes;

can undermine the optimization.

Always inspect the browser Network panel rather than assuming the preload is being reused.

Do not preload fonts that are not used above the fold

Suppose a display font appears only in the footer.

Preloading it at document start may give a low-value resource early priority.

The question is not:

Is this font used somewhere?

It is:

Does the browser need this font
during the initial render?

That distinction matters.

The same principle applies to other frontend resources. Loading every script and stylesheet globally can increase work without improving the current page. wp_enqueue_scripts Explained covers WordPress’s frontend asset-loading model in detail.

Preconnect can help with third-party font origins

When fonts must come from another origin, connection setup itself has a cost.

A page may need:

DNS
↓
TCP
↓
TLS
↓
request

before the font can be downloaded.

A carefully chosen preconnect can establish the connection earlier.

For example:

<link
    rel="preconnect"
    href="https://fonts.gstatic.com"
    crossorigin
>

Every resource hint should still have a reason.

Adding hints for origins the page does not actually need merely adds more instructions for the browser to process.

Cache fonts aggressively when filenames are versioned

Font files usually change infrequently.

A versioned resource such as:

brand-sans-v3.woff2

can often use a long browser cache lifetime.

Then:

first visit
→ font downloaded

later visit
→ font available from cache

This can dramatically reduce the loading problem for repeat visitors.

But first-visit performance still matters.

A warm cache should never be used to ignore cold-cache behavior.

Test fonts with the cache disabled

During development, your browser may already have every font cached.

The site appears:

instant
stable
perfect

A new visitor may instead see:

fallback
swap
movement

Use browser developer tools to test with caching disabled and network throttling enabled.

Slow networks expose font problems

A font that arrives in:

40ms

on a developer’s connection may arrive much later on:

• mobile data;
• congested Wi-Fi;
• high-latency connections;
• distant hosting infrastructure;
• resource-heavy pages.

The longer the fallback remains visible, the more noticeable the eventual swap becomes.

Performance testing needs realistic conditions.

Do not test only one device

Font behavior depends on:

• available system fonts;
• operating system;
• browser;
• viewport width;
• network speed;
• cache state.

A fallback stack may resolve differently on:

macOS
Windows
Android
iOS
Linux

That means the geometry of the fallback can differ too.

System fallback stacks need deliberate testing

A declaration such as:

font-family:
    "Brand Sans",
    Arial,
    sans-serif;

may not behave identically everywhere.

If Arial is unavailable, another font may be selected.

A system-oriented stack such as:

font-family:
    "Brand Sans",
    -apple-system,
    BlinkMacSystemFont,
    "Segoe UI",
    sans-serif;

can produce different fonts on different platforms by design.

That can be excellent for native-looking fallback typography, but it also means you should test metric behavior on representative systems.

Font synthesis can change what users see

If a requested weight is unavailable, browsers may synthesize a bold or italic appearance.

For example:

font-weight: 700;

while only:

font-weight: 400;

is actually loaded.

That can create typography that differs from the intended design.

Declare the font faces and ranges that the design genuinely uses.

Incorrect @font-face declarations can cause unnecessary downloads

Suppose you declare separate files poorly or assign incorrect weight metadata.

The browser may select resources differently from what you expect.

A correct family might use:

@font-face {
    font-family: "Brand Sans";
    src: url("/fonts/brand-regular.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

@font-face {
    font-family: "Brand Sans";
    src: url("/fonts/brand-bold.woff2")
        format("woff2");
    font-weight: 700;
    font-style: normal;
    font-display: swap;
}

Then CSS can request:

font-weight: 400;

or:

font-weight: 700;

predictably.

Hero sections deserve special testing

The hero often contains:

• the largest heading;
• a custom display font;
• CTA buttons;
• an LCP image;
• carefully aligned visual elements.

That makes it a common place for font loading to cause visible instability.

Test:

heading before font load
heading after font load

button positions before
button positions after

hero height before
hero height after

If those values change substantially, investigate the fallback metrics.

Do not solve font CLS with arbitrary fixed heights

A tempting workaround is:

.hero-title {
    height: 200px;
}

This may hide movement at one viewport.

At another viewport:

text needs 240px
↓
overflow

or:

text needs 120px
↓
80px empty space

Fixed heights are rarely the correct general solution for responsive text.

Fix the typography and loading behavior instead.

min-height can occasionally reserve intentional space

There are cases where a predictable component can reasonably reserve minimum space:

.hero-copy {
    min-height: 18rem;
}

But this should come from the component design, not from hiding a font-loading defect.

The first question should still be:

Why are the fallback and final layouts
so different?

Letter spacing can amplify differences

A heading with:

letter-spacing: -0.04em;

may behave differently across typefaces.

Tracking interacts with glyph widths.

When comparing fallback and final typography, test the actual production styles:

• font size;
• weight;
• letter spacing;
• line height;
• container width;
• text transform.

Testing fonts in isolation is not enough.

Line-height affects vertical stability

Consider:

line-height: normal;

The resulting line box can depend on font metrics.

A deliberate line height:

line-height: 1.4;

can make typography more predictable, although it does not eliminate every difference between fonts.

For important text components, explicitly defining line height is usually easier to reason about than relying blindly on normal.

Icon fonts can create their own loading problems

Web fonts are not limited to text families.

Some interfaces use icon fonts.

If the icon font loads late:

• icons may be missing temporarily;
• fallback glyphs may appear;
• buttons may change dimensions;
• controls may move.

Where practical, SVG icons often provide more predictable geometry because their dimensions can be explicitly controlled.

Google’s font performance guidance also recommends considering SVG alternatives to icon fonts where appropriate.

Third-party font stylesheets add another discovery step

A typical remote font flow can be:

HTML
↓
request remote CSS
↓
remote CSS arrives
↓
browser discovers font URL
↓
font request begins

Every step consumes time.

Self-hosting can simplify that chain, particularly when the site already has efficient static asset delivery.

See Self-Hosted Fonts vs. Google Fonts in WordPress for the broader comparison.

WordPress themes can load fonts from several places

A WordPress site may receive fonts from:

• the active theme;
• a child theme;
• a page builder;
• block styles;
• a typography plugin;
• another plugin;
• custom CSS;
• third-party embeds.

That means optimization should begin with an inventory.

Do not assume the font visible in the design is the only font resource being downloaded.

The block editor can also introduce styles that affect frontend typography and layout. For the wider relationship between block-generated markup and CSS, see WordPress Block Editor CSS, Explained.

Audit the network panel

Open browser developer tools and filter requests by:

Font

Look for:

• how many files load;
• their sizes;
• their origins;
• when they start downloading;
• whether they are cached;
• whether unnecessary weights load;
• whether duplicate families load.

A site can accidentally load the same font from both:

theme
and
page builder

or:

local source
and
remote font provider

Removing duplication is more useful than applying increasingly elaborate CSS while downloading the same typeface twice.

This type of resource inventory is also central to Reducing WordPress Front-End Page Weight.

Check which CSS requested each font

The network initiator chain can help identify where a font originates.

For example:

theme.css
→ Inter 400

builder.css
→ Inter 400

plugin.css
→ Inter 600

This immediately reveals that font ownership is fragmented.

A cleaner architecture centralizes typography where possible.

Load WordPress styles through the enqueue system

When theme or plugin CSS defines your font faces, use WordPress’s asset system rather than scattering stylesheet tags through templates.

For example:

function example_enqueue_styles() {

    wp_enqueue_style(
        'example-fonts',
        get_theme_file_uri(
            '/assets/css/fonts.css'
        ),
        array(),
        '1.0.0'
    );
}

add_action(
    'wp_enqueue_scripts',
    'example_enqueue_styles'
);

The official wp_enqueue_scripts hook documentation identifies this as the frontend hook used for enqueuing both scripts and styles.

The official wp_enqueue_style() documentation covers WordPress’s dependency-aware stylesheet loading API.

For a complete WordPress-specific explanation, see wp_enqueue_scripts Explained.

Self-hosting Google Fonts in WordPress

For WordPress sites using Google Fonts, moving font files locally can reduce external dependencies and provide greater control over the loading strategy.

A local structure might be:

/wp-content/themes/example/
    assets/
        fonts/
            inter-regular.woff2
            inter-bold.woff2

Then:

@font-face {
    font-family: "Inter";
    src: url("../fonts/inter-regular.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

For the complete implementation, see Self-Hosting Google Fonts in WordPress.

Font optimization is only one part of WordPress performance

A stable font strategy cannot compensate for:

• enormous images;
• blocking third-party scripts;
• poor server response times;
• unnecessary JavaScript;
• layout dimensions that are not reserved;
• heavy frontend plugin stacks.

Performance needs to be evaluated as a system.

Start with Reducing WordPress Front-End Page Weight when the problem extends beyond typography.

If scripts are being loaded globally despite being needed only on specific templates, continue with How to Remove Unused WordPress Scripts.

If external widgets, videos or social content dominate the network waterfall, review Why Third-Party Embeds Slow Down WordPress.

Measure before and after changing fonts

A useful optimization workflow is:

measure
↓
identify font-related movement
↓
change one variable
↓
measure again
↓
compare

Do not change:

hosting
font-display
font files
preloads
fallback stack
line-height
CSS
CDN

simultaneously and then attempt to guess which change mattered.

Controlled changes produce useful evidence.

Use browser performance tools to inspect layout shifts

Modern browser development tools can help identify layout-shift events.

Record the initial page load and inspect:

• layout-shift markers;
• affected elements;
• font requests;
• request timing;
• rendering behavior.

If a heading moves at almost exactly the moment a font finishes downloading, you have a strong clue.

Google’s CLS optimization guide provides a broader methodology for finding and fixing layout instability.

Test with JavaScript disabled when appropriate

If you suspect font loading but the page also contains substantial JavaScript, temporarily reducing other variables can help isolate the cause.

The objective is to distinguish:

font swap
from
dynamic DOM insertion
from
animation
from
late component initialization

Several things can move simultaneously during a modern page load.

Use the CSS Font Loading API for diagnostics when needed

Browsers expose font-loading information through the Font Loading API.

For example:

document.fonts.ready.then(() => {
    console.log("Fonts ready");
});

Or:

document.fonts.check(
    '16px "Brand Sans"'
);

The MDN CSS Font Loading API documentation explains how scripts can monitor and control font loading when more advanced diagnostics are necessary.

This can be useful during debugging.

It should not become an excuse to hide the entire website until every decorative font has loaded.

Avoid JavaScript font-loading gates unless they solve a real problem

An implementation such as:

body {
    opacity: 0;
}

.fonts-loaded body {
    opacity: 1;
}

turns a font-loading issue into an entire-page visibility issue.

Users now wait for typography before they can see anything.

Prefer resilient CSS and sensible fallbacks.

Do not animate the font swap to disguise it

A transition does not solve metric instability.

If the layout changes, it still changes.

Performance work should address the cause rather than applying visual camouflage.

CLS can vary between pages

A font strategy may be stable on:

homepage

and unstable on:

long article title

because text content changes line wrapping.

Test representative templates:

• homepage;
• landing pages;
• blog posts;
• archives;
• product pages;
• checkout;
• account pages.

Long titles are excellent stress tests

A short heading:

About Us

may fit comfortably in every font.

A title such as:

Everything You Need to Know About Building
High-Performance WordPress Websites

is far more likely to expose metric differences.

Test realistic worst-case content rather than only the shortest design mockup.

Localization can expose font-layout problems

Translated text may be considerably longer or shorter than the original language.

A button that reads:

Save

may become a much longer label in another language.

Combined with different fallback behavior, this can create layout problems that never appeared in the original design.

Multilingual typography should therefore be tested with actual translated content.

Fallback fonts may not contain every required glyph

If the selected fallback lacks a character, the browser may use another fallback for that glyph.

A single line can therefore contain glyphs from multiple fonts.

This is particularly relevant for:

• multilingual websites;
• symbols;
• currency signs;
• special punctuation;
• technical notation.

Font subsetting and fallback design should account for the actual character sets the site uses.

Do not optimize fonts only for Lighthouse

A laboratory test is useful.

It is not the entire user experience.

Also consider:

• real devices;
• real network conditions;
• real content lengths;
• repeat visits;
• different operating systems;
• different viewport widths.

The objective is not merely to silence an audit.

It is to produce typography that loads quickly and remains visually stable.

A practical font-loading strategy

A strong starting architecture is:

1. Use only necessary font families

2. Use only necessary weights

3. Serve efficient WOFF2 files

4. Self-host when it improves control

5. Choose font-display deliberately

6. Define a good fallback stack

7. Match fallback metrics where useful

8. Preload only critical fonts

9. Cache font files appropriately

10. Test cold-cache loading

11. Test slow networks

12. Test multiple viewport widths

13. Measure layout shifts

14. Recheck after typography changes

For WordPress sites, this should be part of a wider asset strategy rather than an isolated optimization. CDN vs. Self-Hosted Assets in WordPress covers the delivery architecture, while wp_enqueue_scripts Explained covers how those assets should enter the frontend.

Example: weak font configuration

Consider:

@font-face {
    font-family: "Brand";
    src: url("brand.ttf");
}

body {
    font-family:
        "Brand",
        sans-serif;
}

Potential problems include:

• inefficient font delivery;
• undefined loading strategy;
• generic fallback;
• unknown metric compatibility;
• no deliberate performance strategy.

Example: improved configuration

A better configuration might be:

@font-face {
    font-family: "Brand";
    src: url("/fonts/brand-regular.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

@font-face {
    font-family: "Brand";
    src: url("/fonts/brand-bold.woff2")
        format("woff2");
    font-weight: 700;
    font-style: normal;
    font-display: swap;
}

body {
    font-family:
        "Brand",
        Arial,
        sans-serif;
    line-height: 1.5;
}

Then improve further by testing whether Arial is actually a suitable metric match.

Example: metric-adjusted fallback strategy

For a carefully optimized implementation:

@font-face {
    font-family: "Brand Fallback";
    src: local("Arial");
    size-adjust: 99%;
    ascent-override: 92%;
    descent-override: 24%;
    line-gap-override: 0%;
}

@font-face {
    font-family: "Brand";
    src: url("/fonts/brand.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

body {
    font-family:
        "Brand",
        "Brand Fallback",
        sans-serif;
}

Again, the percentages must come from the real target and fallback fonts.

The technique matters more than the example numbers.

How to diagnose font-related layout shift step by step

Use this workflow:

1. Open the page with cache disabled

2. Throttle the network

3. Reload the page

4. Watch typography before the font arrives

5. Identify visible movement

6. Inspect font requests

7. Identify fallback font

8. Compare fallback and final wrapping

9. Check line-height

10. Check font weights

11. Check duplicate font requests

12. Review font-display

13. Test a closer fallback

14. Consider metric overrides

15. Retest CLS

This turns a vague complaint such as:

"the page jumps"

into a specific diagnosis.

How to tell whether a font is really causing the shift

Temporarily use a system font only:

body {
    font-family: Arial, sans-serif;
}

Then test again.

If the movement disappears, font loading becomes a strong suspect.

If the movement remains, investigate other sources such as:

• images;
• lazy-loaded sections;
• JavaScript;
• cookie banners;
• animations;
• dynamic headers.

Third-party components are particularly easy to misdiagnose because they can inject their own fonts, styles, iframes and JavaScript. Why Third-Party Embeds Slow Down WordPress explains how to inspect that wider request chain.

How to prioritize fixes

Do not spend hours perfecting a tiny footer-label font swap while the hero moves by half the viewport.

Prioritize:

large visible shifts
↓
above-the-fold shifts
↓
frequently viewed templates
↓
interactive elements
↓
smaller cosmetic movement

Performance work is an allocation problem as much as a technical one.

Do not confuse fewer requests with automatically better performance

Replacing several small font files with one enormous font file does not automatically improve the site.

Likewise:

3 requests
≠
automatically fast

8 requests
≠
automatically slow

Evaluate:

• transferred bytes;
• compression;
• cacheability;
• discovery timing;
• priority;
• actual usage;
• connection overhead.

This principle is discussed more broadly in Reducing WordPress Front-End Page Weight.

External font providers can affect privacy as well as performance

When the browser requests a font from a third-party origin, the request leaves the site’s own infrastructure.

That means the architectural decision can involve more than loading speed.

Depending on the provider and implementation, teams may also need to consider:

• external network requests;
• privacy requirements;
• availability dependencies;
• content security policies;
• organizational compliance requirements.

For that wider issue, see WordPress Privacy and Third-Party Requests.

A WordPress font optimization checklist

Before considering the typography implementation finished, verify:

• Every loaded font family is actually used.
• Every downloaded weight is actually required.
• WOFF2 is used where appropriate.
• Duplicate font requests have been removed.
• The source of each font request is known.
• font-display has been chosen deliberately.
• The fallback stack has been tested.
• Fallback and final font metrics are reasonably close.
• Critical fonts are discovered early enough.
• Only genuinely critical fonts are preloaded.
• Font caching is configured appropriately.
• Large headings have been tested during font swap.
• Navigation has been tested during font swap.
• Buttons have been tested during font swap.
• Mobile layouts have been tested.
• Intermediate viewport widths have been tested.
• Cold-cache behavior has been tested.
• Slow-network behavior has been tested.
• Different operating systems have been considered.
• Layout shifts have been measured rather than guessed.
• Remote font origins have been reviewed.
• Unused font families and weights have been removed.
• WordPress is not loading duplicate typography through multiple plugins or themes.

Related guides

• Self-Hosting Google Fonts in WordPress
• Self-Hosted Fonts vs. Google Fonts in WordPress
• Reducing WordPress Front-End Page Weight
• CDN vs. Self-Hosted Assets in WordPress
• wp_enqueue_scripts Explained

Final recommendation

Web fonts cause layout shift when the typography used during initial rendering occupies different space from the typography used after the final font becomes available.

The fundamental problem is:

fallback metrics
≠
web-font metrics

A faster font download can reduce the time during which the mismatch is visible, but speed alone does not eliminate the underlying geometric difference.

Start by reducing the number of font families and weights the website actually needs.

Serve efficient font resources, remove duplicate requests and decide whether self-hosting gives you better control over delivery. Self-Hosting Google Fonts in WordPress covers the implementation, while Self-Hosted Fonts vs. Google Fonts in WordPress covers the architectural tradeoffs.

Then choose font-display deliberately.

swap makes text available quickly but can still produce movement. fallback and optional provide different compromises when a late font replacement is undesirable.

Most importantly, treat the fallback font as part of the design system rather than an emergency browser default.

Choose a fallback with similar proportions and, where appropriate, evaluate modern CSS tools such as:

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

to make the fallback geometry closer to the final typeface.

Preload only fonts that genuinely participate in the initial render.

Cache them effectively, test with a cold cache and reproduce slow-network conditions instead of evaluating performance exclusively from a development machine where every asset is already cached.

On WordPress, also verify where the fonts actually originate. Themes, page builders, block styles and plugins can all contribute frontend CSS and external resources. Use the normal enqueue architecture described in wp_enqueue_scripts Explained, and inspect the wider asset footprint with Reducing WordPress Front-End Page Weight.

Finally, test typography across real content and multiple viewport widths.

The most stable font-loading architecture is not:

hide text
until everything is perfect

and it is not:

load every font immediately

It is:

small font payload
+
early critical discovery
+
readable fallback
+
compatible metrics
+
controlled font swap
+
real-world testing
=
stable typography

Web typography should enhance the design without forcing the rest of the page to rearrange itself when the font finally arrives.