Wie Websites ihre Schriften wirklich ausliefern

Stand 21. September 2026. Die Sites in unserer Datenbank sind keine Zufallsstichprobe des Webs - siehe wie wir gemessen haben.

Was wir gemessen haben - und was nicht

Jedes Mal, wenn jemand eine URL durch den Schriftart-Checker schickt, lädt unser Scanner das HTML der Seite, ihre eingebetteten <style>-Blöcke und bis zu zehn verlinkte Stylesheets und wertet die @font-face-Regeln und Font-Provider-Links aus, die er darin findet. Für jede Schrift speichert er das src der Regel - und dieses src nennt den Host, der die Schriftdatei tatsächlich ausliefert. Der Scanner führt kein JavaScript aus; eine Schrift, die nur per Skript nachgeladen wird (etwa durch ein Consent-Tool, das Google Fonts erst nach einem Klick einbindet), kann ihm deshalb entgehen. Schriften, die in einem font-family-Stack nur als Fallback stehen, und Systemschriften zählen nicht als Webfonts.

Für diese Studie haben wir jede Site in unserer Datenbank mit mindestens einem echten Webfont genommen: 1.957 Sites, Stand 21. September 2026. Bei 1.836 davon enthielt die gespeicherte Regel eine verwertbare Quell-URL; jede Prozentangabe in diesem Artikel bezieht sich auf diese 1.836 Sites, sofern nichts anderes gesagt wird. Dann haben wir den Host der Quell-URL jeder Schrift mit der eigenen Domain der Site verglichen. Eine Schrift, deren Datei von der Domain der Site oder einer ihrer Subdomains kommt, gilt als selbst gehostet; alles andere gilt als Drittanbieter-Host. Google, Adobe und Bunny erkennen wir an ihren bekannten Hostnamen.

Beim Einordnen wurde noch etwas deutlich: „selbst gehostet oder CDN“ ist eine falsche Gegenüberstellung. 397 der 1.836 Sites liefern Schriften gleichzeitig von der eigenen Domain und von einem Fremd-Host aus - zum Beispiel eine selbst gehostete Textschrift neben einer Display-Schrift von Google. Das ist selbst ein Befund, und es ist der Grund, warum sich die Kategorien unten überschneiden.

Die Auslieferungswege, technisch betrachtet

Ein Webfont erreicht den Besucher in zwei Schritten: Der Browser braucht zuerst ein Stylesheet mit einer @font-face-Regel, dann lädt er die Schriftdatei, auf die diese Regel zeigt. Der Auslieferungsweg bestimmt, wie viele verschiedene Hosts an diesen beiden Schritten beteiligt sind, wer das Caching kontrolliert und welche Server Anfragen erhalten - und damit, als Nebeneffekt, die IP-Adresse des Besuchers.

Selbst gehostet

Die Site liefert ihre eigenen @font-face-Regeln aus, und die Schriftdateien liegen auf dem Origin der Site, oft neben den übrigen statischen Assets: github.com liefert Mona Sans aus /assets/, nytimes.com seine Familien Cheltenham und Franklin aus /fonts/family/, heise.de seine variable Schrift Source Sans aus /assets/fonts/. Der Browser ist für das HTML bereits mit diesem Origin verbunden, die Schriftdateien laufen also über dieselbe Verbindung; kein zusätzlicher DNS-Lookup, TCP-Handshake oder TLS-Aushandlung ist nötig. Die Site kontrolliert jedes Detail: die Cache-Lebensdauer der Dateien, die font-display-Strategie, das Subsetting per unicode-range und ob eine Datei vorab geladen wird. Niemand außer der Site selbst sieht die Anfrage. Der Preis dafür: Die Site muss diese Arbeit selbst erledigen - Dateien konvertieren und subsetten, Cache-Header setzen und die Lizenzbedingungen kommerzieller Schriften im Blick behalten.

web.dev formuliert das Performance-Argument klar: „Auf dem Papier sollte eine selbst gehostete Schrift die bessere Leistung liefern, weil sie den Verbindungsaufbau zu einem Dritten überflüssig macht“ - und schiebt sofort die Bedingung nach, dass die Site die Dateien über ein CDN und HTTP/2 ausliefern sollte und dass man es nur sicher weiß, wenn man beide Varianten misst (Best practices for fonts).

Google Fonts

Die Standard-Einbindung ist ein <link rel="stylesheet"> auf fonts.googleapis.com/css2?family=… (Dokumentation der CSS-API). Dieser Host liefert ein Stylesheet zurück, keine Schrift. Google erzeugt dieses Stylesheet für den anfragenden Browser: Die Seite Technical considerations formuliert es so, dass „die Fonts-API ein Stylesheet ausliefert, das für den konkreten User-Agent erzeugt wird, der die Anfrage stellt“. Wir haben das am 21. September 2026 nachvollzogen: Dieselbe URL lieferte an einen Chrome-User-Agent woff2-Dateien, aufgeteilt in unicode-range-Subsets je Schriftsystem, und an einen Client ohne Browser-User-Agent eine einzelne TrueType-Datei. Die Schriftdateien selbst werden dann von einem zweiten Host geladen, fonts.gstatic.com. Eine Seite, die Google Fonts auf diesem Weg nutzt, spricht also mit drei Origins, bevor ihr Text in der vorgesehenen Schrift erscheinen kann - weshalb web.dev für Drittanbieter-Font-Hosts einen preconnect-Hinweis empfiehlt, und in diesem Fall zwei davon, weil „Schriftdateien über eine CORS-Verbindung gesendet werden müssen“ (web.dev).

Die CORS-Anforderung ist keine Besonderheit von Google. Die CSS-Fonts-Spezifikation verlangt, dass Schriftdateien im CORS-Modus geladen werden, und merkt an, dass „Schriften üblicherweise nicht cross-origin geladen werden, sofern Autoren nicht gezielt Schritte unternehmen, um Cross-Origin-Laden zu erlauben“ (CSS Fonts Level 4, font fetching requirements; MDN zu CORS). Jeder gehostete Schriftdienst antwortet aus diesem Grund mit Access-Control-Allow-Origin: * - Googles Hosts taten das in unseren Prüfungen.

Das Caching ist auf die beiden Hosts verteilt. Am 21. September 2026 kam das Stylesheet von fonts.googleapis.com mit Cache-Control: private, max-age=86400, stale-while-revalidate=604800 - einen Tag lang cachebar -, während eine Schriftdatei von fonts.gstatic.com mit Cache-Control: public, max-age=31536000 kam, ein Jahr. In der Praxis fragt der Browser den Stylesheet-Host regelmäßig erneut an und behält die Dateien lange.

Der Datenfluss ist die Kehrseite des Anfragewegs. Der Browser jedes Besuchers kontaktiert Googles Server zweimal, und ein Server erfährt zwangsläufig die IP-Adresse des Clients, dem er antwortet - so funktioniert HTTP, das ist keine Designentscheidung von Google. Was Google mit diesen Anfragen macht, beschreibt der Datenschutzabschnitt der Google Fonts FAQ; wir verweisen darauf, statt ihn zu paraphrasieren, weil es Googles Aussage ist. In unseren Daten ist youtube.com das Lehrbuchbeispiel für diesen Weg: Roboto und YouTube Sans kommen über fonts.googleapis.com und fonts.gstatic.com. Ob eine bestimmte Site diesen Weg nutzt, zeigt unser Google-Fonts-Checker.

Adobe Fonts (Typekit)

Adobe Fonts arbeitet mit einem „Kit“ oder Webprojekt: Die Seite verlinkt ein Stylesheet auf use.typekit.net, und bei den von uns gescannten Sites werden die Schriftdateien, auf die dieses Stylesheet verweist, vom selben Host ausgeliefert, unter use.typekit.net/af/…. Das macht zwei Origins statt drei. Die Schriften bleiben auf Adobes Servern; das ist Teil des Lizenzmodells, und deshalb erhebt Adobe Nutzungsdaten. Adobes Datenschutzhinweis für den Dienst führt auf, was der Website-Font-Dienst erfasst - unter anderem die ausgelieferten Schriften, die Webprojekt-ID, die Konto-ID, den Hostnamen der Seite, die die Schriften lädt, und die IP-Adresse, zu der es heißt: „Der Fonts-Dienst erhält die IP-Adresse zwar, damit er weiß, wohin er die Schrift ausliefern soll, speichert sie aber nicht.“ Derselbe Hinweis erklärt, dass „wir keine Cookies setzen oder verwenden, um unsere Schriften auszuliefern“, und nennt Abrechnung und Compliance als Zweck (Adobe Fonts privacy notice). Beispiele in unserer Datenbank sind jamesclear.com und princeton.edu.

Monotype und andere gehostete Dienste

Monotypes gehosteter Webfont-Dienst folgt demselben Muster aus Anbieter-Host plus Nutzungsreporting: Zur Einbindung gehört ein Tracking-Stylesheet, das in Monotypes Worten „die Webfont-Nutzung erfasst und diese Nutzungsdaten für Reporting- und Lizenzzwecke an Monotype Fonts zurückmeldet“, gezählt als Seitenaufrufe pro Webprojekt (Monotype: Hosting web fonts and reporting). In unseren Daten taucht der Host static.monotype.com mit 120 Schriftreferenzen auf - die aber von nur zwei Sites stammen, beides Foundry-Sites der Monotype-Gruppe, die jeweils viele Schnitte deklarieren. Das sollte man beim Lesen des Host-Rankings unten im Kopf behalten.

Alternativen aus der EU: Bunny Fonts

Bunny Fonts ist der bekannteste der Dienste, die sich als datenschutzfreundlicher Ersatz für Googles CDN positionieren. Seine API ist nach eigener Aussage „vollständig kompatibel mit der Google Fonts CSS v1 API“, sodass der Wechsel „so einfach ist wie das Ändern des Hostnamens“; der Dienst erklärt eine „Zero-Tracking- und No-Logging-Policy“ und wird von der BunnyWay d.o.o. betrieben, einem Unternehmen mit Sitz in der EU (About Bunny Fonts). Technisch ist es der Google-Weg mit einem Host weniger: Am 21. September 2026 zeigte das Stylesheet unter fonts.bunny.net/css?family=… auf Schriftdateien auf demselben Host und wurde mit Cache-Control: public, max-age=2592000 ausgeliefert. Ob die No-Logging-Aussage zutrifft, können wir von außen nicht messen; wir geben die Aussage des Anbieters als Aussage wieder.

Ein vierter Weg, den niemand wählt: das CDN des Site-Builders

Drei der sieben häufigsten Drittanbieter-Hosts in unseren Daten sind gar keine Schriftdienste. Webflow dokumentiert, dass hochgeladene Assets „über unser Content Delivery Network ausgeliefert“ werden (Webflow: Asset privacy); in unseren Scans meldet sich dieses CDN als cdn.prod.website-files.com, und Webflows eigene Site, webflow.com, lädt ihre WF Visual Sans von dort. Framer führt framerusercontent.com unter den Domains, die es für „das Hosting von Assets, Schriften und Designdateien“ nutzt (Framer: Allowlist Framer domains). Shopifys Theme-Plattform gibt Entwicklern über ihren font_url-Filter für jede Schrift eine CDN-URL (Shopify Liquid: font_url), und shopify.com selbst liefert seine Schriften von cdn.shopify.com. Für den Besucher sind das Drittanbieter-Hosts wie alle anderen - ein zusätzlicher Origin, eine zusätzliche Verbindung, eine Anfrage an ein Unternehmen, das nicht der Site-Betreiber ist. Für den Site-Betreiber ist es einfach das, was die Plattform tut; die Schriften gehören ihm, das Hosting nicht. Wer „Drittanbieter-Host“ als „nutzt einen Schriftdienst“ liest, würde Letzteres überzählen.

Was die Daten zeigen

Selbsthosting ist in dieser Menge die Regel, nicht die Ausnahme. 1.503 von 1.836 Sites (81,9 %) liefern mindestens eine Schrift von der eigenen Domain, und 1.106 (60,2 %) liefern jede Schrift auf diesem Weg. Drittanbieter-Hosts sind auf 730 Sites (39,8 %) beteiligt, und die Schnittmenge dieser beiden Gruppen sind genau die oben erwähnten 397 Sites. Unter den eigentlichen Schriftdiensten dominiert Google: 393 Sites (21,4 %) laden mindestens eine Schrift von fonts.googleapis.com oder fonts.gstatic.com, gegenüber 75 (4,1 %) bei Adobe Fonts. Angesichts einer Stichprobe, die zu großen Marken mit eigener Entwicklung neigt, ist ein Fünftel davon nach wie vor auf Googles Hosts die Zahl, die uns am meisten überrascht hat.

Die Sites mit mehreren Wegen zeigen, wie es dazu kommt. ycombinator.com hostet Avenir selbst und holt DM Sans, Source Serif 4 und Material Symbols von fonts.googleapis.com; zillow.com liefert Inter und Ivar Headline von seinem eigenen zillowstatic.com und Open Sans von fonts.gstatic.com; a16z.com kombiniert ein Adobe-Kit mit einer EB-Garamond-Datei von fonts.gstatic.com; und framer.com - die Site eines Unternehmens, dessen Produkt Schriften hostet - hostet seine Markenschriften selbst und referenziert daneben mehrere Google-Dateien direkt. Eine plausible Lesart: Die Textschrift ist eine bewusste Entscheidung, der Rest sammelt sich an - eine Marketingseite auf einem anderen Stack, eine Icon-Schrift, ein eingebettetes Widget. Wir haben die Betreiber nicht gefragt, das bleibt also eine Interpretation.

Die Drittanbieter-Hosts

Die beiden Google-Hosts führen mit großem Abstand, und ihre Zahlen sind fast identisch (456 und 450), weil sie zwei Hälften eines Weges sind: eine Stylesheet-Referenz auf fonts.googleapis.com und die Dateireferenzen auf fonts.gstatic.com, die daraus entstehen. Adobe folgt mit 191 Referenzen auf use.typekit.net. Der Monotype-Eintrag ist das Lehrstück dieses Rankings: 120 Referenzen von zwei Sites. Und die drei Plattform-CDNs kommen zusammen auf 225 Referenzen, die mit der Wahl eines Schriftdienstes nichts zu tun haben.

Nach Länderdomain - und was diese Tabelle nicht sagen kann

Eine oft wiederholte Annahme lautet, dass deutsche Websites ihre Schriften häufiger selbst hosten als andere - wegen der Abmahnwelle, die auf das Münchner Urteil vom Januar 2022 folgte (siehe den rechtlichen Kontext unten). Das wollten wir prüfen und haben die Sites nach Top-Level-Domain aufgeteilt. Die Tabelle führt jede Domain-Endung mit mindestens 20 Sites auf und für jede den Anteil der Sites, die mindestens eine Schriftdatei von Googles Servern laden - also von fonts.googleapis.com oder fonts.gstatic.com.

Die Richtung passt zur Annahme. 9,7 % der 62 .de-Sites laden eine Schriftdatei von einem Google-Host, gegenüber 19,5 % der 1.131 .com-Sites - ungefähr die halbe Rate. Die beiden anderen europäischen Gruppen in der Tabelle zeigen in dieselbe Richtung: .nl mit 9,1 % und .fr mit 13,6 %, beide unter dem .com-Wert.

Hier endet die ehrliche Lesart, denn mehr trägt die Stichprobe nicht. Bei 6 von 62 Sites in der .de-Gruppe ergibt ein Zwei-Anteile-Test für den Abstand p ≈ 0,056 - knapp außerhalb der üblichen Fünf-Prozent-Schwelle. Eine Handvoll Sites mehr oder weniger würde den Anteil um mehrere Punkte verschieben, und die .nl- und .fr-Gruppen sind mit je 22 Sites noch kleiner. Also: Die Daten neigen zur Annahme, und sie sind nicht stark genug, um sie zu bestätigen. Wir bräuchten eine weit größere deutsche Stichprobe, gezogen ohne die im Methodenteil beschriebene Verzerrung, bevor jemand dies als Beleg dafür anführen sollte, dass deutsche Sites sich von Googles Servern abgewandt haben.

Eine methodische Anmerkung, weil sie unsere eigene Antwort verändert hat. Ein früherer Stand dieser Tabelle zählte Sites, die eine Schrift aus Googles Katalog nutzen, statt Sites, die Schriften von Googles Servern laden. Nach diesem Maß sahen deutsche Sites wie stärkere Google-Nutzer aus, nicht wie schwächere - weil eine Site, die Roboto selbst hostet, also genau das Verhalten, um das es geht, genauso zählte wie eine, die Roboto von fonts.gstatic.com lädt. Die Zahlen oben sind nach Auslieferungshost gerechnet. Diese Unterscheidung entscheidet über die Antwort - ein gutes Beispiel dafür, warum wir die Methode neben den Zahlen veröffentlichen.

Die Bunny-Null

Nicht eine der 1.836 Sites lädt eine Schrift von fonts.bunny.net. Unser Scanner erkennt den Host ausdrücklich, es ist also keine Erkennungslücke. Es ist allerdings eine Aussage über diese Stichprobe: große, überwiegend internationale Sites mit eigenen Entwicklungsteams, die - wie die Selbsthosting-Zahlen zeigen - das Problem, das Bunny Fonts adressiert, eher lösen, indem sie die Dateien selbst hosten. Ein Verzeichnis kleiner deutscher Unternehmens-Sites könnte durchaus anders aussehen. Dazu haben wir schlicht keine Daten, und das sagen wir lieber, als zu extrapolieren.

Die Wege gegeneinander abwägen

Aus alldem folgt keine Regel, die für jede Site passt, sondern eine Reihe von Abwägungen, die jede Site anders gewichtet.

Performance. Selbsthosting spart gegenüber dem Google-Weg zwei Verbindungsaufbauten pro Besucher und gegenüber Adobe einen, und seit der Cache-Partitionierung gibt es dafür nichts mehr auf. Außerdem legt es font-display, Subsetting und Preloading in die Hand der Site. Dagegen steht der Betriebsaufwand: Ein gehosteter Dienst liefert standardmäßig korrekt gesubsettete woff2-Dateien mit vernünftigen Cache-Headern aus, und eine selbst hostende Site, die diese Details falsch macht, kann leicht langsamer enden, als sie auf Googles CDN gewesen wäre. web.devs Rat, beide Varianten zu messen statt anzunehmen, ist hier die ehrliche Antwort.

Datenflüsse. Beim Selbsthosting sieht kein Dritter die Schriftanfragen. Bei jedem gehosteten Weg erhalten die Server des Anbieters bei jedem Seitenaufruf eine Anfrage - und damit die IP-Adresse des Besuchers; was davon wie lange gespeichert wird, ist eine Frage der erklärten Richtlinie des Anbieters (Googles FAQ, Adobes Datenschutzhinweis, Bunnys No-Logging-Aussage), die wir zitieren, aber nicht überprüfen können. Plattform-CDNs fallen in dieselbe Kategorie, auch wenn niemand sie wegen ihres Font-Hostings ausgewählt hat. Ob eine Site Schriften von Googles Servern lädt, lässt sich mit dem Google-Fonts-Checker nachsehen.

Lizenzen. Bei offen lizenzierten Schriften wie Googles Katalog ist der Auslieferungsweg frei wählbar. Bei kommerziellen Schriften entscheiden die Lizenzbedingungen, welche Wege überhaupt offenstehen: Manche Anbieter binden die Webnutzung an ihren gehosteten Dienst und dessen Nutzungsreporting, andere verkaufen Lizenzen zum Selbsthosten. Das ist zuerst eine Vertragsfrage und erst dann eine technische.

Aufwand und Kontrolle. Ein gehosteter Dienst ist eine Zeile HTML und aktualisiert sich selbst; der Site-Betreiber gibt dafür die Kontrolle über Cache-Lebensdauern, Dateiformate und den Zeitpunkt ab, zu dem sich eine Schrift ändert. Selbsthosting ist der umgekehrte Tausch. Die Sites mit mehreren Wegen in unseren Daten legen nahe, dass viele Teams diese Wahl pro Schrift treffen statt pro Site - ob bewusst oder durch Ansammlung.

Der rechtliche Kontext, als Fakten

Zwei Ereignisse haben die Diskussion um Google Fonts in Deutschland geprägt, und wir führen sie hier als Fakten an, ohne zu bewerten, was sie für eine bestimmte Website bedeuten. Diese Bewertung wäre Rechtsberatung, und die gibt dieser Artikel nicht.

Am 20. Januar 2022 hat das Landgericht München I im Verfahren 3 O 17493/20 gegen den Betreiber einer Website entschieden, die Google Fonts von Googles Servern geladen und dabei die IP-Adresse des Besuchers ohne dessen Einwilligung an Google übermittelt hatte. Das Gericht verurteilte den Betreiber zur Unterlassung der Übermittlung und sprach dem Kläger 100 Euro Schadensersatz zu. Die veröffentlichte Entscheidung ist im Rechtsportal des Freistaats Bayern abrufbar.

Am 21. Dezember 2022 hat die Polizei Berlin im Auftrag der Staatsanwaltschaft Berlin Durchsuchungsbeschlüsse gegen einen Rechtsanwalt und dessen Mandanten vollstreckt, wegen des Verdachts des (teils) versuchten Abmahnbetrugs und der (versuchten) Erpressung in mindestens 2.418 Fällen, so die Pressemitteilung der Polizei. Die Schreiben waren bundesweit an Privatpersonen und Kleingewerbetreibende gegangen, deren Websites Google Fonts einsetzten. Das ist die „Abmahnwelle“, auf die sich die Selbsthosting-Annahme oben bezieht.

Häufige Fragen

Prüfe eine Site selbst

Füge unten eine beliebige URL ein, um jeden Webfont zu sehen, den eine Seite lädt, und den Host, von dem sie ihn lädt. Wenn dich nur die Google-Frage interessiert, beantwortet der Google-Fonts-Checker sie direkt; die DevTools-Anleitung zeigt, wie du dieselben Informationen in Chrome und Firefox abliest; und die Schriftart-Vorschau lässt dich eine Ersatzschrift auf einer Seite ausprobieren, bevor du etwas änderst.

Quellen

• Google: Google Fonts CSS API, Technical considerations, Google Fonts FAQ
• Chrome: Gaining security and privacy by partitioning the cache (Chrome 86)
• Mozilla: Firefox 85 cracks down on supercookies (Netzwerk-Partitionierung)
• web.dev: Best practices for fonts
• MDN: font-display, unicode-range, rel=preconnect, Cross-Origin Resource Sharing
• W3C CSS WG: CSS Fonts Module Level 4 - font fetching requirements
• Adobe: Adobe Fonts, Adobe Fonts privacy notice
• Monotype: Hosting web fonts and reporting
• Bunny: Bunny Fonts, About Bunny Fonts
• Plattformen: Webflow - Asset privacy, Framer - Allowlist Framer domains, Shopify - font_url-Filter
• Landgericht München I, Urteil vom 20. Januar 2022, 3 O 17493/20 (Bayern.Recht)
• Polizei Berlin, Pressemitteilung vom 21. Dezember 2022 zu den Durchsuchungen nach der Google-Fonts-Abmahnwelle
• Eigene Messungen vom 21. September 2026: Snapshot der Scan-Datenbank (1.957 Sites); HTTP-Antwort-Header von fonts.googleapis.com, fonts.gstatic.com und fonts.bunny.net

Site-Beispiele verlinken auf unser Profil der jeweiligen Site zum Zeitpunkt des Scans; die oben genannten Schriften und Hosts sind die in diesem Scan erfassten und können sich seither geändert haben. Alle Zahlen beziehen sich auf den Stand vom 21. September 2026. Zitate aus englischsprachigen Quellen haben wir übersetzt; verlinkt ist jeweils das Original.