WordPress und Datenschutz: Google Fonts selbst hosten

Ich hatte ja schon geschrieben, dass ich die DSGVO zum Anlass genommen hatte, mal zu schauen, wie ich es komplett vermeiden kann, Daten meiner Nutzer an Dritte zu geben. Bei manchen Dingen ist es einfacher, bei anderne schwerer. Da andere ja derzeit auch auf der Suche nach entsprechenden Lösungen sind, werde ich hier so nach und nach mal die Lösungen beschreiben, die ich hier für mich gefunden habe.

Wichtig: Hier geht es rein um eine technische Beschreibung, ich habe keine Ahnung, ob es wirklich nötig ist, die Google Fonts auf den eigenen Server zu kopieren, um im Sinne der DSVGO abmahnsicher zu sein und da ich kein Jurist bin, ist es auch nicht mein Job, das zu beurteilen. Ich werde hier auch nicht jedes technische Detail erklären und auch keine stupide Copy’n’Paste-Anleitung rein kopieren. Wer Fragen hat, der darf sie gerne in den Kommentaren stellen und wer bessere Ideen hat, der darf sie dort natürlich auch gerne veröffentlichen oder darauf hinweisen.

Das Problem

Google Webfonts sind eine äußerst praktische Sache: Man kann sich hier schnell eine Sammlung von Schriften zusammen klicken, die man in der eigenen Website verwenden will und erhält ein Stück Code und fertig. Die Fonts werden von den üblicherweise rasend schnellen Servern von Google ausgeliefert und man tut so auch gleich etwas für die Geschwindigkeit der eigenen Site und entlastet den eigenen Server. Kostenlos ist das auch noch. Und die Besucher der Sites profitieren ebenfalls davon, da sie einen beliebten Font (ich würde mal sagen, dass Open Sans zum beispiel so einer ist) nur einmal laden müssen und dann im Cache des Browsers mit sich herumtragen.

Das ist so ungemein praktisch, dass inzwischen kaum noch ein WordPress-Theme ohne Google Webfonts oder gleich eine ganze Auswahl dieser auskommt. Praktische Lösungen, die fast zu gut klingen, um wahr zu sein, haben aber oft einen Haken, in diesem Fall ist der Haken Google. Denn jedes Mal, wenn ich eine Website aufrufe, auf der einer dieser Google Fonts eingebunden ist, dann schickt mein Browser eine Anfrage zu Google und Google erfährt so mindestens meine IP und die Informationen, die mein Browser so teilt. Das mag nicht viel sein, Google speichert diese Informationen vielleicht auch nicht oder nur schwer anonymisiert, aber eine IP-Adresse wird trotzdem von vielen Gerichten als persönliches Datum gesehen und ich habe ehrlich gesagt keine Lust, keine Zeit und nicht zu viel Geld, mich abmahnen zu lassen wegen so einem doofen Webfont, selbst wenn ich irgendwann von einem Gericht Recht bekommen sollte.

Das Ziel

Im Idealfall sollten also keine Requests meiner Sitebesucher mehr an Google geschickt werden, aber die Webfonts trotzdem weiter hier verwendet werden. Im Notfall würde mir auch Erreichung des ersten Ziels reichen.

Lösung 1: Keine Webfonts mehr

Die schnellste Lösung, die gleichzeitg der Performance der Site so richtig gut tut: Einfach keine Webfonts mehr verwenden. Man kann im CSS für eine Schriftart mehrere Alternativen angeben, die einfach der Reihe nach durchgegangen werden vom Browser und der erste Font, der lokal vorhanden ist, wird dann auch verwendet. Will ich also die Open Sans verwenden, dann nehme ich für die font-family eben folgenden Inhalt:

font-family: 'Open Sans', Helvetica, Arial, sans-serif;

Hat der Nutzer nun die Open Sans in seinem System installiert – man kann Google Webfonts ja auch legal herunterladen und lokal auf dem eigenen Rechner installieren – ansonsten eine der darauf folgenden Alternativen: Helvetica, wenn die nicht da ist die Arial und wenn die auch nicht da sein sollte, dann eben einen serifenlose Schrift.

Vorteil ist ganz klar, dass es nicht schneller geht, da keine zusätzlichen Dateien übertragen werden müssen. Der Nachteil ist natürlich, dass man nicht weiß, wer welche Schriften installiert hat und eine Site dann eben auf verschiedenen Systemen sehr unterschiedlich aussehen kann. Ähnlich zwar, aber doch deutlich unterschiedlich.

Lösung 2: Webfonts auf den eigenen Server

Wenn man die Google Webfonts auf den eigenen Rechner installieren darf, dann doch wohl auch auf den eigenen Server? Und ja, soweit ich (und nicht nur ich) das sehe scheint das für die Webfonts von Google auch zuzutreffen. Es gibt verschiedene Anleitungen und Tools im Netz, mit denen man das manuell machen kann. Allen gemeinsam ist aber, dass sie recht aufwändig sind. Und viele Anleitungen beschränken sich dabei auf die TrueType-Versionen der Schriften. TrueType-Fonts sind aber für Desktops gemacht und nicht auf die Übertragung im Web optimiert.

Es geht aber auch einfacher und mit echten Webfonts: google-font-download ist ein bash-Skript, dass den Teil mit dem Download erleichtert und alle Varianten holt, die man gerne hätte und das passende CSS erstellt, um diese einzubinden. Mit

./google-font-download "Open Sans:700" "Open Sans:700i" "Open Sans:600" "Open Sans:600i" "Open Sans:400" "Open Sans:400i"

habe ich alle für dieses Theme benötigten Schriften geholt und hatte im Verzeichnis dann neben den Font-Dateien auch den passenden CSS-Schnipsel.

Bleibt nur die Frage: Wie bekomme ich sie in mein Theme? Ist es ein komplett eigenes Theme, dann ist es kein Problem, aber die meisten dürften fertige Themes – zumindest als Grundlage – verwenden. In diesem Fall ist das Mittel der Wahl ein Child Theme. Kurz: ein Child Theme ist ein abgespecktes Theme, mit dem man Änderungen am eigentlichen Theme (dem Elter/Parent) vornehmen kann, ohne dort Dateien anzufassen. So überleben die Änderungen auch Updates. Mehr dazu gibt es im WordPress Codex.

In meinem Fall war das einfach, ich habe mir Child Themes schon vor einer Weile angewöhnt, damit kann man sich auch das eine oder andere PlugIn ersparen. Also habe ich geschaut, wie das Parent Theme die Google Webfonst einbindet und die entsprechende Funktion steht – wo sie gehört – in der functions.php:

/*-----------------------------------------------------------------------------------*/
/* Include Google Webfonts
/*-----------------------------------------------------------------------------------*/

function load_fonts() {
 wp_register_style('googleFonts', 'https://fonts.googleapis.com/css?family=Open+Sans:400italic,600italic,700italic,400,700,600');
 wp_enqueue_style( 'googleFonts');
 }

add_action('wp_print_styles', 'load_fonts');

Jetzt reicht es aber nicht, diese einfach in der functions.php im Child Theme neu zu schreiben, da spielt PHP nicht mit, man muss eine neue Funktion anlegen und WordPress agen, dass es die aus dem Parent Theme ignorieren soll. Also die im Parent hinzugefügte action entfernen und eine eigene neue definieren, dazu gibt es mehrere Möglichkeiten, ich habe mich für diese entschieden:

function child_remove_parent_functions() {
 remove_action( 'init', 'load_fonts' );
}
add_action( 'wp_loaded', 'child_remove_parent_functions' );

function load_fonts_local() {
 wp_register_style('googleFonts', get_stylesheet_directory_uri().'/fonts/font.css');
 wp_enqueue_style( 'googleFonts');
 }

add_action('wp_print_styles', 'load_fonts_local');

Die von font.css und die Fontdateien müssen dazu noch auf den Webserver in den Unterordner fonts im Child Theme geladen werden und fertig.

Der Vorteil: Es werden für den jeweils verwendeten Browser passende Fonts verwendet und diese kommen vom lokalen Server. Die Site sieht also aus, wie sie soll, Google bekommt keine IP-Adressen meiner Sitebesucher mehr und im Idealfall geht alles auch noch schneller. Es gibt aber auch einen Nachteil: Diese Lösung ist nicht ganz so ausgefuchst, wie die direkte Einbindung von Google. Da Google bei jeder Anfrage prüft, welcher Browser sich da meldet, schickt Google nur die Informationen zu den Fonts, die für den aktuellen Browser ideal sind. Meine Lösung ist da halt die „Ich schicke dir mal alles, such selbst aus“-Variante. Das ginge sicher noch ein Stück optimaler, aber da es hier ja nur um einige wenige Fonts geht, kann ich damit leben.

Update: Da gibt es dieses Plugin…

Ich wurde darauf aufmerksam gemacht, dass der ganze Aufwand mit dem Shell-Skript und dem Child Theme doch gar nicht nötig wäre, es ginge doch auch einfacher, wie es zum Beispiel bei den WP Ninjas beschrieben ist. Kurz zusammegefasst: Statt dem Shell-Skript wird dort der Google Webfonts Helper empfohlen. Hier kann man sich die gewünschten Fonts einfach zusammen klicken und erhält ebenfalls am Ende alle benötigten Dateien und den CSS-Schnipsel. Habe es getestet, funktioniert. Ist also eine wunderbare Alternative zum Skript.

Aber beim zweiten Teil der Empfehlung wage ich deutlich zu widersprechen. Es wird empfohlen die Referenzen zu den Google-Servern per Plugin aus dem Theme zu entfernen. Das Plugin heißt Remove Google Fonts References und macht eben genau das. Das ist aber eine schlechte Idee, selbst wenn das Plugin aktuell wäre und nicht ungetestet mit den drei letzten Major-Releases von WordPress und seit zwei Jahren vom Entwickler unangetastet. Man kann dazu natürlich sagen:

Ja, das Plugin wurde lange Zeit nicht aktualisiert. Da es keine bekannten Probleme oder Sicherheitslücken gibt, ist das absolut kein Problem.

Das halte ich aber für sehr blauäugig. Schließlich bedeutet, dass es keine bekannten Probleme oder Sicherheitslücken gibt nach aller Wahrscheinlichkeit nur, dass sehr wahrscheinlich vorhandene Probleme und Sicherheitslücken bisher nur noch nicht entdeckt wurden. Da aber aller Wahrscheinlichkeit nach jede Sicherheitslücke früher oder später gefunden wird, könnte man sich mit diesem Plugin in die unschöne Situtation bringen, entweder doch wieder die Fonts direkt via Google einzubinden (und sich möglicherweise eine Abmahnung einzufangen) oder eben ein unsicheres Plugin weiter einzusetzen, welches offenbar schon länger nicht mehr gepflegt wird.

Aber selbst wenn es aktuell und aktiv gepflegt wäre, ist dieses Plugin eine schlechte Idee. Dazu muss man sich nur anschauen, wie es arbeitet: Das Plugin nimmt die von WordPress fertig erstellte Seite bevor sie an den Nutzer ausgeliefert wird, geht den Quelltext durch und entfernt dann alle Verweise zu den Google Fonts, die es findet. Man muss kein besonders erfahrener Entwickler sein (man muss nicht mal ein Entwickler sein), um zu erkennen, dass das die Performance der Site sicher nicht verbessert. Außerdem durchsucht das Plugin auch die gefundenen lokalen CSS-Dateien nach solchen Referenzen und entfernt die, was zwar dank Caching nicht bei jedem Seitenaufruf bremst, aber dafür andere Probleme mit sich bringen kann („Warum wird diese Änderung am CSS einfach nicht vom Browser beachtet…?“). Und was ist zum Beispiel, wenn sich die Adressen für die Google Fonts ändern oder andere dazu kommen (aber da sind wir wieder beim Thema aktuelle Pflege durch den Plugin-Entwickler)? Abgesehen davon: So ein Child Theme ist ja auch für andere Änderungen nützlich.

[su_box title=“Mehr zum Thema“ box_color=“#394972″][su_menu name=“Datenschutz“ class=“dobschatcontentmenu“][/su_box]

Beitragsbild von wilhei via Pixabay