Why Do Your Fonts Still Cause Layout Shift When the Page Scores Well?

Why do your fonts still cause layout shift when the page scores well?

Because the shift happens in the gap between the fallback font rendering and the web font arriving, and that gap depends on a visitor's network rather than on your test machine. A lab run on a fast connection often never sees it. A real visitor on a slow connection sees the whole page jump.

This is one of the most common gaps between a good score and a bad experience. The page is fine when you check it. Field data says otherwise, and nobody can reproduce the problem on demand because the problem is a race condition between two things you do not control.

Fonts are worth understanding properly because they are one of the few layout shift causes with a genuinely clean fix. Images without dimensions, injected banners, and late-loading embeds all need structural changes. Font shift can usually be solved with a handful of decisions in your CSS.

What does font-display actually control?

It controls what the browser shows while it waits. Google's own guidance on web.dev puts it plainly: font-display "informs the browser how it should proceed with text rendering when the associated web font has not loaded." Everything else about font shift follows from that single decision.

The mechanism behind the shift is simple once you see it. Google states that "the practice of font swapping has the potential to cause layout shifts and impact Cumulative Layout Shift (CLS)," and that "these layout shifts occur when a web font and its fallback font take up different amounts of space on the page." The browser draws text in one font, then redraws it in another, and if the two occupy different space, everything below moves.

So there are only two ways to eliminate font shift. Either never swap, or make the two fonts take up the same space. Every technique in this article is one of those two things wearing different clothes.

Which font-display value should you choose?

It depends on whether you would rather risk a shift or risk not using your font. Google documents five values, and the meaningful choice for most sites is between swap, which shows fallback text immediately, and optional, which gives the font a brief window and otherwise skips it for that visit.

The full set, as Google documents it, differs by block period and swap period. Auto varies by browser. Block waits two to three seconds with an infinite swap period. Swap blocks for zero milliseconds with an infinite swap period. Fallback blocks for one hundred milliseconds then allows three seconds of swapping. Optional blocks for one hundred milliseconds with no swap period at all.

For performance, Google's recommendation is unambiguous. It says to "use font-display: optional," calling it "the most 'performant' approach: text render is delayed for no longer than 100ms and there's assurance that there isn't font-swap related layout shifts." The cost is that a slow-arriving font simply does not get used for that visit.

If you need the text visible immediately and are willing to manage the risk, Google's guidance is to "use font-display: swap but make sure to deliver the font early enough that it does not cause a layout shift." That second clause is the part everybody drops. Swap without delivery speed is just choosing to have the shift.

My own default on client work is optional for body text and swap for display type that appears above the fold, on the reasoning that a heading in the wrong face for one visit is a smaller sin than a body copy reflow that moves the whole article. Reasonable people disagree, and the right answer depends on how distinctive your typeface actually is.

Does preloading fonts fix it?

It helps, and it is not free. Preloading tells the browser to start fetching the font early instead of discovering it after the CSS is parsed, which narrows the window in which a swap can happen. For a font that is definitely used above the fold, that is usually worth doing.

Google is direct about the trade. It warns that "although preload is highly effective at making fonts discoverable early in the page load process, this comes at the cost of taking away browser resources from the loading of other resources." Preload everything and you have not prioritised anything, you have simply made the queue longer while making it feel urgent.

There is also a specific gotcha worth knowing: Google notes that "preload ignores unicode-range declarations." If you have split your font into subsets so browsers only download the character ranges they need, preloading undoes some of that cleverness. Preload the one or two font files that genuinely appear immediately, and leave the rest to normal discovery.

Why does the fallback font matter as much as the web font?

Because the size of the shift is the difference between them. If your fallback renders at nearly the same width and line height as your web font, the swap is nearly invisible even when it happens. If the fallback is much narrower, every line rewraps and every block below moves.

This is the part most people never touch, and it is where the remaining wins are. Google points to the size-adjust family for exactly this, noting that "to reduce the CLS impact, you can use the size-adjust attributes." Those descriptors let you scale and adjust the metrics of the fallback so it occupies close to the same space as the real font.

The practical version is to define a local fallback face with adjusted metrics rather than accepting whatever the system serves. It takes an hour of fiddling and it converts a visible jump into a subtle change of shape. If you only do one advanced thing about fonts this quarter, this is the one with the best ratio of effort to result.

Does self-hosting fonts help?

Less than the internet believes. The theory is that removing a third-party connection removes a round trip, and Google acknowledges that "on paper, using a self-hosted font should deliver better performance as it eliminates a third-party connection setup." The honest part comes next.

Google continues that "in practice, the performance differences between these two options is less clear cut," and recommends confirming your site uses a content delivery network and HTTP/2 before self-hosting. That is a meaningful caveat. Moving a font onto a slower origin than the one it came from is a downgrade dressed as an optimisation.

So treat self-hosting as a decision with other reasons attached. Control, privacy, and not depending on a third party are all legitimate grounds. Expecting it to fix your layout shift on its own is not, because the shift is caused by the swap rather than by where the file lives.

How do you handle this on a Webflow site?

The same way as anywhere else, because this is browser behaviour rather than platform behaviour. Your decisions are which faces you use, where they load from, what happens while they load, and how close your fallback sits to the real thing. The platform changes the interface for those decisions, not the decisions themselves.

I could not verify Webflow's current font handling against their own documentation while writing this, because their help pages were not reachable, so I am not going to describe specific settings or menu paths that may have changed. Check Webflow's own documentation for how fonts are added and what control you have over loading behaviour on your plan, because that is the kind of detail that moves.

What I would do regardless of platform is reduce the number of faces first. Every weight and style is another file and another chance to shift. Most sites I audit are loading four or five weights and genuinely using two. That single cut usually does more for real-world stability than any amount of clever loading strategy, and it costs nothing.

How do you tell whether fonts are actually your CLS problem?

Look at field data rather than a lab score, because this is a problem that only appears on slow connections. If your lab test is clean and your field numbers are not, fonts are a reasonable first suspect, along with anything else that loads late and changes size.

Then reproduce it deliberately. Throttle the connection in your browser's developer tools, reload, and watch the text. If you see the page settle into a different shape after a beat, you have found it with your own eyes, which is worth more than any score. Do it on a long article page rather than the homepage, because that is where reflow travels furthest.

For the broader diagnosis, I have written about reducing cumulative layout shift on a Webflow site and about reading real field data rather than lab scores. Fonts are one cause among several, and fixing them while ignoring an injected banner will not move your numbers.

What should you do next?

Open your site on a throttled connection and watch the text load. That takes two minutes and it tells you immediately whether you have a font problem or an imagined one. If nothing moves, spend your time elsewhere, because there is always something else on the list.

If something does move, start with the cheapest fixes in order. Cut the font weights you are not really using. Choose font-display deliberately rather than inheriting whatever your setup defaulted to. Preload only the faces that appear above the fold. Then, if it still matters, adjust your fallback metrics so the swap stops costing you space. I have written more broadly about working through Core Web Vitals across a whole site rather than page by page.

If you have field data that looks bad and a lab score that looks fine, and you are not sure which of them to believe, that is usually an hour of investigation rather than a project. Reach out if you want help working out which one is lying.