Viele Webseiten nutzen externe Google Schriften. Die Schriften werden dadurch von einem Google Server geladen. Dieser Beitrag zeigt, dass das Einbinden von Google Fonts in dieser Weise problematisch und eigentlich unmöglich ist. Die für die meisten Webseiten akzeptable Lösung ist einfach.
Update Oktober 2022
Empfehlungen bei erhaltenen Abmahnungen:
Das wichtigste: Zuallererst alle Google Fonts Einbindungen entfernen. Auch Google Maps und Google reCAPTCHA binden Google Fonts ein. Am besten alle Google Tools entfernen, zumindest kurzfristig. Statt Google Maps mein Karten-Plugin verwenden. Statt Google reCAPTCHA tut es oft eine textuelle Rechenaufgabe mit Eingabefeld („Wie viel sind 17 weniger drei? Bitte als Wort schreiben.“).
Update vom 26.08.2022
Das folgend genannte Urteil des LG München schwappte mittlerweile nach Österreich. Es führte zu so großen Verwerfungen, dass sogar die Datenschutzbehörde der Repubik Österreich ein amtswegiges Prüfverfahren gegen Google wegen Google Fonts eingeleitet hat (laut Bekanntmachung vom 23.08.2022).
Update vom 31.01.2022
Mittlerweile gibt es ein Urteil des LG München, wonach das Einbetten von Google Fonts als rechtswidrig eingestuft wurde. Ich hatte es schon immer so gesehen, wie mein folgender Beitrag zeigt. Dadurch kamn eine Abmahnwelle in Deutschland ins Rollen.
Einleitung
Im Gegensatz zu einigen meiner vorigen Beiträge, u.a. zu Cookies, zur ePrivacy Richtlinie oder zu Consent Tools, sind die folgenden Informationen nicht weltbewegend. Die Kombination aus technischer und rechtlicher Betrachtung sowie die technische Lösungsmöglichkeit sind hoffentlich halbwegs neuartig. Allerdings musste ich bereits feststellen, dass selbst eine selbst ernannte Datenschützerin absichtlich weiter externe Google Schriften nutzt. Ich vermute, sie macht das entweder, weil sie sich (durch die rechtswidrige Einbindung) SEO-Effekte erhofft oder weil sie die weiter unten genannte Lösung nicht kennt.
Andere Schriften als die von Google sind übrigens teilweise noch eindeutiger einwilligungspflichtig. Beispielsweise Fast Fonts (fonts.com), weil diese einen Zählpixel zu Abrechnungszwecken einsetzen.
Google Schriften werden auch als Google Fonts bezeichnet. Sie zeichnen sich dadurch aus, dass nahezu jede Schriftart unterstützt wird und vermeintlich einfach und ohne finanzielle Kosten in Webseiten eingebunden werden kann. Bindet man Google Fonts so ein, wie es Google vorschlägt, werden Verbindungen zu Google Servern aufgebaut.
Hier ein reales Beispiel eines solchen Datentransfers, der durch eingebundene Google Schriftarten verursacht wird:

Wie im Netzwerk-Protokoll zu sehen ist, werden gleich zwei verschiedene Domäne angerufen, nämlich googleapis.com und gstatic.com bzw. die dazu gehörigen Subdomänen.
Diese Art der Einbindung nenne ich externe Google Schriften, weil sie von Google Servern geladen werden. Anders sieht es aus, wenn die Schriften von einem eigenen Server oder einem Server eines Anbieters geladen werden, mit dem vetragliche Garantien abgeschlossen wurden.
Ich habe mich entschieden, diesen Beitrag auch in die Kategorie Bullshit Basics zu packen, weil viele immer noch versuchen, alle möglichen Argumente zu suchen, warum externe Google Schriften auf einmal doch erlaubt sein sollen.
Wie sieht es mit dem Datenschutz aus?
Das Einbinden von externen Google Schriften verstößt gegen Art. 5 Abs. 1 DSGVO. Dort ist das Prinzip der Datenminimierung genannt. Dem entgegen steht ein etwaiges berechtigtes Interesse, welches bestimmte Datenverarbeitungen erlaubt. Das berechtigte Interesse ist in Art. 6 DSGVO definiert. Wer Daten erhebt, muss nach Art. 5 Abs. 2 DSGVO nachweisen, dass er die Grundsätze des Art. 5 Abs. 1 DSGVO (Datenminimierung etc.) einhält.
Der Verstoß liegt vor, weil es ohne Weiteres möglich ist, Google Schriften lokal einzubinden. Dabei werden einfach alle benötigten Schriftendateien heruntergeladen, entsprechend angepasst und dann auf dem eigenen Web Server abgelegt. Nun können lokale Dateien auf der eigenen Webseite eingesetzt werden. Ein Datentransfer zu Google oder anderen Dritten findet damit nicht mehr statt.
Der Art. 25 DSGVO bedingt eine datenschutzfreundlichen Technikgestaltung.
Somit ist gezeigt, dass das berechtigte Interesse eindeutig ausscheidet. Niemand wird vor Gericht damit durchkommen. Sollte jemand etwas anders behaupten, hat er entweder keine Ahnung oder nimmt die falschen Tabletten und leidet an maßloser Selbstüberschätzung.
Was ist mit Cookies?
Für gewöhnlich werden beim Abruf von Google Schriften keine Cookies verarbeitet. Ich gebe allerdings zu bedenken, dass dies auch anders sein kann. Es reicht auch, wenn es weltweit eine einzige öffentlich erreichbare Webseite gibt, die in der Domäne der Google Fonts liegt.
Diese Art von Webseiten gibt es zuhauf, wie eine Suche nach Webseiten mit der Hauptdomäne googleapis.com beweist:

Von diesen zahlreichen vorhandenen Webseiten setzen einige Cookies auf einer Domäne, die Google Fonts betrifft. Ruft nun eine Person eine dieser Webseite auf und danach eine deutsche Webseite, die externe Google Schriften lädt, verstößt diese deutsche Webseite dadurch gegen die ePrivacy Richtlinie. Zumindest müsste der Betreiber der Webseite erst einmal beweisen, dass das Gegenteil der Fall ist. Ich hoffe für ihn, dass er dann die Telefonnnummer eines sehr guten Kontakts bei Google zur Hand hat.
Mir selbst sind solche Webseiten bekannt, die Cookies erzeugen, welche dann für Google Schriften relevant werden. Demnach bedürfen Google Schriften auch einer Einwilligung aufgrund des Art. 5 Abs. 3 der ePrivacy Richtlinie in Verbindung mit dem BGH-Urteil vom 28.05.2020 – I ZR 7/16. Im Zweifel muss der Betreiber der Webseite beweisen, dass Google diese Cookies nicht nutzt, was ziemlich schwierig und unglaubhaft sein dürfte. Schließlich handelt es sich um sogenannte Third-Party Cookies.
Was ist mit Google?
Meiner Meinung nach sind zahlreiche Google Tools, ohne jegliche Ausnahme, nicht datenschutzkonform nutzbar. Ob Google Tools mit oder ohne Einwilligung geladen werden, ist eine andere Frage. Hier geht es um die transparente, konkrete Benennung der Pflichtangaben gemäß Art. 13 DSGVO.
Außerdem gibt Google selbst zu, Daten aus Ihrem Google Konto, wenn Sie dort angemeldet sind, mit erhobenen Daten beim Abruf von Google Fonts abzumischen. In der Datenschutzerklärung, die für Google Fonts gilt, steht:
Wir erheben Daten, […] wie zum Beispiel […] den Personen, mit denen Sie online am häufigsten zu tun haben, oder den YouTube-Videos, die Sie interessant finden. […]
Wenn Sie in einem Google-Konto angemeldet sind, erheben wir auch Daten, die wir in Ihrem Google-Konto speichern und als personenbezogene Daten erachten.
Google gibt direkt zu, Ihre persönlichen Daten auszubeuten
Demgemäß müssen u.a. folgende Informationen zu genutzten Google Tools angegeben werden:
- Zwecke der Datenverarbeitung beim Dienstanbieter
- Datenempfänger
- Risiken, etwa Transfers ins bestimmte Drittländer oder bestimmte Arten von Empfängern, wie etwa Behörden oder Geheimdienste
- Zwecke von Cookies (diese sind allgemein nur dem Dienstanbieter bekannt, der im Falle von Google die Zwecke meist nicht ausreichend verrät
Wie man leicht feststellen kann, können diese Angaben für Google Tools nicht konkret, transparent und korrekt gemacht werden.
Zusätzlich kann man für den Google Konzern immer den Art. 44 DSGVO anführen, den Datentransfer in unsichere Drittländer. Ich habe mir allerdings angewöhnt, dieses Problem nur untergeordnet zu nennen, weil die o.g. Datenschutzbetrachtungen bereits als Begründung gegen externe Google Schriften ausreichen.
Wer alle genannten Argumente für lokale und gegen externe Google Schriften als hinfällig ansieht , der kann sicher einen Vertrag vorlegen, den er mit Google geschlossen hat, um geeignete Garantien von Google für eine DSGVO-konforme Datenverarbeitung zu erhalten. Am besten sollte dann auch noch eine Abwahlmöglichkeit (Opt-Out) für erhobene Daten angeboten werden. Viel Vergnügen!
Auf der Webseite eines Anbieters eines Consent Tools wird letzteres übrigens mitgeteilt sowie ebenso die Problematik des Einsatzes von externen Google Schriften. Dass die genannte Webseite dann selbst externe Google Schriften verwendet, verwundert umso mehr. Da die Schriften nicht auf jeder Untrseite, und auch nicht auf der Seite mit dem Artikel zu Google Fonts zu finden sind, zeigt, dass der Anbieter des Consent Tools dies womöglich nicht absichtlich gemacht hat und mit der Einhaltung von Datenschutzvorgaben überfordert ist.
Was ist mit Content Delivery Networks?
Sogenannte CDNs bieten einen schnellen, hoffentlich jederzeit verfügbaren Speicher. Die Begründung für den Einsatz solcher Systeme ist oft eine vermeintlich schnellere Ladezeit der Webseite. Bisher konnte mir das allerdings niemand wirklich belegen (ich will nicht ausschließen, dass dies so ist, möchte aber einen Beweis zumindest für den ersten Ladevorgang haben!). Wie ein Kommentarschreiber zu diesem Beitrag erwähnt, sind Folgeaufrufe derselben Ressource, die von verschiedenen Webseiten gleichzeitig verwendet wird, optimiert. Folgeaufrufe innerhalb einer Webseite selbst sind allerdings durch den lokalen Cache des Nutzers sowieso schon schneller. Es geht hier also nur um einen Erstaufruf einer Webseite, die selbe Ressourcen genauso rechtswidrig einsetzt wie andere Webseiten einsetzt. Wenn ein lokaler Cache beim Nutzer langlebig ist, agiert er besser als jedes CDN. Da Google Fonts weiter verbreitet sind, ist die Chance, einen lokalen Cache-Treffer zu haben, groß. Wer seine Browser Caches aus Datenschutzgründen regelmäßig leert, möchte im Gegenzug wohl nicht von einem datenschutzfeindlichen CDN getrackt werden. Aus Sicherheits- und Datenschutzgründen nutzen moderne Browser mitunter ein Cache Partitioning. Dadurch existiert pro Webseite jeweils ein eigenständiger Cache. Somit ist das Argument des globalen Cache beim Nutzer, der sich über mehrere Webseiten hinweg aufbauen könnte, quasi hinfällig.
Es ist fraglich, ob das Laden einer kleinen, statischen Datei von einem CDN schneller vonstatten geht als von einem lokalen Speicher. Browser puffern Anfragen dieser Art, so dass bei Folgeaufrufen durch den gleichen Nutzer oft die lokale Kopie gezogen wird, was am allerschnellsten ist.
Lädt man Ressourcen von CDNs, kann der Browser Ladevorgänge möglicherweise parallelisieren, indem die Ladevorgänge von mehreren verschiedenenen Servern nahezu gleichzeitig angestoßen werden. Damit können Dateien vom lokalen Server nahezu gleichzeitig geladen werden wie Dateien von anderen Servern.
Wer meint, Google Fonts müssen von einem CDN geladen werden, damit der Erstaufruf der Webseite schneller ist, sollte erst einmal prüfen, ob nicht alle anderen Geschwindigkeitsoptimierungen auf der Webseite ausgeschöpft wurden. Wer unnötige, weil nicht verwendete Schriftarten lädt, braucht nicht mit dem Argument der schnelleren CDN-Ladezeit beim Erstaufruf zu kommen.
Wer unbedingt ein CDN einsetzen möchte, kann dies tun. Es muss aber sichergestellt sein, dass der Betreiber des CDN an die DSGVO gebunden ist und sich selbstverständlich auch daran hält. Amerikanische Unternehmen scheiden demnach als Anbieter von CDN aus, außer, man möchte mit Einwilligungen arbeiten und eine gewisse rechtliche Unsicherheit in Kauf nehmen.
Übrigens kann man auch selber ein CDN aufsetzen. Anscheinend ist der Betreiber der Webseite derart wichtig, dass er ein CDN benötigt. Dann sollte es möglich sein, dies zu tun. Es handelt sich schließlich nur um einen Datei-Server mit schneller Internet-Anbindung. Solche Server gibt es überall in Deutschland zu mieten. Gerne kann ein deutsches Unternehmen ein datenschutzkonformes CDN auf breiter Basis anbieten. Ich denke, hierfür gibt es einen Markt.
Auf keinen Fall sollte man meiner Meinung nach auf Cloudflare zurückgreifen, da dieser Anbieter nach meiner Recherche keinen guten Datenschutz bieten kann. Akamai kann ebenso nicht als datenschutzfreundlich angesehen werden.
Was ist die Lösung?
Google Fonts können lokal eingebunden werden. Dies kann man manuell bewerkstelligen oder mit Hilfe eines Hilfsprogramms. Das Hilfsprogramm lautet Google Webfonts Helper. Nach Aufruf der Webseite des Tools können Sie im linken Bereich (zumindest bei Desktok PC-Darstellung) eine Schriftart auswählen. Im Hauptbereich können dann die fertigen Dateien für eine lokale Einbindung der Schriften heruntergeladen werden.
Den manuellen Weg möchte ich hier zusätzlich beschreiben, auch um das Grundprinzip zu verdeutlichen.
Für den manuellen Weg lädt man sich die Schriftdateien herunter. Das geschieht wie folgt:
Externe Schriften werden über eine Datei wie die folgende geladen: https://fonts.googleapis.com/css?family=Roboto. Dies kann man im Quellcode der Webseite sehen. Eine andere Möglichkeit ist die Entwicklerkonsole von Firefox und anderen Browsern, die man mit der Taste F12 öffnen kann. Nachdem die Konsole geöffnet ist, die Webseite aufrufen. Der Karteireiter Netzwerkanalyse zeigt die Datentransfers. Dort findet man dann Ladevorgänge von der Domäne fonts.googleapis.com und weitere.
Öffnen Sie die Schriftdatei im Browser und kopieren Sie den Inhalt in eine Datei namens roboto.css (Name für andere Schrifttypen sinnvollerweise anders wählen).
Sie sehen Zeilen, in denen auf externe Dateien verwiesen wird. Diese sehen beispielsweise so aus:
src: url(https://fonts.gstatic.com/s/roboto/v20/KFOmCnqEu92Fr1Mu72xKOzY.woff2) format('woff2');
Normalerweise sind nur die Abschnitte relevant, die mit dem Kommentar /* latin */ versehen sind, ggfs. auch die mit erweitertem lateinischem Zeichensatz /* latin-ext */.

Laden Sie alle Dateien dieser Art herunter. Ändern Sie in roboto.css die Angabe so, dass sie auf ihre lokale Datei zeigt. In den Nutzungsbedingungen von Google sehe ich keinen Hinweis, warum dies nicht erlaubt sein soll.
Ab sofort können Sie sich potentiell falsche Datenschutztexte zu Google Fonts sparen. Niemand kann Ihnen ab jetzt vorwerfen, Sie hätten den Datenschutztext vergessen oder würden mit externen Google Schriften gegen Datenschutzregeln verstoßen.
Wie man sieht, ist die Lösung relativ einfach und keine Raketenwissenschaft. Es spielt für den Datenschutz hier keine Rolle, dass diese Vorgehensweise am besten von einer technikaffinen Person erledigt wird. Fragen Sie bei Bedarf jemanden, der sich damit auskennt. Wenn er gut ist, wird er es in sehr kurzer Zeit hinbekommen.
Für WordPress-Webseiten empfehle ich den Einsatz von Design Themes, die entweder Google Schriften lokal einbinden oder eine Option dafür bereitstellen.
Mit meinem online Webseiten-Check kann schnell geprüft werden, ob eine Webseite Google Fonts einsetzt. Der Check prüft nur die ersten paar Unterseiten. Das reicht meist für eine gute Einschätzung aus.
Mögliche Gegenargumente und Entgegnungen
Das Gegenargument der angeblich längeren Ladezeiten kann bei kleinen Schriftartdateien, auch aufgrund meiner eigenen jahrelangen Erfahrung mit lokalen Schriften, ausgeräumt werden. Wer möchte, kann ja ein datenschutzkonformes CDN verwenden, aber nicht das von Google! Auch der Aufbau eines eigenen CDN ist möglich und lohnt sicher für Webseiten, die auf eine Ladezeit angewiesen ist, die fünf Millisekunden kürzer ist als das lokale Einbinden.
Weiter unten habe ich einen Geschwindigkeitstest beschrieben, der beweist, dass externe Google Schriften keine höhere Geschwindigkeit bringen.
Das Argument, dass die Schriften dann nicht mehr automatisch (von Google) gewartet werden, ist keines. Schließlich sollten Schriften dauerhaft genau so aussehen, wie sie installiert wurden. Dass Browser sich einmal erheblich ändern und ein Font Update erfordern würden, kommt sehr selten vor. Bei neu ausgelieferten Schriften wird es selten vorkommen, dass beim Design der Schrift der Punkt auf dem i vergessen wurde. Bei schon länger vorhandenen Schriften stellt sich die Frage, was sich noch ändern soll. Es geht um eine Schriftart und nicht um einen Atomreaktor.
Aus eigener Erfahrung weiß ich, dass es kein Wartungsproblem gibt. Zudem gibt es in anderen Fällen Urteile, wonach ein Unternehmer mit einem online Angebot verpflichtet ist, sich regelmäßig sein Angebot anzusehen und neu zu bewerten. Der Unternehmer gerät sogar dann in Haftung, wenn eine Plattform, auf der er seine Produkte anpreist, eigenständig und vollautomatisiert das Angebot des Unternehmers rechtswidrig werden lässt. Genau gleiches Engagement kann zu Schriften erwartet werden (vgl. etwa OLG Frankfurt, Beschluss vom 18.03.2021, Az. 6 W 8/18).
Lizenzrechtlich konnte mir bisher niemand zeigen, wo steht, dass die lokale Einbindung, wie ich sie oben beschreibe, unerlaubt sei. Im Gegenteil, die Schriften laufen unter der SIL Open Font License. Google kennzeichnet alle Schriften auf Google Fonts als Open Source und frei:
All the fonts and icons in our catalog are free and open source…
Quelle: https://fonts.google.com/about?preview.size=165
Dies wird von Google an anderer Stelle bestätigt: "All fonts are released under open source licenses. You can use them in any non-commercial or commercial project."
Manche meinen, durch Einbinden von Google Tools wird deren Webseite höher gewichtet und erscheint dann prominenter in Suchergebnissen der Google Suchmaschine. Alleine schon, weil viele Webseiten Google Tools einbinden, verfängt dieses Argument nicht. Zusätzlich kann ich aus Erfahrung behaupten, dass höherwertige Onpage SEO-Maßnahmen wesentlich weniger Effekt bringen als eine gute Content-Strategie. Zu dieser gehört auch das Verbreiten von Inhalten in geeigneten Medien. Hierzu bedarf es Google in keinster Weise (außer, man möchte auf YouTube ein Video veröffentlichen, aber auch hierzu gibt es bessere Alternativen, weil YouTube als überlaufen bezeichnet werden darf).
Übersicht der Entgegnungen
Manche sind recht kreativ, wenn es darum geht, den rechtswidrigen Einsatz von externen Google Schriften doch irgendwie zu rechtfertigen. Die folgende Tabelle zeigt eine kurze Darstellung der angeblichen Argumente und ihre Entgegnung.
Angebliches Argument | Entkräftung |
---|---|
Externe Google Schriften sind schneller | 1. Nutzen Sie doch Ihr eigenes CDN oder ein DSGVO-konformes 2. Schriften machen oft nur einen Bruchteil der Ladezeit einer Webseite aus und lokale Schriften sind nicht wirklich langsam. Sie machen nur einen kleine Teil der Ladezeit aus. Schauen Sie sich meinen Test weiter unten an 3. Haben Sie ansonsten, wo Ihnen Geschwindigkeit im Millisekundenbereich wichtig zu sein scheint, tatsächlich alle anderen Maßnahmen ergriffen? Falls nicht, wäre Ihr Argument unglaubwürdig 4. Siehe Art. 5 DSGVO und Art. 25 DSGVO 5. Vergleiche Storage Partitioning. Damit wird die Ladezeit von lokal geladenen Schriften im Vergleich mit externen Schriften noch besser gestellt. |
Lokale Schriften machen zu viel Arbeit | 1. Ich brauche nur wenige Minuten, um Google Schriften lokal einzubinden 2. Suchen Sie sich jemanden, der es schnell hinbekommt 3. Wenn Sie einen Parkplatz suchen, brauchen Sie doch auch länger als ein Falschparker 4. Siehe Art. 5 DSGVO und Art. 25 DSGVO |
Google Schriften dürfen nicht lokal eingebunden werden | Wo steht das? Selbst falls es so wäre: Jeder kann sich TrueType Schriften herunterladen (auch von der Google Fonts Plattform) und diese in Web Fonts umwandeln. Hierfür gibt es frei verfügbare Hilfsprogramme. Achtung: Die SIL Open Font License von Google Fonts erfordert eine Umbenennung der Schriftart nach Konvertierung, sofern ein Weiterverteilen stattfindet (siehe Kommentar nach dem Beitrag). Auf der Webseite von Google Fonts steht etwa für die Roboto Schriftart: You can use them freely in your products & projects – print or digital, commercial or otherwise. However, you can't sell the fonts on their own. Siehe außerdem Art. 5 DSGVO und Art. 25 DSGVO |
Nur externe Google Schriften sind wartungsfrei | Bevor eine Schriftart aus rein technischen Gründen ausgetauscht werden muss, hat sich die Webseite mehrmals selbst überholt. Ich habe mir einige Font Updates auf dem Google Fonts Marktplatz angesehen. Die Updates sind allesamt nicht notwendig, wenn die Schrift bereits zuvor eingesetzt wurde. Sie betreffen oft neue Schrifttypen (etwa Semifettdruck) oder rein organisatorische Gründe. Die Notwendigkeit eine Wartung kommt quasi nie vor – das kann ich nach 30 Jahren IT Erfahrung behaupten. Hier ein weiterer Beleg: Die Quelldateien der Roboto Schriftart wurden zuletzt vor vier Jahren aktualisiert. Lediglich das Make File wurde syntaktisch im Jahr 2020 optimiert, was keine Rolle spielt, wenn man die Schriften als Endprodukt verwendet. Zudem sind Unternehmer verpflichtet, Ihre Angebot regelmäßig zu prüfen und ggfs. die Schriftart auszutauschen. Zudem sorgt der lokale Zwischenspeicher in Nutzer-Browsern dafür, dass Schriften teils erst nach einem Jahr oder mehr erneut abgerufen werden. Siehe außerdem Art. 5 DSGVO und Art. 25 DSGVO |
Externe Google Schriften werden gecacht | Stimmt. Aber auch alle anderen Dateien landen genauso im Browser-Cache. Wird eine Webseite zum ersten Mal aufgerufen, mag das bei populären Schriftarten einen Unterschied machen. Keinen Unterschied macht es bei Folgeaufrufen oder wenn der Nutzer aus Datenschutzgründen seinen Browser-Cache häufig leert. Es gibt sogar Hilfsprogramme, die dies tun, wie etwa die Open Source Lösung BleachBit. Ein partitionierter Cache moderner Browser (Cache Partitioning) sorgt aus Sicherheits- und Datenschutzgründen sogar dafür, dass es keinen globalen Cache gibt, der Webseiten-übergreifend arbeiten würde. |
Für bestimmte Schriften wird der Download geblockt | Dieses Argument ist unzutreffend. Google Fonts ist eine Plattform, die auch Schriften anderer Anbieter anzeigt, aber zum Download auf die Webseiten der Anbieter verweist. Beispiel: Palatino Font, welche insofern überhaupt keine Google Font ist, sondern die eines anderen Anbieters (nämlich Monotype, fonts.com) |
Bessere Auffindbarkeit | Durch eingebundete Google Tools erhält Google ein Signal, dass eine Webseite aufgerufen wurde. Dieses Signal darf rechtlich nicht ausgewertet werden, um die Webseite höher zu gewichten. Unabhängig davon bringt es auch nichts. SEO-Maßnahmen ab einem bestimmten Reifegrad bringen um mindestens eine Größenordnung weniger Erfolg als eine zielgerichtete Content-Strategie und -Verteilung, wie ich aus Erfahrung berichten kann. Siehe außerdem Art. 5, Art. 25 und Art. 44ff DSGVO. |
Wenn Sie ruhig schlafen möchten oder etwas für den Datenschutz tun wollen oder einfach nur Gesetze einhalten möchten, dann binden Sie Google Schriften lokal ein.
Die Haltung von Aufsichtsbehörden
In Deutschland gibt es pro Bundesland eine Datenschutzaufsichtsbehörde und zusätzlich den Bundesdatenschutzbeauftragten, der etwa für öffentliche Stellen zuständig ist.
Die Äußerungen von Aufsichtsbehörden sind Meinungen, nämlich Behördenmeinungen. Sie können herangezogen werden, um eine Risikoabwägung vorzunehmen. Damit kann abegschätzt werden, wie wahrscheinlich ein Bußgeld durch eine Aufsichtsbehörde ist. Die juristische Frage lässt sich so nicht klären. Gerichte können Behördenmeinungen als Anhaltspunkt ansehen, sind aber daran in keinster Weise gebunden. Datenschutzbehörden sind grundsätzlich kulanter als Gerichte, so ist meine Erfahrung. Das hilft wenig, wenn eine Abmahnung durch eine Privatperson oder einen Wettbewerber ansteht.
Jeder Landes-Datenschutzbeauftragte hat möglicherweise eine andere Meinung und Empfehlung. Hier zwei Beispiele:
- Bayern: Nach dem Urteil des LG München vom 20.01.2022 hat der BayLDA den Einsatz von Google Fonts für öffentliche Stellen quasi untersagt. Erlaubte zuvor externe Google Fonts. Warum, ist mir nicht klar (eine Begründung fehlt in den FAQ). Dankenswerterweise hat die bayerische Behörde mir geantwortet, und zwar sehr schnell und umfassend. Die Antwort macht.e deutlich, dass ein Datentransfer in unsichere Drittländer als kritisch angesehen wird und externe Schriften an sich, aber nicht in jedem Fall erlaubt sind. Bayern weist darauf hin, dass der Datentransfer in die USA ohne Einwilligung nur unter der strengen Vorgabe des Schrems-II-Urteils möglich ist.
- Baden-Württemberg: Keine explizite Position, sondern ein Hinweis auf Datenschutzprobleme und die Empfehlung, Schriften lokal einzubinden.
Geschwindigkeitstest: lokale versus externe Google Schriften
Für den Vergleich wurde die ansonsten gleiche HTML Seite einmal mit externen Google Schriften und einmal mit lokalen Google Schriften getestet. Die externen Google Fonts wurden, wie von Google empfohlen, mit preconnect eingebunden, so dass eine schnellere Ladezeit möglich ist.
Zum Test wurde der online Webpagetest verwendet. Der Test wurde von einem Server in Frankfurt mit dem Chrome Browser durchgeführt.
Testlauf mit externen Google Schriften
Das Ergebnis zeigt in einer Übersicht den Anteil der externen Schriften an der Gesamtladezeit und den Datentransfer:

Wie man sehen kann, haben die externen Google Schriften einen Anteil von 15% an der Gesamtzeit aller Anfragen, die zum Abruf der Webseite erforderlich sind. Der Anteil der übertragenen Daten beträgt 20,1% vom Gesamtumfang.
In einer Wasserfall-Diagramm Darstellung stellt sich die Ladezeit für externe Google Schriften wie folgt dar:

Die relevante Ladezeit ist aber die blockierende Zeit, also die Zeit, die der Abruf mit externen Google Schriften länger dauert als es ohne diese Schriften der Fall wäre:

Hier sind die relevanten Ladezeiten genauer zu sehen:

Die erste Anfrage startete bei Zeitpunkt 0,696 Sekunden. Die letzte Anfrage endete bei Zeitpunkt 0,699 Sekunden + 88 Millisekunden (Time to first byte) +26 Millisekunden (Content Download) = 0,813 Sekunden
Die relevante Gesamtladezeit für den Erstabruf betrug bei externen Google Schriftarten also insgesamt 0,813 – 0,699 Sekunden = 114 Millisekunden.
Analog wurde der Folgeabruf ausgewertet. Er betrug 91 Millisekunden.
Testlauf mit lokalen Google Schriften
Das Ergebnis zeigt in einer Übersicht den Anteil der lokalen Schriften an der Gesamtladezeit und den Datentransfer:

Der Anteil an der Ladezeit bezüglich aller Requests ist bei lokalen Google Schriften so gering, dass ich mit dem Cursor über das rote Kuchenstück fahren musste. Er beträgt 12,8%. Der Anteil der übertragenen Daten beträgt 18,3% vom Gesamtumfang. Allerdings ist hier anscheinend die Verbindungszeit nicht mit eingerechnet.
Beim Erstabruf erzeugen lokale Google Schriften folgende Ladezeiten:

Die relevante Ladezeit ist aber die blockierende Zeit, also die Zeit, die der Abruf mit lokalen Google Schriften länger dauert, als es ohne diese Schriften der Fall wäre. Ein Diagramm nach Servern wie bei externen Google Schriften bringt hier nicht weiter, weil auch andere Dateien als Schriften vom Server der Webseite geladen werden.
Hier sind die relevanten Ladezeiten genauer zu sehen:

Die erste Anfrage startete bei Zeitpunkt 0,772 Sekunden. Die letzte Anfrage endete bei Zeitpunkt 0,775 Sekunden + 270 Millisekunden (Time to first byte) +1 Millisekunden (Content Download) = 1,046 Sekunden.
Die relevante Gesamtladezeit für den Erstabruf betrug bei lokale Google Schriftarten also insgesamt 1,046 – 0,772 Sekunden = 274 Millisekunden.
Analog wurde der Folgeabruf ausgewertet. Er war ungefähr gleich schnell wie der Erstabruf.
Ergebnis des Geschwindigkeitstests
Am besten sieht man das Ergebnis bei einer Gegenüberstellung.
Kriterium | Externe Google Schriften | Lokale Google Schriften |
---|---|---|
Ladezeit 1. Abruf | 114 ms | 211 ms |
Ladezeit 2. Abruf | 91 ms | 225 ms |
Externe Google Schriften sind etwas schneller als die lokale Einbindung. Betrachtet man die gesamte Ladezeit der Webseite, dann entsteht folgende Statistik (die Gesamtladezeiten sind als Nenner der Brüche angegeben, alle Angaben in Millisekunden):
Anteil Ladezeit an Gesamtladezeit | 1. Abruf | 2. Abruf |
---|---|---|
Externe Google Schriften | 114 / 2432 = 4,7% | 91 / 2469 = 3,7% |
Lokale Google Schriften | 211 / 2482 = 8,5% | 217 / 2426 = 8,9% |
Die Gesamtladezeit war mit externe Google Schriften gegenüber lokal eingebundenen Schriften beim Erstabruf der Webseite um 3,8% schneller und beim Folgeabruf um 5,2%.
Die Optimierungsmaßnahmen für meine Webseite haben gezeigt, dass eine Verbesserung der Ladezeit durch ganz andere Maßnahmen wesentlich effektiver stattfinden kann. Beispiele: Caching auf Ebene der Datei htaccess aktivieren, Bilder weiter komprimieren, unnötige Plugins deaktivieren.
Der Test fand übrigens mit dieser Webseite statt. Sicher ist er nicht akademisch verwertbar, weil die Anzahl der Tests zu gering ist und die Schwankung der Ladezeiten bei mehreren Tests einige Prozent beträgt. Anhand der Ergebnisse und der genannten Argumente und Fakten kann sich jeder sein eigenes Bild machen.
Wer sich immer noch auf das Geschwindigkeitsargument für externe Google Schriften beruft, der muss nachweisen, dass
- wenige Millisekunden beim Erstaufruf der Webseite geschäftskritisch sind,
- kein DSGVO-konformes CDN bereitsteht (das ist allerdings immer noch kein Argument),
- ein eigenes CDN, im einfachsten Fall auch File Server genannt, nicht möglich ist (das wird schwierig zu zeigen),
- wirklich alle anderen Maßnahmen bereits voll ausgeschöpft sind (viel Erfolg!)
- beim Abruf externer Schriften kein Datentransfer in unsichere Drittländer stattfindet
- Google die erhaltenen Verkehrsdaten nicht für eigene Zwecke nutzt und nicht an Dritte weitergibt (Dritte sind alle, die ungleich Google Ireland Ltd. sind)
Lokale Schriften schneller laden
Wer mehr als eine Schriftartdatei einbindet (typische Dateiendung: woff oder woff2), der sollte jede Schriftdatei separat einbinden und ein nichtblockierendes Laden verwenden. Letzteres lässt sich wie folgt erreichen:
<link rel="stylesheet" href="font1.css" type='text/css' media="none" onload="if(media!='all')media='all'"><link rel="stylesheet" href="font1.css">
Diese Zeile Code lädt eine Schriftdatei in asynchroner Weise. Dafür sorgt die Kennzeichnung media="none". Nachdem die Schriftdatei geladen wurde, wird der Mediendatei über die JavaScript-Anweisung im onload-Ereignis auf media="all" gesetzt, so dass die Schrift für die aktuelle Darstellung angewandt wird.
Die noscript-Anweisung sorgt dafür, dass die Schriftart auch für Browser, in denen JavaScript deaktiviert wurde, korrekt geladen wird.
Eigenen schnellen File Server aufsetzen
Für die eigenen Webseiten benötigt man kein Content Delivery Network (CDN). Ein CDN ist in erster Linie notwendig, weil ganz viele Webseiten daran angebunden sind.
Ein eigenes CDN, welches für nur wenige eigene Webseiten verwendet wird, kann man auch als schnellen File Server bezeichnen. Wer mehr möchte, baut sich eine Server-Infrastruktur mit Lastverteilung. Beim Abruf mehrerer Schriftartdateien werden mehrere CDN-Server eingeschaltet.
Ein solcher File Server ist ein Server mit schneller Internetanbindung und möglichst ohne Restriktionen bezüglich des Datentransfervolumens. Hierfür gibt es einige Angebote deutscher Anbieter, die sehr günstig sind. Auch CDNs mit Lastverteilung gibt es von rein europäischen Anbietern. Wer eine superschnelle Webseite braucht (und sich auch darauf beruft), dem wird es zuzumuten sein, wenige Euro pro Monat für ein Web Hosting Angebot auszugeben, um die heiß geliebten Google Schriften schneller laden zu können.
Servus,
Du hast geschrieben:
>> Die Begründung für den Einsatz solcher Systeme (CDNs) ist oft eine vermeintlich schnellere Ladezeit der Webseite. Bisher konnte mir das allerdings niemand wirklich belegen (ich will nicht ausschließen, dass dies so ist, möchte aber einen Beweis haben!).
Die CDNs ansich sind natürlich darauf ausgelegt statische Dateien schnell und effizient zu verteilen. Diese Optimierungen können aber höchsten ein paar Millisekunden ausmachen. Dies ist also nicht der Grund.
Beispiel:
Eine Website example.com mit Bootsrap, Fonts und mehreren JS-Frameworks von insgesamt ~10 MB wird von einem Webseitenbesucher das allererste mal besucht. Der Browser lädt und cache't alle Ressourcen und die nächsten Ladevorgänge gehen schneller, da die 10 MB bereits beim erstmal
Der Punkt ist "die nächsten Ladevorgänge", denn der erste dauert immer noch ~5 Sekunden auf dem Smartphone ist immer noch (relativ gesehen) extrem langsam. (Ihr kennt euch selbst am besten, aber wenn bei mir eine Website nach 3 Sek. nicht geladen ist, nehm' ich das nächste Google-Suchergebnis 😉 )
Durch die Benutzung von CDNs werden externe Ressourcen (Bootsrap, Fonts, JS Frameworks, …) sogar webseitenübergreifend nur einmal geladen, was zur Folge hat, dass der erste Webseitenbesuch eventuell nur noch 1 Sekunde dauert, da der Webseitenbesucher beispielsweise Bootstrap und die Fonts (~6 MB) bereits vorher vom gleichen CDN für eine ganz andere Website geladen hat.
Ja, das stimmt und ist mir mittlerweile auch bekannt (ich werde den Beitrag ergänzen).
Allerdings ist der Effekt für die meisten Webseiten bei Schriften kaum spürbar, siehe meine Webseite, die laut PageSpeed Insights schnell genug ist (wenn ich wollte, könnte ich das noch steigern, ohne CDNs). Die meisten Webseiten müssen nicht superschnell sein, vor allem, wenn dies nur unter Missachtung von Datenschutzgesetzen möglich ist.
Außerdme betrifft es "nur" Erstaufrufe von Webseiten, die dieselben Dateien wie andere Webseiten nutzen. Wer einen lokalen Browser-Cache hat (am besten von erstmals datenschutzkonform geladenen Fonts), für den ist der Aufruf schneller als wenn die Webseite ein CDN nutzen muss. Wer seinen Browser Cache aus Datenschutzgründen regelmäßig leert, möchte vielleicht eher nicht von einem amerikanischen CDN getrackt werden.
Zudem sind viele Webseiten an anderer Stelle nicht optimiert. Man kann nicht sagen: Die Fonts müssen schnell laden, wenn dann nicht mal Bilder optimiert wurden.
Ich finde Ihre Webseite sehr gut. Danke dafür. Allerdings sollten Sie auch an diejenigen denken, die nicht das Geld haben, einen professionellen WebDesigner zu engagieren. Ich mache alles alleine und kann mir keinen Profi leisten. Wünschenswerte wäre hier und da aus Sicht eines Laien nicht nur zu argumentieren, sondern auch Hilfestellungen anzubieten und wenn das bedeutet, lediglich auf eine andere Webseite zu verweisen, die mit entsprechenden einfachen Anleitungen daherkommt. Speziell das Einbinden der Fonds fällt mir schwer. Obwohl Sie argumentieren, dass alles so leicht wäre. Das ist relativ.
Die DSGVO ist so ziemlich das gruseligste was ich kenne und damit alles drumherum, was man den Webseitenbetreibern zumuten kann. Für mich steht das alles unter der Rubik "Deutschland schafft sich ab Basics", auch wenn ich natürlich einsehe, dass Datenschutz wichtig ist. Unnötig zu diskutieren, aber wir in Deutschland sind immer päpstlicher als der Papst. Ich kenne kein Land, in dem der Datenschutz so ausgelegt wird wie bei uns. Spätestens seit der Pandemie erkennen wir doch, wohin uns der Datenschutz führt. Außerdem: Google und Co. machen sowieso was sie wollen – und sie können das.
Beste Grüße und weiterhin viel Erfolg mit Ihrer Webseite
Vielen Dank für Ihre Rückmeldung, in der Sie zurecht das Problem ansprechen, dass die technische Umsetzung für viele nicht einfach ist. Auch mir fällt es schwer, Dinge unter Einhaltung aller Vorschriften zu tun, die nicht in meinem Fachgebiet liegen.
Es gibt leider keine ganz einfache Lösung zum Einbinden von lokalen Schriften. An sich ist es recht einfach, Schriften lokal einzubinden. Aber es gibt Sonderfälle, etwa, wenn eine Schrift von einem Plugin (externes Tool wie Google Maps) geladen wird. Auch kommt es auf das Webseiten-System an: WordPress, Typo3 oder doch einfach nur selber erstellte HTML-Dateien?
Ich nehme Ihren Kommentar zum Anlass, einen Artikel zu schreiben, wie Google Schriften lokal eingebunden werden können. Dabei werde ich auf mehrere Fälle eingehen, die nicht alle im Detail beschrieben werden können.
Hallo Herr Meffert,
man kann die Auslegung der DSGVO in Deutschland begrüßen oder nicht. Ich gehöre zu letzteren. Ihre Ausführung sind jedoch alle korrekt bis auf eine "Kleinigkeit": Die SIL OFL Licence erlaubt es nicht, den ttf-Font, den man bei Google herunterladen kann, einfach in ein Webkit (WOFF, WOFF2 etc.) umzuwandeln. Man muss der Datei zwingend einen neuen Namen geben. Das macht aber der genannte Google-Font-Helper nicht.
Bei Fontsquirrel wird man dagegen darüber informiert, ob eine Schrift problemlos in ein Webfont-Kit umgewandelt werden kann. Das kann z.B. mit einer Schrift wie der "Oswald" nicht. Dann bekommt man dies zu lesen:
"The license for this font is the SIL OFL license. This license does not allow us to redistribute derivative versions of the font without wholesale name changes inside and out of the font. Until we figure out a reasonable method of delivering these to you and complying with the license, you will have to use the Webfont Generator yourself on these, renaming the fonts appropriately."
Wäre schön, wenn Sie das in Ihrem Beitrag auch noch erwähnten.
Vielen Dank
Vielen Dank Frau Hermanns für Ihren wertvollen Hinweis. Ich habe es kurz geprüft.
Wahrscheinlich ist mit "redistribute" m.E. etwas anderes gemeint als das lokale Einbinden auf einer eigenen Webseite. Denn das ist für mich nicht ein Distribuieren (also verteilen), sondern ein bloßes Nutzen.
Ich habe Ihren Hinweis im Beitrag gewürdigt.
Das die schnellere Auslieferung durch einen CDN "nicht belegt" sei ist ist wirklich unsinn und entstammt wohl einfach der unkenntnis was denn eigentlich besonders an einem gutem CDN ist. Nicht wie in Ihrem Beitrag geschreiben ein einzelner Server mit schnellem Download. Das ist schlichtweg falsch.
Und das kann man wirklich kurz zusammenfassen. Ein CDN ist kein Downloadserver, sondern ein per BGP routenoptimierter mirror. Das Stichwort ist anycast. Heißt, welches Datenzenter auch immer das nächstgelegene ist wird den Content ausliefern. Im Zuge dessen ist also automatisch klar, ein CDN optimiert immer die Ladezeit, da wir über die weltweite auslieferung der Website und nicht eine lokal begrenzte sprechen. Während sich für Ihre website zum Beispiel wohl kaum jemand in den USA interessiert, ist das aber für viele Unternehmen nicht der fall.
Übrigens, google fonts ist auch via anycast ausgeliefert. Die Folgerung des LG München ist insoweit technisch falsch. Die IP wurde nie, zumindest nicht direkt, an einen Server in den USA geschickt. Sondern an einen Server in der EU. Das von dort dann fröhlich munter auch weiter an die USA gesendet werden kann ist natürlich ein separates Problem.
Fakt ist, CDNs sind wichtig. Punkt. Und wir sollten uns nicht zurück in die Steinzeit versetzen lassen aufgrund von mikro Daten wie IPs mit Zeitstempel. Was ich damit sagen möchte: CDNs müssen erlaubt sein. Seiten wie fonts.google.com für die auslieferung zu verbieten (weil google damit nachweislich sämtliche aktivitäten eines Users agregieren kann) ist hingegen legitim. Jedoch kann nicht die Lösung sein den Content statisch von einem ollem Server in der EU auszuliefern wenn die Zielgruppe global ist, sondern entsprechend einen anderen CDN zu wählen.
Die ganze Geschichte ist EXTREM problematisch. Denn würde die USA nun auch auf die tolle Idee kommen eine DSGVO auszurollen, dann hätten wir eine deadlock Situation. Die USA würde die EU blockieren, die EU die USA. Dann wäre es defakto unmöglich weiterhin anycast optimierte Routen überhaupt einzusetzen außer entsprechende ausnahmen die diese technischen besonderheiten klären sind gegeben.
Danke für Ihre Rückmeldung!
Meine Tests mit meiner eigenen Webseite jedenfalls zeigten das, was ich beschrieben hatte.
CDNs mögen einen kleinen Geschwindigkeitsvorteil bei Schriftartdateien bringen, mehr aber nicht. Daran ändert auch ein paralleler Abruf von Dateien von mehreren CDN-Servern gleichzeitig nichts. Übrigens wird ja zunächst (meist) die CSS-Datei für die Schriften geladen, welche erst definiert, welche weiteren Dateien zu laden sind. Diese Datei muss alleinig geladen werden. Sie haben aber Recht, dass ich den Punkt des Parallelabrufs zu wenig gewürdigt habe. Ich ergänze den Artikel entsprechend.
Natürlich dürfen Sie CDNs einsetzen, aber eben nicht die von Unternehmen, die Datenschutzgesetze nicht einhalten. Sie haben dann sicher einen Vertrag mit dem CDN-Anbieter, der die Einhaltung der DSGVO vollumfänglich garantiert.
Ansonsten wäre nämlich auch § 9 TTDSG nicht eingehalten (Schutz von Verkehrsdaten).
Oder Sie machen es sich ganz einfach und binden, so wie ich, Schriften einfach lokal ein. Das geht super und ist schnell.
Die USA kann gerne eine "DSGVO" einführen, dann müsste sie aber Cloud Act, EO 12333 und FISA 702 fallen lassen. Europa könnte sich mühelos an die USA-DSGVO halten. Es gäbe kein Deadlock.
Leider habe Sie meinen Kommentar nicht verstanden. **ANYCAST** ist das Stichwort (hier von Cloudflare eine Erklärung dazu https://www.cloudflare.com/en-in/learning/cdn/glossary/anycast-network/). Es geht nicht um parallelität, die kann man auch selbst ohne CDN erreichen. Es geht darum das CDNs die Latenz zu verringern, in dem immer der **NÄCHSTGELEGENE** Server gewählt wird. Weswegen wie erwähnt, das Urteil des LG Münchens eigentlich fachlich falsch ist, denn dort wurde gerügt das die Daten an einen USA Server gehen. Das ist jedoch insoweit falsch, das der Server defakto in der EU liegt und nicht in den USA. Anycast sei dank. Ohne Anycast geht der Traffic immer zum selben Server (unicast).
Und CDNs werden für alle Dateien eingesetzt, von Bildern, zu CSS und JS Dateien. Nicht nur Fonts und da macht es schon einen gewaltigen Unterschied. Insbesondere wenn man eben auch Kunden in den USA hat als deutsches Unternehmen. Oder auch in Indien oder sonstwo. Denn die Latenz ist sehr sehr hoch über die Strecke. Der Grund ist auch sehr simpel. Die Geschwindigkeit des Lichtes. Alle ~200KM Strecke kommt mindestens 1ms Latenz je Richtung hinzu. In der Realität sogar weit mehr.
Es macht in der Praxis kaum einen Unterschied, ob ein Server vor Ort oder von anderswo im Spiel ist. Siehe meinen Beitrag, wo der Geschwindigkeitsunterschied minimal ist.
Die allermeisten Webseiten haben keine 50.000 Besucher pro Tag.
Bei Serverausfall, DNS-Ausfall, starker Auslastung o.ä. ist zudem nicht garantiert, dass der Server in Deutschland gezogen wird. Google Fonts bieten nicht die Möglichkeit, einen Serverstandort auszuwählen. Woher wollen Sie wissen, welche Server Google einschaltet?
Wegen des Privacy Shield Urteils (Schrems II): Wenn die amerikanische Muttergesellschaft Zugriff auf die Daten haben kann (egal, wo diese gehalten werden), haben wir ein Problem!
Zudem gilt, was ich bereits im Artikel schrieb: Wer behauptet, er brauche Google Fonts vom Google-Server wegen 100 Millisekunden Speedup, der sollte besser seine gesamte Webseite inkl. Mediendateien vorher maximal optimiert haben. Das ist so gut wie nie der Fall, behaupte ich aus Erfahrung.
Wer lokal Dateien lädt, kann das asynchron tun. Der Serverstandort ist erwiesenermaßen Deutschland.
Meine Webseite verzeichnet jeden Monat viele tausend Klicks über die Google-Suche (wie Google mir in Meilenstein-Mails meldet), obwohl ich Schriften und Hilfsbibliotheken lokal einbinde.
Nehmen Sie doch ein CDN, aber eines, das die DSGVO-Einhaltung garantiert. Google garantiert das nicht. Google ist zudem ein Konzern mit amerikanischer Muttergesellschaft.
Das ist vollkommen falsch. Wenn man keine Ahnung hat… .
9000km distanz bedeuten mindestens ~100ms Latenz, plus erhöhter Paketverlust auf diesen Distanzen, also realistisch sogar bis zu 1 Sekunde Latenz.
Und Sie haben es immer noch nicht verstanden….
> Bei Serverausfall, DNS-Ausfall, starker Auslastung o.ä. ist zudem nicht garantiert, dass der Server in Deutschland gezogen wird.
ANYCAST!
Anycast ist **NICHT** DNS basiert! Setzen Sie sich mit dem Thema bitte auseinander und lassen nicht Ihr halbwissen hier gelten. Welchen Server man ansteuert kann man entsprechend prüfen wenn man im Peering hängt und die aktuellen BGP Routen prüft. Cloudflare hatte dazu sogar mal einen öffentlichen Monitor. Die Transparenz an dieser Stelle wo der Traffic hingeht ist durchaus möglich. Wenn google aufhören würde Traceroutes komplett zu verschleiern wäre das sogar noch einfacher möglich.
Das Problem ist außerdem das es kein verünftiges Europäisches Unternehmen gibt, das solche Services anbietet. Wenn die EU etwas tun möchte, wäre doch der erste Schritt selber kostenlos CDN Infrastruktur MIT ANYCAST für den weltweit optimierten Betrieb für common resources zur Verfügung zu stellen. Damit wären unglaublich viele Probleme auf einmal gelöst.
Vorab: Wir reden hier von statischen Schriftartdateien.
Anycast: Danke für Ihren Hinweis. Er ist sicher interessant, aber hier überhaupt nicht wichtig. Siehe folgend sowie: Wenn auf jedem Kontinent ein Server steht, wird der nächste Kontinent gezogen, wenn der EU-Server ausfällt.
Vielen CDN bieten keine dedizierten Serversandorte an, und wenn, dann nur gegen erheblichen Aufpreis. So jedenfalls steht es auf den Webseiten einiger CDN-Anbieter.
Ob es ein EU-Unternehmen gibt oder nicht, welches Ihren Anforderungen genügt, spielt keine Rolle.
Wenn Sie keinen Parkplatz finden, parken Sie dann vor der Feuerwehrzufahrt?
Haben Sie schon mal BunnyCDN probiert?
Die meisten Webseiten aus Deutschland sind ganz vorwiegend auf Besucher aus Deutschland ausgerichtet. Für die prozentual ganz wenigen findet sich eine Lösung. Wir reden hier von simplen statischen Dateien für Schriften.
Zudem: Die allermeisten Webseiten benötigen offensichtlich kein superschnelles CDN mit garantierten Serverstandorten nahe des Nutzers. Man sollte die Kirche mal im Dorf lassen.
Die Webseiten, die behaupteterweise ein solches CDN benötigen, kann man wie folgt angreifen: Angeblich Speedup nötig bei Schriften, aber Bilder nicht verlustfrei komprimiert und Layout- & Script-Dateien mit überflüssigen Codes ausliefern. Manchmal spart es auch Ladezeit, wenn man einfach überflüssige Tracker oder nervige Werbe-Widgets weglässt.
Meine Webseite kommt komischerweise ohne CDN aus.
@Thorsten Formann Endlich mal jemand der von der Sache Ahnung hat. @Dr-Dsgvo sie haben in Informatik promoviert und sind Sachverständiger vor Gericht?? Bei diesem Unwissen??
Ob fonts durch (google) CDN oder lokal schneller oder langsamer sind, ist *völlig* irrelevant. Relevant ist ob Daten entgegen der DSGVO in ein Drittstaat abfließen. Herr Formann hat richtig dargelegt, dass dies nicht der Fall ist. Google unterhält in Europa mehrere Rechenzentren. Sollte eines (komplett) ausfallen, kommen die Daten immer noch aus der EU an den Kunden in der EU.
Ob Daten illegal von google EU an google US weitergeleitet werden, können Sie und ich nicht beurteilen. Da in google EU überwiegend Europäer Arbeiten und google eine vorzügliche Rechtsabteilung besitzt, ist davon auszugehen, dass google EU sich an die DSGVO hält. Anderenfalls würde ich auf einen Wistleblower und die EU-Whistleblower-Richtlinie warten….
Technisch empfehle ich "ping fonts.google.com" von ihrem Heimcomputer aufzurufen. Sollten Sie eine ping Zeit von unter 40ms erhalten, hätten Sie Einstein's Relativitätstheorie gebrochen, würde ihnen google aus den USA geantwortet haben. Erfahrungsgemäß benötigen Daten aus den USA mehr als 80ms – 40ms entspräche der Bestzeit der Luftlinie von Ihnen in die USA ohne zwischengeschalteter Router.
Weiterhin lege ich ihnen nahe, folgende Passagen zu ändern, da man Sie sonst abmahnen könnte.
1) Amerikanische Unternehmen scheiden demnach als Anbieter von CDN aus, außer, man möchte mit Einwilligungen arbeiten und eine gewisse rechtliche Unsicherheit in Kauf nehmen.
2) Wer möchte, kann ja ein datenschutzkonformes CDN verwenden, aber nicht das von Google!
Grund: Google ist ein amerikanisches Unternehmen das datenschutzkonform in der EU operiert. Sie haben das Gegenteil bisher nicht bewiesen und ihre Warnungen können als Eingriff in das Recht am eingerichteten und ausgeübten Gewerbebetrieb angesehen werden.
PS. Sie schrieben: "Siehe folgend sowie: Wenn auf jedem Kontinent ein Server steht, wird der nächste Kontinent gezogen, wenn der EU-Server ausfällt."
Der Bürger muss den Datenschutzverstoß beweisen, nicht google EU, dass die Daten datenschutzkonform aus der EU ausgeliefert wurden. Es würde mich nicht wundern, würde google eine 100% uptime für die EU-Zone ausweisen!! D.h. sie beklagen einen theoretischen Datenschutzverstoß, der aller Wahrscheinlichkeit noch nie eingetreten ist und von google aktiv unterbunden wird und dank redundanter EU Rechenzentren auch nicht zu erwarten ist.
PPS. Eine viel interessantere Frage ist, was passiert, wenn man mittels VPN die EU verläßt, oder außerhalb der EU lebend, mit VPN als EU Bürger surft! Die DSGVO ist and den Wohnsitz, nicht die IP gebunden. Und wenn man die EU mittels VPN verläßt, was ist dann von den Datenstaubsaugern der NSA, GCHQ, etc. DSGVO-technisch zu halten????
———————
Antwort hier im Beitrag, da die maximale Kommentartiefe erreicht ist:
Wo Server stehen, ist zweitrangig. Enscheidend ist, wer Zugriff auf die Server hat. Wenn ein amerikanischer Mutterkonzern eine weisungsgebundene Tochter in Irland hat, dann kann die amerikanische Mutter auf jeden beliebigen Server zugreifen, den die Tochter für die Mutter in der EU unterhält.
Somit ist Ihr Ping-Beispiel irrelevant.
Wenn allerdings Server direkt in den USA stehen, ist ein Zugriff aus den USA allerdings generell anzunehmen.
Zur Beweislast: Die DSGVO legt den Verantwortlichen den Beweis auf (Beweislastumkehr). Nicht der Betroffene, sondern der Verantwortliche muss beweisen, dass alles korrekt abläuft.
Hallo,
ich würde com CC Cleaner absehen, das dieses Programm Daten absaugt!
OK, danke für den Hinweis. Ich habe die Erwähnung geändert in Bleachbit. Das Tool ist Open Source. Sicher findet jeder Interessierte auch andere Tools nach eigenem Geschmack oder nutzt die Browser-Einstellungen zum Verwalten/Bereinigen von Cookies.
Ein Punkt in Ihrem hervorragenden Artikel löst bei mir juristischen Laien eine Beunruhigung aus: darf ich denn überhaupt noch ein YouTube-Video hochladen und öffentlich den Link referenzieren, wenn doch damit recht detaillierte Statistiken über Nutzeraufrufe etc. erstellt und vermutlich nach USA gesendet werden … ist ein publiziertes YouTube-Video also von vornherein DSGVO-konträr ? Man kann bei einem YouTube-Link zum Video ja keine Zustimmungserklärung voranstellen.
Die Frage ist berechtigt. Externe Links können durch Kennzeichnung entschärft werden. Sie finden diese Kennzeichnung auch im Blog Dr. DSGVO.
Ich habe hier mal einen Artikel dazu geschrieben: https://dr-dsgvo.de/externe-links-auf-webseiten-was-ist-zu-beachten/
Ich finde es komisch, dass Unternehmen sich beschweren und dabei aber oftmals Google Analytics ohne Einwilligung verwenden. Die Hälfte der Cookie-Banner funktioniert auch nur pseudomäßig.
Ich habe meine Seiten alle mit einem Google Font Checker geprüft und dann richtig eingebunden. Problem gelöst!
[Anmerkung der Redaktion: Der Website Check auf https://dr-dsgvo.de/website-check kann noch mehr als ein Google Fonts Checker[
Danke für den Beitrag, weiter so 😀