Should you self-host fonts or use Google Fonts?

For most production websites, self-hosting fonts is the better choice: it's usually as fast or faster than the Google Fonts API, it removes a third-party connection, it gives you full control over caching and preloading, and it avoids sending visitors' IP addresses to Google. The old argument for Google Fonts, that visitors would already have the files cached from other sites, no longer applies because modern browsers partition their HTTP cache by site. Google Fonts is still a perfectly good option for prototypes, small personal sites and situations where you can't change the build or server. The fonts themselves are identical either way, since Google Fonts families are openly licensed and can be downloaded and hosted yourself.

The choice affects page speed, privacy compliance and how much work you take on. Neither option is wrong in every case, but the trade-offs have shifted over the years and much of the advice online is out of date. In this article you'll learn how the Google Fonts API actually loads fonts, why the shared cache disappeared, how the two approaches compare on performance and privacy, when Google Fonts still makes sense, and how to migrate from the API to self-hosted files.

How the Google Fonts API Loads Fonts

When you embed Google Fonts with the standard snippet, the browser goes through several steps before your text appears in the right typeface:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link
  href="https://fonts.googleapis.com/css2?family=Lora:ital,wght@0,400;0,700;1,400&display=swap"
  rel="stylesheet"
>

1. Connect to fonts.googleapis.com: DNS lookup, TCP and TLS handshakes for the CSS host.
2. Download the CSS: Google returns a stylesheet tailored to the requesting browser, containing @font-face rules for each style and character subset. This stylesheet is render-blocking, like any other.
3. Connect to fonts.gstatic.com: A second origin, with its own handshakes, hosts the font files.
4. Download the font files: Only once the CSS is parsed and the browser finds text that needs a particular style.

The preconnect hints overlap some of the connection setup, but the chain still involves two extra origins and a stylesheet you don't control.

Google does several things well here. It serves WOFF2 to browsers that support it, splits each family into unicode-range subsets so pages only download the scripts they use, and lets you set font-display with the display URL parameter.

The Shared Cache No Longer Exists

The classic argument for Google Fonts was cross-site caching. If thousands of sites used the same copy of a popular font from fonts.gstatic.com, a visitor would probably already have it cached.

That stopped being true when browsers introduced cache partitioning to prevent cross-site tracking. Safari partitioned its cache first, and Chrome and Firefox followed in 2020 and 2021. A cached resource is now keyed by the top-level site that requested it as well as its URL. The same font file fetched on two different websites is downloaded and stored twice.

So when a visitor arrives at your site for the first time, they download your Google Font no matter how many other sites use it. The only caching benefit left is for repeat visits to your own site, which you get equally with self-hosting.

Performance Compared

With the shared cache gone, the comparison comes down to the cost of the request chain:

Factor	Google Fonts API	Self-hosted
Extra origins	Two (CSS and files)	None if served from your domain
Render-blocking CSS	Third-party stylesheet	Your own CSS, often already loaded
Font discovery	After third-party CSS arrives	As soon as your CSS is parsed
Preloading	Hard, as file URLs can change	Easy, with stable or hashed URLs
Cache headers	Set by Google	Set by you
Subsetting	Automatic per script	You do it, or use a tool
Format negotiation	Automatic	You choose WOFF2

Why Self-Hosting Usually Wins

On a first visit, a self-hosted font served from the same origin as your HTML reuses the connection that's already open. If you use HTTP/2 or HTTP/3, the font request is multiplexed alongside your other assets with no new handshakes. You can also preload the critical file directly, so the browser starts fetching it as soon as it reads the head, rather than after a third-party stylesheet arrives.

Where Google Fonts Holds Up

Google's infrastructure is fast and globally distributed, and its automatic subsetting is excellent. If your own hosting is slow, far from your visitors and has no CDN, Google's servers may deliver font files faster than yours. In that case the better fix is usually to put your site behind a CDN, but it's a real consideration.

Measure Rather Than Guess

Test both approaches on your own site with WebPageTest or Lighthouse using a throttled mobile profile. Look at:

• When the font file starts downloading: In the waterfall chart.
• Largest Contentful Paint: Especially if the LCP element is text.
• Cumulative Layout Shift: When the web font swaps in.

Privacy and GDPR

Every request to Google's servers sends the visitor's IP address and browser details. Under the GDPR, an IP address can be personal data.

In January 2022 a regional court in Munich ruled that a website operator had violated the GDPR by embedding Google Fonts from Google's servers without the visitor's consent, transmitting their IP address to Google, and awarded the claimant damages. The ruling led to a wave of warning letters to German site owners and prompted many European organisations to switch to self-hosting.

A few points are worth keeping in perspective:

• It was one regional court decision: It isn't binding EU-wide precedent, and this isn't legal advice. If compliance is a concern, ask your data protection adviser.
• Self-hosting removes the issue for fonts: No visitor data goes to Google when the files come from your server.
• Other third-party embeds raise the same question: Analytics, video embeds and CDNs all transmit IP addresses.

For many organisations, self-hosting is simply the easiest way to avoid having to justify or obtain consent for a font request.

Maintenance and Control

Google Fonts is low effort: paste a snippet and you're done. Google handles updates to the font files, format negotiation and subsets.

Self-hosting asks a little more:

• Choosing subsets: You decide which characters to include, or install a package that has done it for you.
• Updating files: When a font family releases a new version, you update your copy if you want the changes.
• Server configuration: Setting cache headers and content types.

In exchange, you gain control:

• Stable URLs for preloading: Google's font file URLs can change when families are updated, so hard-coding a preload to them is fragile.
• Font metric overrides: You can add size-adjust and related descriptors to fallback faces to reduce layout shift. With Google's CSS, you can only do that for your own fallback rules.
• Fewer surprises: A family update on Google's side can subtly change metrics or glyphs on your live site without warning.
• Availability: Your fonts don't depend on a third-party service being reachable, which matters in regions or networks where Google domains are blocked or slow.

When Google Fonts Still Makes Sense

• Prototypes and experiments: Trying out typefaces quickly without downloading files.
• Hosted platforms with no file access: Some site builders and hosted CMSs let you add a stylesheet link but not upload font files.
• Very small sites: Where the performance and privacy differences are not a priority and simplicity is.
• Email: Self-hosting doesn't change much for newsletters, where font support depends on the email client.

How to Migrate From Google Fonts to Self-Hosting

Moving over takes about half an hour for a typical site.

1. List what you load: Copy your current Google Fonts URL and note every family, weight and style in it.
2. Get the files: Install the matching Fontsource packages, or download the family from Google Fonts and convert it to WOFF2.
3. Write @font-face rules: Use the same family names as before so your existing font-family declarations keep working.
4. Remove the Google snippet: Delete the stylesheet link and both preconnect hints. Check templates, theme settings and plugins for any other copies.
5. Preload the main font: Add one preload for the font used in your largest above-the-fold text.
6. Verify: In DevTools, filter Network requests by gstatic and googleapis to confirm nothing is still requested from Google.

With Fontsource, steps 2 and 3 collapse into an install and an import:

npm install @fontsource/lora

import "@fontsource/lora/400.css";
import "@fontsource/lora/400-italic.css";
import "@fontsource/lora/700.css";

body {
  font-family: "Lora", Georgia, serif;
}

If you prefer plain files, the self-hosted rules look like this:

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

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

The full setup, including server headers, is covered in the guide on how to self-host web fonts.

WordPress Sites

Themes and page builders often load Google Fonts on their own. Check for a setting to disable remote fonts or load them locally. Many popular themes and builders have added a local fonts option since 2022, and block themes can register self-hosted fonts in theme.json. After switching, search the page source for fonts.googleapis.com to make sure no plugin is still adding its own link.

Confirming Nothing Leaks to Google

A quick command-line check against your rendered HTML:

curl -s https://www.example.com/ | grep -oE "fonts\.(googleapis|gstatic)\.com[^\"' ]*" | sort -u

No output means the page itself doesn't reference Google's font servers. CSS files and JavaScript can still inject them, so confirm in the Network panel too.

If You Stay With Google Fonts

If self-hosting isn't practical, you can still make the API faster:

• Keep both preconnects: Including crossorigin on the fonts.gstatic.com hint, because font files are fetched in CORS mode.
• Request only what you use: Each extra weight and italic adds files.
• Add the display parameter: &display=swap or &display=optional, so text isn't hidden while fonts load. The options are explained in the guide to the font-display property.
• Use the text parameter for tiny needs: For a logo or a single heading, &text= returns a font containing only the listed characters.
• Consider variable families: Requesting a weight range such as wght@400..700 can replace several static files with one.

---

FAQ: Self-Hosting vs Google Fonts

---

Conclusion

The case for loading fonts from Google's servers has weakened considerably. Cache partitioning removed the shared cache benefit, the extra connections and third-party stylesheet add latency to first visits, and sending visitor IP addresses to Google carries privacy risk in Europe. Self-hosting the same openly licensed files gives you equal or better speed, full control over caching and preloading, and one less dependency.

Google Fonts remains a quick and reliable way to try typefaces and a sensible fallback on platforms where you can't upload files. For any site you care about in production, though, download the fonts, serve them from your own domain, preload the one that matters most, and check that nothing still calls out to Google.