Self-Host vs Google Fonts CDN: A Performance Comparison

Loading web fonts is one of the few front-end decisions that directly affects Core Web Vitals. The choice between self-hosting font files and using the Google Fonts CDN touches LCP, privacy, cache efficiency, and developer ergonomics. This article compares the two approaches with measured numbers and a recommendation framework.

The Two Approaches

The Google Fonts CDN serves font files from fonts.gstatic.com. You add a <link> tag to your HTML, Google's CDN handles the request, and the browser downloads the WOFF2 file from Google's edge. The CDN is free, fast, and serves cache headers that let browsers reuse the file across every site that uses the same font.

Self-hosting means downloading the WOFF2 files from Google Fonts (or generating them from the source), placing them in your site's /fonts/ directory, and writing @font-face declarations that point to your own origin. The browser downloads the file from your domain, not Google's.

LCP: The Measured Numbers

The Google Fonts CDN adds one extra DNS lookup, one TLS handshake, and one HTTP request to fonts.gstatic.com. On a cold cache, that is roughly 150 to 300 milliseconds of overhead on a fast connection, and more on a slow mobile connection. On a warm cache, the cost is near zero because the file is already in the browser's cache.

Self-hosting eliminates the cross-origin overhead. The font file downloads from your own domain, alongside your CSS and JS, in the same HTTP/2 connection pool. Measured LCP improvement on a cold cache: 100 to 250 milliseconds on a mid-range phone over a 4G connection. On a warm cache, the difference is negligible because both paths are cached.

The LCP delta is real but modest. If your site is otherwise fast, the CDN is fine. If your site is borderline on LCP, self-hosting can push you into the green.

Privacy and the GDPR Question

The Google Fonts CDN sends the user's IP address to Google's servers. In 2022 a German regional court ruled that this constitutes a GDPR violation without explicit consent. The ruling is contested, but it has led many European sites to self-host or to add a consent banner before loading Google Fonts.

Self-hosting keeps the font request on your own origin. No third party receives the user's IP. For sites that need to comply with GDPR or that want to minimize third-party data sharing, self-hosting is the safer choice.

Cache Efficiency

The Google Fonts CDN has a powerful cross-site cache. If a user has already visited a site that loads Inter from Google Fonts, the file is in their browser cache. Your site loads Inter from cache, with no network request. For popular fonts like Inter and Roboto, this is a real win: a meaningful percentage of visitors will get the font for free.

Self-hosting cannot use the cross-site cache. Every visitor downloads the font from your origin, even if they have it cached from another site. For popular fonts, the CDN is faster on average. For niche fonts, the difference is zero because the cross-site cache would never hit anyway.

Developer Ergonomics

The CDN is the easier path. One <link> tag and you are done. No build step, no font file management, no @font-face declarations. Google handles subsetting, unicode-range, and format negotiation.

Self-hosting requires you to download the WOFF2 files, place them in your project, write @font-face declarations, and handle subsetting yourself. The FontBlend font stack generator and font embed generator produce the @font-face declarations for you, which removes most of the friction.

The Font-Display Setting

Both paths support font-display: swap, which lets the browser render text in a fallback font while the web font loads. This avoids the FOIT (Flash of Invisible Text) problem, where text is invisible for up to 3 seconds while the font loads. Always use font-display: swap or font-display: optional, regardless of which path you choose.

A Recommendation Framework

Use the Google Fonts CDN if: you are building a marketing site or blog where LCP is not borderline, you are not subject to strict GDPR consent requirements, and you want the simplest possible setup.

Self-host if: your site is borderline on LCP and you need the 100 to 250 millisecond saving, you need to comply with GDPR, you are building a privacy-focused product, or you want full control over font subsetting and delivery.

The two are not mutually exclusive. You can self-host the fonts that appear above the fold (the LCP font) and use the CDN for the rest. This captures the LCP saving where it matters and keeps the cross-site cache benefit for the rest of the page.

How to Self-Host with FontBlend

The FontBlend font stack generator produces a complete @font-face declaration for any font in the catalog. Pick the font, copy the generated CSS, drop the WOFF2 file into your /fonts/ directory, and you are done. The font embed generator does the same for the Google Fonts <link> path, with preconnect hints included.

What the CDN Does That You Cannot See

A Google Fonts link tag hides a surprising amount of work. The CSS that the browser fetches first lists dozens of woff2 files, one per subset and weight, and each declaration carries a unicode-range so the browser downloads only the files that cover the glyphs actually on the page. A Latin-only English page never fetches the Cyrillic or Vietnamese subsets. When you self-host, that machinery becomes your responsibility: you either download pre-subsetted files from a helper service or ship full files and accept the extra weight.

The CDN also negotiates the format. Older browsers get a format they can parse while modern ones get woff2, decided by the browser's own request headers. A self-hosted @font-face rule does the same negotiation only if you list multiple src entries in the right order with format hints.

The Middle Path: An Npm Package

Between a manual fonts directory and the CDN sits a third option: package-managed font files such as those published under the Fontsource project. You add a package, and your bundler copies the woff2 files into your own output and rewrites the @font-face declarations to point at your origin. The request stays on your domain, so the privacy and connection-pool benefits of self-hosting hold, but updates arrive as dependency bumps instead of manual downloads.

The tradeoff is build size and discipline. Your bundle now carries font files, so every dependency update is a potential visual diff, and you still need the same care with unicode-range and font-display that hand-rolled self-hosting needs.

Measuring Before You Switch

Do not move the files on faith. Open the network panel, throttle to a mid-range 4G profile, and reload until the waterfall settles. Note three numbers: when the font request starts, how long it takes to finish, and whether text rendered before the file arrived. Then serve the same font from your own origin and compare the start time, because that is where the CDN tax lives: the extra DNS lookup, the TLS handshake, and the connection setup to a second host. LCP guidance will tell you which element is the largest on the page, and if that element is a heading in the web font, the font is part of your LCP story either way.

A quick proxy test works too: load the page with fonts.gstatic.com blocked in the browser and see whether the fallback text is acceptable. That is the experience a privacy-focused visitor gets, and it is the strongest argument for self-hosting independent of any benchmark.

A Decision for Three Real Sites

A local restaurant brochure site with modest traffic should probably stay on the CDN. The setup cost is one link tag, the LCP budget is rarely tight, and visitors who have Inter cached from another site load it for free.

A B2B SaaS dashboard used daily by European customers should self-host. The privacy posture matters, the font is needed on every authenticated page load, and a warm cache on your own origin beats a cold third-party connection every morning.

A content site whose brand font is niche should self-host too, because the cross-site cache argument evaporates when few other sites use the same face. The popular-font advantage only exists for the fonts everyone loads.

Questions That Come Up

Does self-hosting break font updates? Google occasionally revises a family. The CDN always serves the current version; a self-hosted copy stays frozen until you refresh the files, which is usually a feature for a brand that wants its letterforms to stop moving.

Do I still need preconnect when self-hosting? No. Preconnect exists to warm up a connection to a different origin. On your own domain the font request rides the connection your page already opened.

Can a service worker cache the CDN fonts for offline use? In theory yes, but a third-party request is harder to capture reliably than a same-origin one, and the CDN's cache headers do the job only while the visitor is online. Self-hosted files drop into the same-origin cache and your service worker without extra ceremony.

Related Tools

The font stack generator produces self-host @font-face declarations. The font embed generator produces the Google Fonts CDN link with preconnect. The brand kit builder exports both paths as part of a complete design system.