Wie Websites ihre Schriften wirklich ausliefern

Stand 5. Oktober 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. Die erste Fassung dieser Studie (21. September 2026) stützte sich allein auf diesen statischen Abruf. Für diese Fassung (5. Oktober 2026) wurde jede Site zusätzlich in einem echten, gerenderten Browser geladen, und wir lesen jedes Stylesheet, das nach dem Laden der Seite aktiv ist - also auch per JavaScript nachgeladene Schriften und Schriften, die eingebundene Drittanbieter-Tools wie Chat-Widgets, Consent-Banner, Newsletter-Pop-ups und Zahlungsbuttons mitbringen. Sites, deren Bot-Schutz auch den Browser blockiert, bleiben bei der statischen Messung. Der Browser interagiert nicht mit der Seite: Eine Schrift, die erst nach einer Interaktion geladen wird - nach der Zustimmung in einem Consent-Banner oder beim Öffnen eines Chat-Fensters -, wird nicht erfasst; die Widget-Zahlen unten sind deshalb eine Untergrenze, keine vollständige Zählung. Für jede Schrift speichert der Scanner das src der Regel - und dieses src nennt den Host, der die Schriftdatei tatsächlich ausliefert. 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: 2.079 Sites, Stand 5. Oktober 2026. Bei 1.939 davon enthielt die gespeicherte Regel eine verwertbare Quell-URL; jede Prozentangabe in diesem Artikel bezieht sich auf diese 1.939 Sites, sofern nichts anderes gesagt wird. Der Auslieferungsweg einer Site ergibt sich aus dem Host der ersten src-URL jeder ihrer Nicht-Fallback-Schriftregeln, verglichen mit der registrierbaren Domain der Site. Eine Schrift, deren Datei von dieser Domain kommt - relative URLs wie /fonts/… zählen als eigene Domain -, gilt als selbst gehostet; alles andere gilt als Drittanbieter-Host. Google, Adobe und Bunny erkennen wir an ihren bekannten Hostnamen.

Die Verschiebung zwischen den beiden Fassungen hat zwei Gründe, die beide in der Messung liegen, nicht in den Websites, und wir können sie trennen. Der erste ist der gerenderte Durchgang. Mit der Auswertungsregel der ersten Fassung ergaben die Daten der zweiten Fassung für „jede Schrift von der eigenen Domain“ 53,9 % statt 60,2 %. Von den 1.106 Sites, die in der ersten Fassung als „nur eigene Domain“ galten, haben in der gerenderten Messung 129 Fremd-Hosts für Schriften (gezählt am 25. September; zu diesem Snapshot in derselben Größenordnung): 63 nur wegen per JavaScript nachgeladener Google Fonts, 47 nur wegen anderer Fremd-Hosts - überwiegend eingebundene Widgets -, 12 aus beiden Gründen und die restlichen 7 wegen Schriftdiensten oder Plattform-CDNs.

Der zweite Grund ist die Korrektur eines Auswertungsfehlers, der schon in der ersten Fassung steckte. Eine protokoll-relative Schrift-URL - //www.zillowstatic.com/…, ohne das https: - nennt einen Host wie jede absolute URL, aber die erste Fassung hat sie nicht als solche gelesen und solche Schriften als eigene Domain gezählt. Korrigiert sinkt „jede Schrift von der eigenen Domain“ weiter, von 53,9 % auf 51,8 % - 42 Sites. Die Selbsthosting-Zahlen der ersten Fassung sind damit leicht zu hoch. Ihre Rohdaten liegen nicht mehr vor, eine korrigierte erste Fassung können wir deshalb nicht angeben; wir können nur sagen, dass der Fehler sie in dieselbe Richtung verschoben hat wie der statische Abruf. Kurz: Die erste Fassung hat die Auslieferung über Dritte unterschätzt.

Beim Einordnen wurde noch etwas deutlich: „selbst gehostet oder CDN“ ist eine falsche Gegenüberstellung. 569 der 1.939 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, oder eine selbst gehostete Markenschrift neben der Schrift eines eingebundenen Chat-Widgets. 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 auf nur 2 Sites auf - zwei Schriftgießerei-Sites, fontsmith.com und milieugrotesque.com -, die zusammen 120 Schriftreferenzen deklarieren, weil jede viele Schnitte aufführt. Nach Referenzen gezählt, wie in der ersten Fassung, lag Monotype unter den häufigsten Hosts; nach Sites gezählt, wie im Ranking unten, kommt es gar nicht vor. Dieser Abstand ist der Grund, warum das Ranking jetzt Sites zählt.

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 shopify.com ist das nach unserer Regel die eigene Domain, dieselbe registrierbare Domain; für den Shop eines Händlers auf der Plattform ist derselbe Host ein Dritter. Für die Besucher der Sites, die auf diesen Plattformen laufen, sind die Plattform-CDNs 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 weiterhin die Regel, aber weniger ausschließlich, als die erste Fassung nahelegte. 1.573 von 1.939 Sites (81,1 %) liefern mindestens eine Schrift von der eigenen Domain, und 1.004 (51,8 %) liefern jede Schrift auf diesem Weg - gut die Hälfte, wo die statische Messung drei von fünf gesehen hatte. Drittanbieter-Hosts sind auf 935 Sites (48,2 %) beteiligt, und die Schnittmenge dieser beiden Gruppen sind genau die oben erwähnten 569 Sites mit mehreren Wegen. Unter den eigentlichen Schriftdiensten dominiert Google: 512 Sites (26,4 %) laden mindestens eine Schrift von fonts.googleapis.com oder fonts.gstatic.com, gegenüber 87 (4,5 %) bei Adobe Fonts. Angesichts einer Stichprobe, die zu großen Marken mit eigener Entwicklung neigt, ist ein Viertel davon auf Googles Hosts die Zahl, die uns am meisten überrascht hat - und es war ein Fünftel, bevor der gerenderte Durchgang die per Skript geladenen Schriften hinzufügte.

Mischformen zeigen, wie es dazu kommt. ycombinator.com hostet Avenir selbst und holt DM Sans, Source Serif 4 und Material Symbols von fonts.googleapis.com; a16z.com kombiniert ein Adobe-Kit mit einer EB-Garamond-Datei von fonts.gstatic.com. zillow.com liefert Inter, Ivar Headline und Object Sans von www.zillowstatic.com - protokoll-relativ eingebunden, als //www.zillowstatic.com/…, genau das Muster, das die erste Fassung als eigene Domain fehlgelesen hat - und Open Sans von fonts.gstatic.com. framer.com, die Site eines Unternehmens, dessen Produkt Schriften hostet, liefert seine Markenschriften (unter anderem GT Walsheim) über das eigene Asset-CDN framerusercontent.com aus und referenziert daneben mehrere Google-Dateien (unter anderem Geist und EB Garamond) direkt. Nach unserer Regel zählen die beiden letzten als „nur Fremd-Hosts“, weil zillowstatic.com und framerusercontent.com andere registrierbare Domains sind - die Grenze „Domains, nicht Unternehmen“ aus dem Methodenteil in Aktion. 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

fonts.googleapis.com führt mit großem Abstand mit 422 Sites. fonts.gstatic.com, der Host, zu dem Googles Stylesheet den Browser für die Schriftdateien schickt, ist auf 154 Sites erfasst. Beide sind Hälften eines Weges, eine Site kann unter beiden erscheinen, und zusammengenommen sind sie die 512 Sites (26,4 %) des Google-Wegs oben. Adobe folgt mit 87 Sites auf use.typekit.net - dieselben 87 wie in der Tabelle der Auslieferungswege, weil Adobe Stylesheet und Dateien von einem Host ausliefert. Dann kommen die drei Plattform-CDNs - Webflow mit 29, Shopify mit 15 und Framer mit 13 Sites -, die mit der Wahl eines Schriftdienstes nichts zu tun haben, und use.fontawesome.com mit 16 Sites, die gehostete Auslieferung der Font-Awesome-Icon-Fonts: ein Schriftdienst, aber einer, der Icons statt Textschriften liefert. Hosts eingebundener Tools - Chat-Widgets, Consent-Banner und Ähnliches - sind in diesem Ranking nicht enthalten; sie haben unten einen eigenen Abschnitt. Ebenso wenig Monotype, mit 120 Referenzen von 2 Sites.

Schriften, die mit einem Widget kommen

Der gerenderte Durchgang hat einen Weg sichtbar gemacht, den die erste Fassung gar nicht sehen konnte. 62 der 1.939 Sites bekommen mindestens eine Schrift über ein eingebundenes Drittanbieter-Tool - ein Chat-Widget, ein Consent-Banner, ein Newsletter-Pop-up, einen Zahlungsbutton -, das sein eigenes Stylesheet mitbringt und seine Schrift vom Host des Tool-Anbieters lädt. Bei 27 dieser 62 Sites sind diese Tools die einzigen Fremd-Hosts für Schriften: Die Site selbst liefert jede ihrer eigenen Schriften von der eigenen Domain. Beide Zahlen sind Untergrenzen - der Browser klickt nichts an, ein Tool, das seine Schrift erst beim Öffnen eines Chats oder nach der Zustimmung lädt, ist also nicht enthalten.

Die Kategorien überschneiden sich - eine Site kann mehr als ein solches Tool einbinden -, deshalb summieren sich die Zeilen auf mehr als 62. Beispiele sind Sites aus unseren Daten, auf denen das Tool der jeweiligen Zeile eine Schrift lädt.

Als Messung sagt das: Wer seine eigenen Schriften selbst hostet, kann trotzdem Schriftanfragen an Dritte auslösen - über Tools, die niemand als Schriftquelle wahrnimmt. Dass Consent-Banner darunter sind, ist das Detail, das uns am meisten aufgefallen ist. Was das für eine bestimmte Site bedeutet, hängt davon ab, was der Anbieter des Tools mit den Anfragen macht - das steht in dessen Dokumentation, nicht in unseren Daten; wir berichten die Anfragen, nicht ihre Folgen. Eine plausible Lesart ist, dass die Betreiber vieler dieser Sites von diesen Anfragen nichts wissen. Wir haben sie nicht gefragt, das bleibt also eine Interpretation.

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. 10,6 % der 66 .de-Sites - 7 Sites - laden eine Schriftdatei oder ein Stylesheet von einem Google-Host, gegenüber 24,7 % der 1.199 .com-Sites, weniger als die halbe Rate. Die beiden anderen europäischen Gruppen in der Tabelle zeigen in dieselbe Richtung: .nl mit 11,5 % und .fr mit 12,5 %, beide unter dem .com-Wert.

Wie viel Gewicht das hat, ist eine Frage der Arithmetik, also hier ist sie. Bei 7 von 66 Sites in der .de-Gruppe ergibt ein Zwei-Anteile-z-Test gegen .com für den Abstand p ≈ 0,009; in der ersten Fassung, mit 6 von 62, waren es p ≈ 0,056. Das liegt unter der üblichen Fünf-Prozent-Schwelle - aber die Tabelle betrachtet 6 Domain-Gruppen, und was dann gilt, hängt davon ab, wie man für Mehrfachvergleiche korrigiert: Korrigiert für 6 Vergleiche (0,05 / 6 ≈ 0,0083) liegt p ≈ 0,009 knapp über der Schwelle, korrigiert für 5 Vergleiche gegen .com (0,05 / 5 = 0,01) knapp darunter. Dazu kommt, dass der .de-Anteil auf 7 Sites ruht, eine Handvoll mehr oder weniger ihn also um mehrere Punkte verschieben würde, dass die .nl- und .fr-Gruppen mit 26 und 24 Sites noch kleiner sind und dass nichts davon eine Zufallsstichprobe ist. Also: Die Daten deuten darauf hin, dass deutsche Sites seltener Schriften von Googles Servern laden als .com-Sites - sie legen es nahe, sie belegen es nicht. Es bräuchte eine 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. Und ob die Abmahnwelle der Grund für den Abstand ist, ist eine mögliche Deutung, nicht etwas, das diese Zahlen zeigen können.

Eine methodische Anmerkung, weil sie unsere eigene Antwort verändert hat. Ein früherer Stand dieser Tabelle, in der ersten Fassung, 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.939 Sites lädt eine Schrift von fonts.bunny.net. Unser Scanner erkennt den Host ausdrücklich, es ist also keine Erkennungslücke, und der gerenderte Durchgang - der bei 129 Sites, die die statische Messung als „nur eigene Domain“ gezählt hatte, Fremd-Hosts hinzugefügt hat - hat daran nichts geändert. 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: Snapshot der Scan-Datenbank vom 5. Oktober 2026 (2.079 Sites, Durchgang im gerenderten Browser); Snapshot der ersten Fassung vom 21. September 2026 (1.957 Sites, statischer Abruf); HTTP-Antwort-Header von fonts.googleapis.com, fonts.gstatic.com und fonts.bunny.net, geprüft am 21. September 2026

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 Site-Zahlen beziehen sich auf den Stand vom 5. Oktober 2026; die erste Fassung dieses Artikels, gemessen am 21. September 2026, ist im Kasten oben zusammengefasst. Zitate aus englischsprachigen Quellen haben wir übersetzt; verlinkt ist jeweils das Original.