Do web fonts really block rendering and harm your Core Web Vitals?

Why do web fonts slow down page rendering?

Modern browsers download web fonts when the rendering engine detects that a DOM element needs them. This behavior creates a render delay: the text remains invisible until the font is available (FOIT, Flash of Invisible Text) or displays in a system font before switching (FOUT, Flash of Unstyled Text).

The issue worsens when the CSS file containing the @font-face is itself blocking or loaded from a third-party CDN. Every millisecond counts for First Contentful Paint (FCP), and a blocking font can delay the LCP by several hundred milliseconds on mobile.

What does it mean to load a font asynchronously?

Asynchronous loading means avoiding font retrieval from blocking the browser's main thread. Two dominant approaches are: font-display: swap in the @font-face, which displays text immediately in a system font and then switches, or the JavaScript Font Loading API that gives full control over timing.

Google recommends this approach because it allows text content to appear quickly, even if the custom font takes time to arrive. It's a compromise between user experience and brand visual identity.

How are Core Web Vitals related to this?

FCP and LCP are directly affected by blocking resources at the start of loading. A web font that blocks rendering delays the moment when the browser can paint meaningful content on the screen. On mobile with a slow connection, the delta can explode.

PageSpeed Insights audits often report unoptimized web fonts under "Eliminate render-blocking resources". A site that loads 3-4 fonts without a preloading strategy or font-display may lose 500 ms on LCP, which is enough to switch from green to orange.

• Web fonts block rendering if they are loaded synchronously in the critical path
• font-display: swap is the simplest solution to avoid FOIT and display text immediately
• Preloading critical fonts with rel="preload" reduces retrieval time if they are on the same domain
• Limiting the number of variants (weights, styles) reduces overall size and the number of HTTP requests
• WOFF2 is the most compact format and has almost universal browser support

Is this recommendation consistent with real-world observations?

Yes, PageSpeed tests and Lighthouse audits consistently show that unoptimized web fonts degrade FCP and LCP. Sites applying font-display: swap or font-display: optional gain an average of 200-400 ms on mobile, as documented in public case studies.

However, Google remains vague on what constitutes a "critical" font that would justify preloading. An e-commerce site with a strong visual identity has different constraints than a corporate blog. [To be verified] whether systematic preloading of all fonts improves or degrades metrics depending on the context.

What nuances should be added to this directive?

Asynchronous loading with font-display: swap creates a visible text flash with each page load. On a high-converting landing page, this flash can harm quality perception and increase bounce rates. Some brands prefer a short FOIT rather than an unattractive FOUT.

Moreover, preloading a font with rel="preload" makes it blocking for the browser: it will wait for its retrieval before moving on. If the font is heavy or hosted on a slow CDN, preloading may degrade FCP instead of improving it. It should be tested on a case-by-case basis.

In what cases does this rule not apply?

If your site uses only system fonts (system-ui, -apple-system, native Roboto), this issue disappears. System fonts are already present on the device and do not create any additional HTTP requests.

Web applications that primarily operate in offline mode and where users stay for long periods (SaaS, back offices) may tolerate an initial FOIT if the font is then effectively cached by the service worker or HTTP cache. The cost of the first load is amortized over the session duration.

What should you do to optimize font loading in practice?

Start by adding font-display: swap to all your @font-face declarations. This is the simplest and most effective solution to prevent text from being invisible. The browser will immediately display the content in a system font and then switch to the custom font as soon as it arrives.

Next, identify the fonts that appear above-the-fold (header, hero, first paragraphs) and preload them with <link rel="preload" as="font" type="font/woff2" crossorigin>. Be cautious: only preload truly critical variants (regular + bold maximum), otherwise, you saturate the initial bandwidth.

What mistakes should be avoided when optimizing web fonts?

Do not preload all of your fonts. Each preloaded resource takes bandwidth and delays other critical resources (CSS, JS, images above-the-fold). A site that preloads 6 font variants loses more than it gains.

Avoid loading fonts from third-party CDNs without control over HTTP headers. If the CDN does not send the correct Cache-Control headers, the browser will request the font again on each visit. Host your fonts locally or use Google Fonts with a preconnect.

How can I check if my fonts are optimized properly?

Use PageSpeed Insights and Lighthouse to audit blocking resources. If the fonts appear under "Eliminate render-blocking resources", they are still blocking rendering. The report will also tell you if font-display is set.

Then test on WebPageTest with a 3G throttling to simulate a mobile connection. Check the filmstrip: if the text remains invisible for more than 500 ms, you have a FOIT. If the text violently switches from Arial to your custom font after 1 second, your FOUT degrades the experience.

• Add font-display: swap to all @font-face
• Preload only fonts above-the-fold (1-2 variants max)
• Use the WOFF2 format to reduce file sizes by 30-50%
• Limit the number of loaded variants (regular, bold, italic often suffice)
• Host fonts on the same domain to avoid additional DNS lookups
• Test Core Web Vitals before/after with PageSpeed Insights and WebPageTest