Drücke „Enter”, um zum Inhalt zu springen.
Ausprobieren
Online Webseiten-Check
Ergebnis in wenigen Sekunden sehen

Externe Google Schriften auf Webseiten sind faktisch nicht nutzbar

0

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.

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 eine 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:

Datenübertragung aufgrund von Google Schriften

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.

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 Artikel 5 DSGVO. Dort ist das Prinzip der Datenminimierung genannt. Dem entgegen steht ein etwaiges berechtigtes Interesse, welches bestimmte Datenverarbeitungen erlaubt. Das berechtigte Interesse ist in Artikel 6 DSGVO definiert.

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.

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 Artikel 5 Absatz 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äß Artikel 13 DSGVO.

Demgemäß müssen u.a. folgende Informationen zu genutzten Googe 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 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.

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 haben!).

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 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.

Auf keinen Fall sollte man meiner Meinung nach auf Cloudflare zurückgreifen, da dieser Anbieter meiner Recherche nach keinen guten Datenschutz bieten kann.

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 */.

Auszug aus einer typischen Layout-Datei für Google Schriften

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.

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. Aus eigener Erfahrung weiß ich, dass es kein Wartungsproblem gibt.

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.

Übersicht der Entgegnungen

Angebliches ArgumentEntkräftung
Externe Google Schriften sind schneller1. 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
4. 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
Lokale Schriften machen zu viel Arbeit1. 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
Google Schriften dürfen nicht lokal eingebunden werdenWo 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.
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.
Nur externe Google Schriften sind wartungsfreiBevor eine Schriftart aus rein technischen Gründen ausgetauscht werden muss, hat sich die Webseite mehrmals selbst überholt.
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.
Scheinargumente für externe Google Schriften und mögliche Entgegnungen

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: Erlaubt 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 Antwot machte 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.
  • Bade Württemberg: Eine konkrete Antwort gibt es nicht. Weiterhin ist die Haltung der Behörde, dass Datentransfers in die USA nur nicht sanktioniert werden, sofern der Datentransfer aus Sicht der Behörde alternativlos ist

Geschwindigkeitstest: lokale versus externe Google Schriften

Für den Vergleich wurde dieselbe HTML Seite einmal mit externen Google Schriften und einmal mit lokalen Google Schriften getestet. Die externen Google Fonts wurdeb, 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:

Externe Google Schriften: Speed-Messung mit Webpagetest

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:

Ladezeiten von externen Google Fonts in Wasserfall-Darstellung

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:

Ladezeiten-Diagramm mit externen Google Schriften

Hier sind die relevanten Ladezeiten genauer zu sehen:

Aufschlüsselung der Ladezeiten der Anfragen für externe Google Fonts

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:

Lokale Google Schriften: Speed-Meddung mit Webpagetest

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:

Ladezeiten von lokalen Google Fonts in Wasserfall-Darstellung

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 Googlr 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:

Aufschlüsselung der Ladezeiten der Anfragen für lokale Google Fonts

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.

KriteriumExterne Google SchriftenLokale Google Schriften
Ladezeit 1. Abruf114 ms211 ms
Ladezeit 2. Abruf91 ms225 ms
Gegenüberstellung externer und lokal eingebundener Google Schriften

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 Gesamtladezeit1. Abruf2. Abruf
Externe Google Schriften114 / 2432 = 4,7%91 / 2469 = 3,7%
Lokale Google Schriften211 / 2482 = 8,5%217 / 2426 = 8,9%
Anteil an der Gesamtladezeit für externe und lokale Google Schriften [Millisekunden]

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

  1. wenige Milliskeunden beim Erstaufruf der Webseite geschäftskritisch sind,
  2. kein DSGVO-konformes CDN bereitsteht (das ist allerdings immer noch kein Argument),
  3. ein eigenes CDN, auch File Server genannt, nicht möglich ist (das wird schwierig zu zeigen),
  4. wirklich alle anderen Maßnahmen bereits voll ausgeschöpft sind (viel Erfolg!)
  5. beim Abruf externer Schriften kein Datentransfer in unsichere Drittländer stattfindet
  6. 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.

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. Wer eine superschnelle Webseite braucht (und sich auch darauf beruft), dem wid 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.

Bullshit Basics
Dies war ein Beitrag aus der Kategorie Bullshit Basics.
In dieser Kategorie werden weit verbreitete Unwahrheiten oder Falschwissen thematisiert und durch Fakten aufbereitet.
Wer schreibt hier?
Mein Name ist Klaus Meffert. Ich bin promovierter Informatiker und beschäftige mich seit über 30 Jahren professionell und praxisbezogen mit Informationstechnologie. Im Jahr 2017 bin ich zum Datenschutz gekommen. Mir sind juristische Gegebenheiten nicht fremd. Ich versuche, meine Ergebnisse durch Betrachtung von Technik und Recht zu gewinnen. Das scheint mir jedenfalls absolut notwendig, wenn es um digitalen Datenschutz geht. Ich würde mich freuen, wenn Sie meinen Newsletter abonnieren.
Bitte nutzen Sie als Quelle für diesen Artikel oder die Verwendung von Ergebnissen aus diesem Artikel folgende Angabe (leichte Variationen sind erlaubt):
Einen Kurzlink oder eine Bestätigung für Ihre Quellenangabe erhalten Sie kurzfristig auf Anfrage.

Schreiben Sie einen Kommentar

Ihre Mail-Adresse wird nicht veröffentlicht.