Eine Website ohne fremde Schriften, und warum sie trotzdem nicht lud

Wer Google Fonts von Googles Servern lädt, überträgt bei jedem Seitenaufruf die IP-Adresse seiner Besucher in die USA. Das Landgericht München hat dafür 2022 Schadenersatz zugesprochen, seither hosten viele Betriebe ihre Schriften selbst. Das ist richtig, und es ist in einer Stunde erledigt.

Wir haben es für diese Website getan, und die Schriften luden trotzdem nicht. Der Grund war ein Zeichen im Stylesheet.

Der Fehler, den man nicht sieht

Die Schriftdateien lagen lokal. Das Stylesheet verwies auf sie. Der Browser lud sie nicht, und zwar ohne Fehlermeldung, ohne rote Zeile in der Konsole, ohne irgendeinen Hinweis. Die Seite lief in der Systemschrift, und das fällt nur auf, wenn man weiß, wie sie eigentlich aussehen sollte.

Der Verweis lautete url(http://www.beispiel.de/wp-content/fonts/archivo.woff2). Die Seite selbst läuft über https. Browser behandeln eine unverschlüsselte Ressource auf einer verschlüsselten Seite als Mixed Content und laden sie schlicht nicht. Bei Bildern warnen sie noch, bei Schriften und Skripten blockieren sie stillschweigend.

Die Lösung braucht keine Konfiguration

Man kann jetzt anfangen, die Adresse in der Datenbank zu suchen, oder eine Regel schreiben, die http durch https ersetzt. Beides funktioniert und beides bricht wieder, sobald die Domain sich ändert.

Der bessere Weg ist, das Protokoll gar nicht erst zu nennen: url(fonts/archivo.woff2). Ein relativer Pfad erbt Protokoll und Domain von der Datei, in der er steht. Er funktioniert auf der Testinstallation, auf der Produktivseite und nach einem Domainwechsel, ohne dass jemand etwas nachzieht.

Was beim lokalen Hosten sonst noch schiefgeht

Die Zeichenbereiche vergessen. Google liefert für jede Schrift mehrere Dateien, je eine für Latein, erweitertes Latein, Kyrillisch. Wer nur die erste herunterlädt, bekommt eine Seite, auf der jedes Wort mit Umlaut in einer anderen Schrift steht. Die unicode-range-Angaben gehören mit übernommen.

Zu viele Schnitte laden. Eine variable Schriftdatei deckt alle Stärken von 100 bis 900 ab und wiegt weniger als drei feste Schnitte. Für diese Website sind es vier Dateien, zusammen etwa 216 KB, und damit sind zwei Schriftfamilien in allen Stärken abgedeckt.

Der Baukasten lädt weiter nach. Bei WordPress-Baukästen genügt es nicht, die Dateien lokal abzulegen. Elementor etwa hat einen eigenen Schalter für Google Fonts, und solange der steht, lädt er sie zusätzlich.

Wie man es prüft, statt es zu glauben

Ein einziger Befehl reicht: curl -s https://www.beispiel.de/ | grep -i fonts.gstatic. Kommt nichts zurück, geht nichts an Google. Ein Blick in die Einstellungen ersetzt das nicht: Die Einstellung sagt, was gewollt ist, der Quelltext sagt, was passiert.

Was daraus folgt

Datenschutz auf einer Website ist selten eine Frage der Absicht und meistens eine Frage der Prüfung. Die Absicht war hier von Anfang an richtig, die Dateien lagen am richtigen Ort, und trotzdem war das Ergebnis eine Seite ohne ihre Schriften.

Die unbequeme Folgerung: Bei Schriften merkt man den Fehler, weil die Seite anders aussieht. Bei einem Analysewerkzeug oder einer eingebetteten Karte merkt man ihn nicht, und dann läuft der Fremdrequest weiter, den man längst abgestellt zu haben glaubte.