Text that changes line breaks when a custom font arrives can push buttons and surrounding content around the page. First prove that the font swap causes the shift, then adjust the fallback and loading strategy. A font loading successfully does not mean it loads without a layout cost.
Capture the actual shift
Choose a public page with a repeatable heading jump. Record a cold-cache load in browser performance tools, using the same viewport and network conditions for comparisons. Look at the affected text before and after the web font is applied, then correlate the layout-shift entry with the font request.
Check the computed font family, weight and style on that exact element. If the font never loads, begin with the custom-font delivery guide. If an image or banner expands at the same time, isolate that cause instead of attributing every movement to typography.
Compare metrics before changing preload
| Difference |
What to inspect |
| Heading gains a line |
Fallback width, font weight and available container width |
| Lines keep their count but height changes |
Font ascent, descent and line-height behavior |
| Only bold text moves |
Missing or incorrectly mapped weight |
| Icons become text briefly |
Icon-font strategy, not ordinary body-font fallback |
The web.dev font guidance describes tradeoffs between font-display strategies and metric-adjusted fallbacks. A fast visible fallback with swap can still shift when the final font arrives. Optional can avoid a late swap in some conditions, but it can also leave the fallback visible for that visit.
Cause: Shift aligns with font swap. Metrics: Compare actual font pair. Readability: Text remains usable. Evidence: Lab result is not field data. Explanatory checklist, not a customer test result.
Make one measurable change
Start by choosing a fallback with similar character widths and line metrics. If using size-adjust, ascent-override, descent-override or line-gap-override, derive the values for the actual font pair and validate them visually. Copying percentages from an unrelated typeface can make the mismatch worse.
Keep the page's intended line height explicit where appropriate. Verify the real font weight file is used rather than an unintended synthesized variant. Test headings, buttons, navigation and long translated strings, not just one English paragraph.
Preload only a genuinely critical font when the request timeline shows it is discovered late. Ensure the URL, format and request behavior match the font the page actually uses. Preloading every family and weight can compete with more important resources without fixing a metric mismatch.
The CLS optimization reference also covers reserving space and non-font causes. Hiding all text until fonts arrive is not a useful default repair for a readable content page.
Retest the states visitors encounter
Compare cold and warm cache runs at the same desktop and mobile sizes. Include a slow connection and a missing-font fallback test on staging. Read the page and operate its primary action in each state. A visually stable heading that becomes unreadable or clips at a narrow width is still a regression.
Record the measured shift entries and the exact change responsible. Lab results from a controlled test should not be presented as an immediate improvement in field Core Web Vitals, which reflect real visits over their reporting window.
HandL WP can investigate font-related layout movement with the page URL, affected element, font pair and before/after trace. Keep the final decision grounded in readable text and stable controls, not a performance score alone.
References reviewed October 11, 2026. Examples are explanatory, not customer test results.