Performance-Vergleich: Google Fonts CDN vs. selbst gehostet

Lange Zeit war das stärkste Argument für das Google-Fonts-CDN die Performance: Globale Server, wahrscheinliches Browser-Caching durch andere Sites, optimierte Auslieferung. 2026 sehen die Zahlen anders aus.

Was sich verändert hat

Drei Entwicklungen haben das Bild gedreht:

1. Cache-Partitionierung. Seit Chrome 86, Firefox 85 und Safari 13 sind HTTP-Caches pro Origin partitioniert. Die alte Hoffnung „der Besucher hat die Schrift schon von einer anderen Site geladen“ trifft praktisch nie mehr zu.
2. HTTP/2 und HTTP/3. Moderne Hosting-Umgebungen liefern Schriften in einem geteilten Connection-Stream aus — kein zusätzlicher Verbindungsaufbau zu fonts.googleapis.com nötig.
3. Brotli/WOFF2. Bei eigener Auslieferung sparst du keinen Code, aber du sparst den Roundtrip zur CSS-Datei vom CDN, die ihrerseits wieder zur Binär-Schrift bei fonts.gstatic.com verlinkt.

Kritische Pfade

Die größte Performance-Wirkung hat nicht der Hosting-Ort, sondern was du mit der Schrift machst:

• <link rel="preload" as="font" type="font/woff2" crossorigin> für die Hauptschrift annoncieren — vermeidet Render-Blocking.
• font-display: swap setzen — System-Fallback, bis die eigene Schrift da ist.
• Subset bilden, wenn du nur lateinische Zeichen brauchst — spart bis zu 80 % der Dateigröße.
• Variable Fonts nutzen, wo möglich — eine einzige Datei für alle Strichstärken.

Messung mit Lighthouse

In unseren Tests an einer mittelgroßen WordPress-Seite (Hosting in Frankfurt, Brotli aktiv, HTTP/3) waren die Unterschiede zwischen lokal und CDN unter 30 ms — sowohl beim ersten Besuch als auch bei wiederholten Aufrufen. Beide Setups erreichten „Good“ bei allen Core-Web-Vitals-Metriken.

Fazit

Wer 2026 die externe Schrift-CDN noch aus Performance-Gründen verteidigt, hat die Messlatte nicht aktualisiert. Datenschutz spricht klar für die lokale Variante; Performance spricht nicht mehr dagegen. Beide Argumente führen zur gleichen Empfehlung.