Ich verwende für diese Website die freie Weblog-Software WordPress mit dem aktuellsten der drei vorinstallierten Standard-Themes, genannt Twenty Seventeen. Der Einsatz jedes dieser drei inkludierten Themes hat – wenn man nichts dagegen unternimmt, siehe unten – folgenden Nebeneffekt: sie bringen die Browser der Besucherinnen dazu, der Google Corporation Bescheid zu geben, dass sie sich gerade die Website ansehen.
Wie heute allgemein üblich, setzen diese Themes Web-Fonts ein. Das heißt nichts anderes, als dass die auf der jeweiligen Website eingesetzten Schriftarten beim Aufruf derselben mit heruntergeladen werden und so dafür gesorgt ist, dass das Schriftbild über alle Betriebssysteme und Browser hinweg gleich aussieht. Das ist an sich großartig – problematisch ist nur, dass die Fonts nicht vom jeweils eigenen Server, sondern von Google-Servern geladen werden.
Google is not a charity
Besucht man eine solche Website, dann schickt man damit also automatisch eine Anfrage an Google, dass man für deren korrekte Darstellung bitte gerne diese und jene Schriftart hätte. Wie bei jeder anderen HTTP-Anfrage sendet man dabei unter anderem die eigene IP-Adresse, Informationen über den verwenden Browser und das Betriebssystem (den User Agent) sowie die Adresse der Website, für deren Darstellung man die Schriftart braucht (also die des Referrers), mit. Wenn man mehrere Websites besucht, die das Google Fonts API nutzen – und das sind mittlerweile sehr viele –, dann fallen dabei auf den Google-Servern Daten zum individuellen Surfverhalten an.
Die Website-Betreiber bezahlen Google für die prompte Zurverfügungstellung von Schriftarten also mit Daten über ihre Besucherinnen – Daten, mit denen man alle möglichen spannenden Dinge tun kann. Aber in aller Regel wissen nicht einmal sie etwas davon: viele Leute lassen sich ihre Websites von Erfahreneren erstellen, andere machen es selbst und sind froh über alle Details, über die sie sich nicht den Kopf zerbrechen müssen. Eben deswegen gibt es ja schließlich so etwas wie Standard-Themes. Wie das Ganze funktioniert, interessiert sie nicht – und sollte sie auch nicht interessieren müssen.
Kritisch sehe ich das im Unterschied zu vielen anderen (wie zum Beispiel die Jury der deutschen Big Brother Awards, siehe dazu die diesjährige tadelnde Erwähnung von WordPress) nicht primär aufgrund datenschutzrechtlicher Bedenken. Meines Erachtens ist diese im öffentlichen Diskurs immer wieder – wenn auch nur für kollektive Übungen im Schulterzucken – verhandelte, uns alle individuell betreffende Problematik im Vergleich zur gesamtgesellschaftlichen geradezu vernachlässigbar. Ich bin fest davon überzeugt, dass es grob fahrlässig ist, profitorientierten Organisationen exklusiven Zugriff auf unfassbar wertvolles Datenmaterial über uns zu gewähren – und mit diesem Uns meine ich eben nicht uns als Summe aller Individuen, die jeweils Anspruch auf den Schutz ihrer Privatsphäre haben; ich meine uns als Gesamtheit (kurz das, was man in der Regel als Gesellschaft bezeichnet).
Niemand kann heute im akademischen Kontext für Zwecke der quantitativen Sozialforschung Zugang zu einem auch nur ansatzweise vergleichbar ergiebigen Datenmaterial erhalten wie Google, Facebook und dergleichen. Normalität heißt heute, auf Profit ausgerichteten Organisationen Verfügungsgewalt über bis vor kurzem unvorstellbare Quellen soziologischen Wissens einerseits sowie zentrale gesellschaftliche Mittler andererseits zuzugestehen. Das ist Irrsinn. Es lässt die letzten beiden Jahrhunderte als primitive Frühphase kapitalistischer Vergesellschaftung erscheinen. Aber dazu vielleicht in einem anderen Beitrag einmal mehr…
Zurück zum eigentlichen Thema: In zumindest sehr, sehr vielen Fällen nehmen Website-Betreiberinnen und -Nutzer also ohne einen blassen Schimmer davon zu haben eine Google-Dienstleistung, für die sie auch etwas zahlen, in Anspruch. Die Frage, die sich aufdrängt: Warum integriert das WordPress-Projekt die genutzten Schriftarten nicht einfach in die Standard-Installation und lässt sie beim Aufruf der Website vom jeweils eigenen Server laden? Alle in den Standard-Themes verwendeten Fonts sind frei im Sinne Freier Software – von einem rechtlichen Standpunkt spricht absolut nichts dagegen. Wieso greift man hier also überhaupt auf Google-Dienste zurück?
Über entbehrliche Zeichen, gut gemeinte Hinweise und den ehrfürchtigen Umgang mit Alten und Altgebliebenen
Die kurze Antwort: Der Einsatz von Google Fonts hat damit zu tun, dass man je nach benötigten Zeichen (den Sprachen, in denen Texte auf einer Website verfasst sind) und dem von der jeweiligen Besucherin eingesetzten Browser und Betriebssystem unterschiedlichste Möglichkeiten hat, die Größe der herunterzuladenden Fonts zu reduzieren – und die will man optimal nutzen. Schließlich ist es ja nicht ganz unwesentlich, wie schnell eine Seite geladen wird. Nun könnte man natürlich alle relevanten „Versionen“ der verwendeten Schriftarten inkludieren und in jedem Einzelfall die jeweils passende ausliefern; nur bläht man dann die Standard-Installation in einem wirklich absurden Ausmaß mit Schriftarten auf… Aber schauen wir uns die einzelnen Optimierungsmöglichkeiten einmal genauer an.
Subsets
Fonts sind im Grunde Dateien, die (vor allem) Glyphen, also grafische Darstellungen von Schriftzeichen, enthalten – und zwar oft deutlich mehr, als man in einem bestimmten Sprachraum benötigt; der Font Open Sans umfasst beispielsweise 897 Glyphen mehrerer Alphabete. Es wäre nicht einfach nur unnötig, Browser beim Aufruf einer deutschsprachigen Website zig griechische und kyrillische Glyphen herunterladen zu lassen – es würde auch deutlich länger dauern, die Seite zu laden. Deswegen erstellt man Teilmengen (Subsets) der in einem Font enthaltenen Glyphen. Auch wenn Leute in Frankreich, Russland und Griechenland also dieselbe Schriftart (bleiben wir beim Beispiel Open Sans) auf ihrer Website verwenden; real nutzen sie unterschiedliche – wenn auch sich überschneidende – Subsets dieses Fonts. Im konkreten Fall wären das latin, cyrillic bzw. greek.
Um auf einer einzelnen Website nur die Teilmenge eines Fonts einzusetzen, könnte man bei einem deutschsprachigen Weblog zum Beispiel einfach nur das Subset latin auf den Server laden und im Seiten-Quelltext mit der CSS font-face @-Regel darauf verweisen:
@font-face {
font-family: 'Open Sans';
font-style: normal;
font-weight: 400;
src: local('Open Sans Regular'), local('OpenSans-Regular'),
url('../fonts/open-sans-v14-latin-regular.woff2') format('woff2'),
url('../fonts/open-sans-v14-latin-regular.woff') format('woff');
}Wie man sieht, werden hier (als Werte der Eigenschaft src) vier Quellen angegeben. Wenn der durch Schriftstärke 400 und Schriftlage normal definierte Schriftschnitt der Schriftfamilie Open Sans benötigt wird, dann überprüft der Browser zuerst einmal, ob er auf dem Rechner des Nutzers installiert ist (es werden zwei Bezeichnungen probiert: Open Sans Regular und OpenSans-Regular). Wenn das nicht der Fall ist, wird der Font vom Server geladen – vorzugsweise im Format WOFF2 und wenn der Browser damit nichts anfangen kann, dann im Format WOFF (zu den Formaten siehe den übernächsten Abschnitt). Was in diesem Beispiel am Dateinamen der Fonts am Server erkennbar ist: Wenn der Schriftschnitt vom Server geladen werden muss, liefern wir dem Browser eben nur das Subset latin, das er für die Anzeige der Website braucht.
So einfach ist das bei einer einzelnen Website – weil wir als deren Betreiberin ja wissen, welche Sprache(n) wir nutzen und damit welche Teilmengen der Fonts wir benötigen. Aber was tut man, wenn man wie das WordPress-Projekt Themes entwickelt, die möglichst viele Sprachen unterstützen sollen? Muss man dann nicht erst wieder die Subsets für all diese Sprachen in den Font inkludieren – was bedeuten würde, dass alle Nutzerinnen beim Aufruf der Website alle Subsets herunterladen müssen?
Eben diesem Problem begegnet die CSS unicode-range Eigenschaft. Sagen wir, wir wollen die Schriftart für deutsche und griechische Texte zur Verfügung stellen – dann könnte das so aussehen:
@font-face {
font-family: 'Open Sans';
font-style: normal;
font-weight: 400;
src: local('Open Sans Regular'), local('OpenSans-Regular'),
url('../fonts/open-sans-v14-latin-regular.woff2') format('woff2'),
url('../fonts/open-sans-v14-latin-regular.woff') format('woff');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215;
}
@font-face {
font-family: 'Open Sans';
font-style: normal;
font-weight: 400;
src: local('Open Sans Regular'), local('OpenSans-Regular'),
url('../fonts/open-sans-v14-greek-regular.woff2') format('woff2'),
url('../fonts/open-sans-v14-greek-regular.woff') format('woff');
unicode-range: U+0370-03FF;
}Die beiden Regeln beziehen sich auf denselben Schriftschnitt – sie unterscheiden sich nur in Bezug auf den Unicode-Bereich und die jeweiligen Quellen. Das heißt, wenn der Browser für die korrekte Darstellung eines Textes Glyphen lateinischer Zeichen braucht, greift er auf die in der ersten Regel definierten Quellen zurück, wenn er Glyphen griechischer Zeichen braucht, auf jene aus der zweiten Regel.
Man könnte also die Subsets für alle Sprachen, die man unterstützen will, in die Standard-Installation inkludieren und mit der unicode-range Eigenschaft sicherstellen, dass Browser nur die Dateien laden, die sie für die Darstellung der jeweiligen Website auch wirklich brauchen.
Hints
Alle im gegebenen Zusammenhang relevanten Fonts sind Vektorfonts, das heißt, sie enthalten im Grunde Vektorgrafiken der Glyphen, die für die Darstellung auf Monitoren immer erst gerendert (also in Rastergrafiken umgewandelt) werden müssen. Da das – besonders bei geringen Auflösungen bzw. sehr kleiner Darstellung – zu durchaus hässlichen bis zu unlesbaren Ergebnissen führen kann, enthalten die meisten Fonts Hinweise (Hints) dafür, wie sie gerendert werden sollen.
Richtig gute Hints werden manuell erstellt, was sehr arbeitsaufwändig ist. Viele Fonts enthalten daher nur automatisch erstellte, qualitativ minderwertige Hints – und manche gar keine. Das ist einer mehrerer Gründe, warum Betriebssysteme völlig unterschiedlich mit diesen inkludierten Rendering-Hinweisen umgehen. Soweit ich das nachvollziehen kann, verwenden einige (darunter zumindest die meisten GNU/Linux-Distributionen) inkludierte Hints; nur wenn keine vorhanden sind, übernehmen sie das „Hinting“ (besser gesagt das Rendern ohne Hints) selbst. Andere (darunter macOS) ignorieren offenbar grundsätzlich mitgelieferte Hints.
Zumindest in diesen Fällen könnte man die Hints aus den Fonts entfernen, erhielte kleinere Dateien und trüge so dazu bei, dass die jeweiligen Seiten schneller geladen werden. Dazu müsste man aber abhängig vom User Agent (also in diesem Fall vor allem dem genutzten Betriebssystem) unterschiedliche Fonts – mit bzw. ohne Hints – ausliefern und das ist nicht ganz einfach.
Formate
Die Sache wäre schon kompliziert genug, wenn alle Browser die aktuelle Version 2.0 des Web Open Font Formats (WOFF2) unterstützen würden. Aber nein, es sind sogar noch immer welche in Verwendung, die nicht einmal Version 1.0 dieses Formats (WOFF) unterstützen. Deswegen ist es bis heute – um ja ganz sicher zu gehen dass alle Browser (die dazu grundsätzlich in der Lage sind) die Schriftart wie gewünscht anzeigen – üblich, alle Fonts bzw. deren Subsets in fünf unterschiedlichen Formaten bereit zu stellen (neben WOFF2 und WOFF sind das TTF, SVG und EOT).
Was man heute für Daten alles bekommt…
Auf dieser Grundlage kann ich jetzt anhand des konkreten Beispiels der WordPress Standard-Themes grob skizzieren, was das Google Fonts API leistet.
Alle diese Themes verwenden Schriftarten, bei denen man nicht davon ausgehen kann, dass sie auf den Systemen der Nutzer sowieso installiert sind. Gleichzeitig findet man aber auch nirgends in den Stylesheets font-face Regeln, in denen Quellen für diese Fonts angegeben wären. Stattdessen gibt es für jede benötigte Schriftart einen Stylesheet-Link, also einen Link zu einem externen Stylesheet; als Beispiel hier der einzige aus Twenty-Seventeen (das Theme verwendet nur einen Web-Font):
https://fonts.googleapis.com/css?family=Libre+Franklin:300,300i,400,400i,600,600i,800,800i&subset=latin,latin-extDie Syntax ist leicht verständlich: Wir wollen aus der Schriftfamilie Libre Franklin die Schriftschnitte light (300), light italic (300i), regular (400), regular italic (400i), semi bold (600), semi bold italic (600i), extra bold (800) und extra bold italic (800i). Von den verfügbaren Subsets hätten wir gern latin und latin-ext (das sind in dem Fall übrigens alle, die es von der Schriftart gibt).
Das von Google auf diese Anfrage hin ausgelieferte Stylesheet enthält ausschließlich font-face Regeln. Wie diese aber konkret aussehen – und vor allem auch auf welche Font-Dateien sie auf den Google-Servern verweisen – hängt völlig vom jeweils eingesetzten User Agent ab.
Wenn der Browser problemlos mit der unicode-range Eigenschaft umgehen kann, dann enthält das Stylesheet Regeln für alle verfügbaren Subsets. Man kann sich darauf verlassen, dass der Browser sich jeweils nur die Subsets holt, die er für die Darstellung der jeweiligen Website braucht. Wenn das nicht der Fall ist (und das gilt übrigens auch für einige aktuelle Browser), gibt es pro Schriftschnitt nur eine Regel, die auf eine Font-Datei verweist, die alle im Link angeforderten Subsets enthält.
Wenn das genutzte Betriebssystem Hints verwendet, dann verweisen die Links auf Fonts inkl. Rendering-Hinweisen; wenn nicht, dann eben nicht. Und dann wird natürlich nur das für den jeweiligen Browser am besten geeignete Font-Format geliefert. Mit einem einzigen Stylesheet-Link stellt man also sicher, dass erstens wirklich alle Browser (die dazu grundsätzlich in der Lage sind) eine verwendete Schriftart korrekt anzeigen und dass dafür zweitens so wenig Daten wie gerade notwendig heruntergeladen werden müssen.
Kann WordPress auf Google Fonts verzichten?
Zurück zur oben gestellten Frage: Warum integriert das WordPress-Projekt die genutzten Schriftarten nicht in die Standard-Installation und lässt sie beim Aufruf der Website vom je eigenen Server laden?
Soweit ich es nachvollziehen kann, würde sich diese Frage nicht stellen, wenn alle eingesetzten Browser WOFF2 und die unicode-range Eigenschaft unterstützen würden. Sicher, man müsste vorerst damit leben, dass Hints auch Systemen ausgeliefert werden, die nichts damit anfangen – aber dieser Aspekt ist relativ vernachlässigbar. Die Hauptprobleme bestehen darin, dass erstens nach wie vor alte Browser-Versionen eingesetzt werden, die WOFF2 nicht unterstützen (und teilweise nicht einmal Version 1.0 des Formats, also WOFF) und dass zweitens einige Browser selbst in den aktuellen Versionen nicht in der Lage sind, die unicode-range Eigenschaft vernünftig zu interpretieren (siehe caniuse.com). Vor allem diese Probleme sind es, die man durch den Einsatz eines simplen Stylesheet-Links löst.
Meines Erachtens stellt sich für das WordPress-Projekt in Bezug auf Web-Fonts in der Standard-Installation daher folgende Frage: Legitimiert das Bedürfnis nach einer wunschgemäßen Text-Darstellung auf möglichst allen Browsern es wirklich, Google derart viele Daten zu überlassen? Wenn man nämlich die Subsets der eingesetzten Fonts ausschließlich im WOFF2-Format inkludiert, dann ist einerseits die zusätzliche Datenmenge am Server und andererseits die Größe der herunterzuladenden Fonts durchaus vertretbar.
Nehmen wir wieder das naheliegende Beispiel Libre Franklin (schließlich ist es die Schriftart, in der dieser Text hier verfasst ist). Ich komme bei den 16 WOFF2-Dateien (das sind je zwei Subsets der weiter oben genannten acht Schriftschnitte) auf eine Gesamtdatenmenge von 282,8 Kilobyte.
Um anzuregen, dass das Projekt sich dieser Angelegenheit widmet, hab ich vorerst einfach einmal ein Ticket im Bugtracker von WordPress erstellt: Bundle fonts used by default themes. Mal schauen, vielleicht erfahren wir da bald mehr.
Sie lösen all meine Probleme? Danke, nein.
Am Schluss noch kurz zu der Frage, wie man WordPress derzeit nutzen kann, ohne den fragwürdigen Handel mit Google einzugehen. Das geht in zwei Schritten: zuerst verhindert man die Anfrage an Google und dann sorgt man dafür, dass die Fonts vom eigenen Server geladen werden.
Alle Standard-Themes nutzen Schriftarten, die nur in einigen Sprachen verwendbar sind, Libre Franklin deckt beispielsweise „nur“ alle lateinischen Alphabete ab. Im Falle eines griechischen oder russischen Weblogs wäre es daher völlig abwegig, wenn das Theme das Stylesheet von Google laden würde.
Für solche Fälle gibt es in den Funktionen der Standard-Themes, die die Stylesheet-Links erstellen, eine einfache Möglichkeit für WordPress-Übersetzerinnen, den unnötigen Zugriff auf Google Fonts zu verhindern. Hier als Beispiel die Funktion aus Twenty Seventeen:
function twentyseventeen_fonts_url() {
$fonts_url = '';
/**
* Translators: If there are characters in your language that are not
* supported by Libre Frankin, translate this to 'off'. Do not translate
* into your own language.
*/
$libre_franklin = _x( 'on', 'libre_franklin font: on or off', 'twentyseventeen' );
if ( 'off' !== $libre_franklin ) {
$font_families = array();
$font_families[] = 'Libre Franklin:300,300i,400,400i,600,600i,800,800i';
$query_args = array(
'family' => urlencode( implode( '|', $font_families ) ),
'subset' => urlencode( 'latin,latin-ext' ),
);
$fonts_url = add_query_arg( $query_args, 'https://fonts.googleapis.com/css' );
}
return esc_url_raw( $fonts_url );
}Wenn Übersetzerinnen der Variable libre_franklin den Wert ‚off‘ zuweisen (hier als Beispiel die deutsche „Übersetzung“), gibt die Funktion nichts zurück und es wird kein Stylesheet von Google geladen. Und solche „Schalter“ gibt es in den Standard-Themes für alle nicht inkludierten Web-Fonts.
Eben diesen Umstand macht sich das freie WordPress-Plugin Disable Google Fonts zunutze: es setzt einfach alle derartigen „Font-Schalter“ auf ‚off‘. Wenn man es installiert und aktiviert kann man also sicher sein, dass (Vorsicht: wirklich nur) die Standard-Themes keine Stylesheets und keine Fonts mehr von Google laden.
Wenn man die im Theme verwendeten Schriftarten weiterhin verwenden will, muss man die notwendigen Dateien auf den eigenen Server laden und mit font-face Regeln darauf verweisen. Dafür gibt es ein sehr angenehmes freies Tool, den google webfonts helper. Man wählt einfach die gewünschte Schriftart, deren Subsets und Schriftschnitte sowie die Browser aus, die man unterstützen möchte und erhält sowohl die entsprechenden font-face Regeln als auch ein Archiv mit den Font-Dateien.
Die font-face Regeln kann man zum Beispiel einfach mit dem Appearance Editor in den Stylesheet des eigenen Child-Themes kopieren und dort den eigenen Bedürfnissen anpassen. Mir reicht es beispielsweise, wenn der Text hier nur in jenen Browsern in der Schriftart Libre Franklin angezeigt wird, die das Format WOFF2 unterstützen – ich hab also die Verweise zu allen anderen Formaten gelöscht. Außerdem will ich die Fonts in einem Unterordner meines Child-Themes speichern und habe die relativen Pfadnamen dementsprechend angepasst. Eine Regel sieht dann bei mir also so aus:
@font-face {
font-family: 'Libre Franklin';
font-style: normal;
font-weight: 300;
src: local('Libre Franklin Light'), local('LibreFranklin-Light'),
url('fonts/libre-franklin-v1-latin-300.woff2') format('woff2');
}Danach muss man nur noch die Dateien an den angegebenen Ort kopieren. Testen kann man das ganze zum Beispiel im Firefox mit der Netzwerkanalyse (Tastenkombination Strg+Shift+q): einfach nach dem Öffnen die Seite neu laden und den Cache überschreiben (Tastenkombination Strg+Shift+r) und nachschauen, ob die Fonts geladen wurden.