Führen schon analoge Wege alle nach Rom, so führen sie in der digitalen Welt alle zu Google.
WordPress ist da keine Ausnahme.
Bereits im Jahre 2012 wurden mit Erscheinen der WordPress-Version 3.8 die Wege zum digitalen Rom geebnet. „Open Sans“, die in der Folge immer unvermeidlichere Schriftart, wurde seither von externen Google-Servern in das WordPress-Backend(!) geladen. Auch die Standard-Themes laden seit jener Zeit, bis hin zu allen Versionen der 4.x.x-Reihe, ihre Schriften von Googles US-Servern.
Dieser Entscheidung gingen Privatsphäre-Bedenken im WordPress-Entwicklerforum voraus. Sie wurden ignoriert und konnten sich nicht durchsetzen. Selbst der 3 Jahre später kurz aufflammende Einwand bzgl. der „General Data Protection Regulation“ (DSGVO) blieb unbeachtet. Das führte letztlich zu einem abgewürgten Ende der Diskussion: „Resolution set to wontfix“ liest man auf der Entwicklerseite. – Vorerst, wie sich herausstellte.
WP-Version 4.6 ruderte nämlich überraschend zurück. Mit dieser Version war das WordPress-Backend plötzlich und ziemlich unerwartet wieder google-webfont-frei. Die Begründung dafür war, dass es mittlerweile genug gute Systemschriftarten gäbe, die diesen Schritt rechtfertigen würden.
Die vormaligen Standard-Themes jedoch, von „TwentyTwelve“ bis „TwentySeventeen“, luden und laden die Google-Fonts fleißig weiter, waren also von der kleinen kopernikanischen Wende nicht betroffen.
Sagte ich „Wende“? – Die jüngste WP-Version 5.x führt sang- und klanglos externe Google-Webfonts mit dem Gutenberg-Editor wieder ein. Die „guten nativen System-Fonts“ haben das Gutenberg-Feeling offenbar nicht hinreichend unterstützt.
Der eigentliche Schönheitsfehler bei all dem Hin und Her ist aber: das Einbinden der Webfonts von Google-Servern wurde unter Berufung auf die DSGVO zumindest in Deutschland bereits abgemahnt. Das ist ein gewichtiger, aber nicht der einzige Einwand gegen die bislang übliche Praxis.
Webfonts in herkömmlicher Weise zu laden, so also, wie Google es empfiehlt und wie Tausende von Themes für WordPress es seit Jahren implementieren, verstößt gegen Google’s eigene Web-Performance-Richtlinien der PageSpeed Insights (und zwar völlig zurecht: Webfonts lokal vom Server der Webseitenresidenz zu laden, spart erhebliche 7 Roundtrips gegenüber der externen Ladevariante ein und lädt somit durch wegfallende Netzwerklatenzen deutlich schneller in langsamen Netzen – wenigstens dann, wenn man das lokale Laden richtig implementiert).
Natürlich betrifft das Backend-Laden externer Fonts nicht die normalen (Frontend-)Besucher einer WordPress-Website. Aber Betreiber, die Mitgliederbereiche bereitstellen, oder die ein Blog-Netzwerk anbieten, oder welche Mitarbeiter, Autoren und Redakteure beschäftigen – diese Betreiber müssen vorsichtig sein, denn hier könnte DSGVO-Abmahngefahr drohen.
Vor allem wird der Einsatz von WordPress bei nicht permanenter Anbindung ans Internet (im Rahmen eines Intranet z.B.) zunehmend schwieriger aufgrund der stetig anwachsenden externen Abhängigkeiten, wie eben die von den Webfonts. Daneben bietet der Reigen der externen Vernetzung allein des WordPress-Core ja auch noch Emojis, Gravatare, Update-Abfragen mit Datenweitergabe, durchgereichte Beitrags-Update-Infos via Pingdom, ggf. geladene Script-Bibliotheken etc.
All dies bedenkend ist vom automatischen Laden der Fonts von Google-Servern eher abzuraten.
Vor allem die Performance leidet im ohnehin schon oft als schleppend langsam wahrgenommenen Backend. Sind Webfonts unabdingbar im Frontend, sollten sie lokal, vom eigenen Server geladen werden. Im Backend gehören sie schlicht ausgemerzt.
Du kannst zum Deaktivieren des externen Google-Font-Ladens, je nach verwendetem Standard-Theme, das folgende PHP-Snippet verwenden. Nicht benötigte $styles->add-Zeilen innerhalb der Funktion kannst du löschen; orientiere dich dabei an den Kommentaren am Zeilenende.
Solange das Deaktivieren des externen Ladevorgangs rein theme-bezogen war, gehörte nachfolgender Code eigentlich in die Datei functions.php des betroffenen Child-Themes.
Da aber nun wieder das WP-Backend betroffen ist, und der Code trotz etwaiger Theme-Wechsel erhalten bleiben sollte, empfiehlt sich das Erstellen eines eigenen Mini-Plugins, in welches folgender Code hineinkopiert werden kann:
<?php
/**
* Disable loading of Google Fonts for WordPress' backend & standard themes.
*/
function google_fonts_load_disable( $styles ) {
$styles->add( 'wp-editor-font', '' ); // Backend: WP v5.0+
$styles->add( 'twentyseventeen-fonts', '' );// Theme Twentyseventeen
$styles->add( 'twentysixteen-fonts', '' ); // Theme Twentysixteen
$styles->add( 'twentyfifteen-fonts', '' ); // Theme Twentyfifteen
$styles->add( 'twentyfourteen-lato', '' ); // Theme Twentyfourteen
$styles->add( 'twentythirteen-fonts', '' ); // Theme Twentythirteen
$styles->add( 'twentytwelve-fonts', '' ); // Theme Twentytwelve
$styles->add( 'open-sans', '' ); // old backends: WP v3.8 - v4.5.x
}
add_action( 'wp_default_styles', 'google_fonts_load_disable', 5 );
Was macht der Code nun genau?
Die add()-Methode der WP_Dependencies-Klasse verhindert ein Überschreiben bereits definierter Styles – weswegen der Code oben mit „5“ eine niedrigere Priorität für den add_action()-Hook festlegt als die Standard-Priorität „10“. Unser Methodenaufruf wird somit zuerst ausgeführt. Er definiert für den Font-Namen eine leere Zeichenkette und blockiert weitere Definitionen für denselben Font-Namen. Das Snippet kommt somit den Ladevorgängen der Styles zuvor 🙂
Mini-Plugin, oder functions.php – das ist hier die Frage. Was machst du?
Da diese Sache ohnehin im Blick behalten werden muss (was macht die nächste WP-Version??), mag ja auch die functions.php ausreichen.
Auf mich wirkt das Ganze jedenfalls wie die alte Geschichte mit dem Herzog, der die Herzogin hin- und herzog …
Hallo Frank,
ich schlage mich gerade mit dem Twenty Sixteen Template rum und will da die Googlefonts deaktivieren. Da ich noch neu in der Materie bin, hab ich folgende Frage:
Reicht es aus den Code in die functions.php des child-themes zu kopieren?
Beste Grüße,
Jojo
Ja, das reicht aus.