Warum ein Theme keine Google Fonts verwenden sollte
Veröffentlicht: – 19 Kommentare Letzte Aktualisierung:
Als Webfonts über @font-face neu waren, wusste Google genau, wie man einen Dienst anbieten kann, der scheinbar für alle nur Vorzüge hatte. Mittlerweile jedoch hat sich hier einiges getan und immer mehr kommen die Schattenseiten des Dienstes „Google Fonts“ zum Vorschein.
Im nachfolgenden Beitrag möchte ich einmal kurz beschrieben ein paar Gründe nennen, warum man keine Google Fonts nutzen sollte, egal ob bei der Erstellung eines eigenen Themes/Plugins oder auch auf eigenen oder fremden Websites.
Performance
Google hat schnelle Server, keine Frage. Dennoch ist die Performance immer mehr eine tragende Rolle, wenn es um gute Websites geht. Bindet man Google Fonts ein, hat man hier erst einmal zwei Möglichkeiten.
link-Element
Über ein link-Element kann die Google Font direkt im head-Bereich der Website angegeben werden. Hierbei wird eine eigene CSS-Datei geladen, welche ihrerseits die Anweisungen für jede einzelne Schriftart im eingebundenen Schriftschnitt bereitstellt. Die eigentliche Schrift selbst muss separat zusätzlich geladen werden.
Über @import
Als alternative Möglichkeit kann man die Datei über den CSS-Befehl @import einbinden. Hierbei wird ebenfalls eine eigene CSS-Datei mit eigenen Anweisungen geladen und auch hier muss die eigentliche Schrift separat geladen werden.
Was ist so schlimm daran?
Es gibt bei beiden Methoden mehrere Probleme. Da @import in CSS sowieso niemals genutzt werden sollte, da es die Verarbeitung des nachfolgenden CSS aufhält, bis die Datei, die in @import deklariert ist, geladen wurde, ist das ein absolutes Performance-Desaster.
Darüber hinaus lädt man mindestens eine komplette CSS-Datei mehr, nämlich die von Google. Diese liegt auf einem separaten Server, für den der Browser erst die DNS-Einträge auflösen muss, um überhaupt zu wissen, wohin er die Anfrage richten muss.
Da die Anfrage – glücklicherweise – verschlüsselt ist, kommt zu der DNS-Abfrage auch noch ein sogenannter „SSL-Handshake“ hinzu. Der eigene Browser kommuniziert also erst einmal mit dem Server, um die bestmögliche Verschlüsselung auszuhandeln. Erst danach werden überhaupt weitere Daten übertragen.
Außerdem ist das Caching sehr schlecht eingestellt. Genauer gesagt liegt es bei einer Stunde. Das heißt, dass ein weiterer Seitenaufruf eine Stunde später dazu führt, dass der Browser die Schrift von Google erneut herunterladen muss. Empfehlenswert sind hier eher Werte von mindestens einer Woche, denn wie oft ändern sich schon Schriften?
Kontrolle
Bei Schriften von externen Quellen musst du davon ausgehen, dass einerseits genau die Schrift geladen wird, die du möchtest, andererseits aber auch darauf vertrauen, dass sie immer erreichbar ist. Gerade letzteres ist keine Selbstverständlichkeit und Probleme bei externen System sind immer ein Faktor, mit dem man rechnen muss. Wenn du die Schriften dagegen selbst auf deinem Server/Webspace liegen hast und dieser nicht erreichbar ist, ist das insofern unproblematisch, als dass deine Website zur selben Zeit ebenfalls nicht erreichbar ist. Dort sind demnach sämtliche Ressourcen entweder erreichbar oder nicht.
Es kann zudem vorkommen, dass eine Schrift aktualisiert wird und dadurch eventuell plötzlich anders aussieht, als du es dir vorstellst. Das kann verhindert werden, wenn man die Dateien bei sich manuell ablegt.
Datenschutz
Mit jedem Seitenaufruf, auf dem Google Fonts eingebunden sind, fragt der Browser an Googles Server an, ob es Änderungen an den Schriften oder an der CSS-Datei gab. Damit erkennt Google jederzeit, von welcher Seite du eine Anfrage sendest und kennt damit einen Großteil deines Browser-Verlaufs, denn sehr viele Websites nutzen Google Fonts und nur wenige Personen blockieren beispielsweise ihre Referrer oder ähnliches.
Über verschiedene Algorithmen muss demnach nicht einmal eine Google-eigene Website aufgerufen werden, damit Google ein relativ dichtes und nutzbares Netz an Daten erhält, mit der jede normale Person, die sich im Internet bewegt, nachverfolgt werden kann.
Hinzu kommt, dass die Daten höchstwahrscheinlich irgendwann ihren Weg in ein Datenzentrum außerhalb der EU finden, wodurch ein hohes Schutzniveau, wie es aktuell hier der Fall ist, nicht mehr gegeben ist. Geheimdienste, Regierungen und Firmen, die mit derartigen Daten Geld verdienen, haben dann leichtes Spiel.
Alternativen
Die gute Nachricht ist: Es gibt mögliche Alternativen. Zwei davon möchte ich gerne vorstellen.
Die performantere von beiden ist der sogenannte „System Font Stack“. Das ist im Endeffekt die Angabe mehrerer Schriftarten, wovon mindestens eine auf allen populären Systemen bereits vorinstalliert ist. Dadurch muss überhaupt keine Schrift heruntergeladen werden. Dadurch wird Datenvolumen gespart, es müssen weniger Anfragen an irgendeinen Server geschickt werden und der Browser kann sämtliche Schriften direkt anzeigen.
Die zweite Variante wäre, die Schriften einfach selbst zu hosten. Für die Google Fonts gibt es sogar ein eigenes Repository auf GitHub:
https://github.com/google/fonts
Dieses kann man sich beispielsweise komplett auf den eigenen Server klonen oder manuell herunterladen und hat dann sämtliche Google Fonts ebenfalls verfügbar – auf dem eigenen System. Dann fallen keine zusätzlichen DNS-Anfragen oder SSL-Handshakes an und Google bekommt es zumindest nicht mehr über die Google Fonts Informationen über deine Website-Besuchenden. 🤗
Also bei aller Liebe… System-Fonts als „Alternative“ anzubieten…
Da bleibt nämlich nur Arial über…
Das System Font Stack ist nicht nur eine einzelne Schriftart. Das ist der Vorteil daran, weil es ein ganzes „Stack“ ist, also eine Ansammlung.
WordPress nutzt beispielsweise selbst im Backend folgendes Stack:
-apple-system, BlinkMacSystemFont, „Segoe UI“, Roboto, Oxygen-Sans, Ubuntu, Cantarell, „Helvetica Neue“, sans-serif
Wie du hier schon sehen kannst, werden verschiedene Schriften hier genutzt, unter macOS die Systemschrift, unter Windows Segoe UI, unter Android Roboto, unter Linux Ubuntu etc.
Das Ganze geht also weit über Arial hinaus. 🙂
Hallo Matze, danke für deinen Beitrag. Ich finde auch gerade aus der Sicht des Datenschutzes die Fonts nicht über Google geladen werden sollten, allerdings habe ich noch keine Theme entdeckt das es nicht tut. Da sollten mal die Theme-Hersteller auch langsam umdenken.
Was mir hier im Beitrag fehlt ist eine verständliche Anleitung für die Umsetzung deiner zwei alternativen.
Gruß Claudio
Vielen Dank für dein Feedback! Eine Anleitung ist bereits umgesetzt und wird hier bald veröffentlicht. 🙂
Super da freue ich mich drauf! Danke
Hallo Matze,
bei mir läuft es auch auf eine deiner Schlussfolgerungen hinaus:
den System Font Stack nutze ich generell. Es ist eben nicht nur Verdana oder Arial sondern es integriert sich in das OS. Die heutigen System-Schriften laufen auch recht schlank. Verdana und Arial sind ja schon immer Brocken gewesen.
Liegen konkrete Wünsche vor, dann per WOFF und @font-face.
Der Performance Schub bei den System Fonts ist spürbar und gut messbar.
Außerdem bewertet Google die Nutzung der eigenen Server bei Page Speed schlecht. Da sind die schon ehrlich 🙂
Grüße aus der Arnold-Bode-Schule
Deine Schlussfolgerungen kann ich so nur unterschreiben!
Wobei PageSpeed Insights sowieso mit Vorsicht zu genießen ist.
Zustimmung, Pagespeed ist ein Indikator mit Schwächen und teilweise ungenügender Aussagekraft. Allerdings was ganz gut am Pagespeed ist das er relativ plakativ daher kommt und gegenüber Laien leicht kommunizierbar ist. („schau mal, google sagt deine Seite ist Sehr gut“)
Aber gerade das Plakative daran ist gleichzeitig auch ein Problem: Wenn der Kunde sieht, dass seine Seite dort „nur 80 / 100“ Punkten hat und dich dafür verantwortlich macht, dass du seine Website nicht korrekt optimiert hast. Geht also in beide Richtungen. Es kommt also immer drauf an, wie gut die Seite für PageSpeed optimiert ist. 🙈
Ich hatte mir da interessanterweise noch keine Gedanken zu gemacht, um die ganzen Begleitumstände/Vorgänge. Aber nach einigen Gedanken dazu, klingt das alles sehr plausibel.
Vielen Dank für den Wink mit dem Zaunpfahl, gegen den man eigentlich schon bei der Nutzung, bzw. der Überlegung zur Nutzung laufen müsste. Der (menschliche) Faktor Bequemlichkeit steht einem da gern im Wege. Wenn der auftaucht, sollte man gerade zweimal hinschauen.
Beste Grüße und Danke
Ich schätze, nicht nur die Bequemlichkeit war ein Faktor, sondern auch so Dinge wie, dass es der neue „heiße Scheiß“ war, als man begann, es zu nutzen. Und ja, man hat sich einfach oftmals keine Gedanken dazu gemacht… Mittlerweile ist jedoch der Datenschutzgedanke glücklicherweise bei denen, die damit auf technischer Seite zu tun haben, höher.
Also die Hinweise zum Datenschutz sind natürlich richtig, die zur Perfomance aber nicht. Wieso? Hier ein einfaches Beispiel.
Nehmen wir an, ein Nutzer besucht 10 Websites, die alle die Schriftart „Open Sans“ verwenden. Eine Schriftart, die sehr beliebt ist. Jede dieser Websites liefert die Schriftart selbst aus, also wird sie 10 mal geladen. Aber es sind nicht nur 10 Requests, denn die Schrift gibt es in verschiedenen Styles. Oft werden hier die 4 Varianten „normal“, „normal italic“, „bold“ und „bold italic“ geladen. Macht also 40 Downloads auf den 10 Seiten.
Und bei der Einbindung über Google? Wenn alle Seiten die gleichen Schriftvarianten verwenden, wird jede der 4 Dateien genau einmal geladen zzgl. eines Requests für die CSS-Datei, in der diese 4 Dateien referenziert sind.
Diese Datei wird vom Browser 24h zwischengespeichert und nicht erneut abgerufen (könnte länger sein, aber immerhin). Viele Webserver sind aber nicht gut eingestellt und die Dateien werden bei jedem einzelnen Request erneut angefragt und eventuell sogar neu übertragen.
Wie gesagt, im Sinne des Datenschutzes gebe ich dir Recht, bei der Performance aber nicht 🙂
Ist das aber nicht ein sehr theoretisches Beispiel? Bei aktuell über 800 Schriften von Google da innerhalb einer Stunde 10 Stück anzusurfen, die dieselbe Schrift verwenden, muss es sich schon um einen großen Zufall handeln.
Natürlich gehe ich oben von einer vernünftigen Serverkonfiguration aus. Alle Eventualitäten abzudecken ist mithin etwas schwierig. 🙂
Allein aber schon die Zeit, die man mit DNS-Preconnects und zusätzlichen SSL-Handshakes benötigt, dürften auch bei schlechter Konfiguration durchaus auf Null rauskommen. Und für alle, die es hier dann besser machen, gibt es auch mehr Performance.
Nein, das ist ein ziemlich praxisnahes Beispiel. Und der Cache gilt ja auch für 24h. Von den 800 Schriftarten gibt es einige die von Millionen von Seiten verwendet werden (Roboto mit ca. 54 Milliarden Views in 7 Tage, Open Sans mit ca. 28 Milliarden).
Noch klarer wird es, wenn man sich überlegt, dass alle WordPress Websites, die das gleiche Theme verwenden auch exakt die gleiche Schriftart einbinden. Besucht ein Nutzer also beispielsweise zwei Websites, die TwentySeventeen einsetzen, muss die Datei gar nicht mehr geladen werden.
Und das Argument mit dem DNS-Preconnect und dem SSL-Handshake klappt auch nicht, da der Nutzer diese mit Sicherheit mit der Domain fonts.google.com bereits gemacht hat.
Auch wenn Google in ihren FAQs etwas anderes schreibt, so gilt der Cache für die CSS-Datei lediglich eine Stunde. Hier der Response-Header dazu (Aufruf: 17:40:24):
:status: 200
Content-Type: text/css; charset=utf-8
Date: Wed, 16 May 2018 15:40:24 GMT
Timing-Allow-Origin: *
X-XSS-Protection: 1; mode=block
Server: ESF
Access-Control-Allow-Origin: *
Expires: Wed, 16 May 2018 15:40:24 GMT
X-Frame-Options: SAMEORIGIN
Content-Encoding: br
Cache-Control: private, max-age=86400
alt-svc: hq=“:443″; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=“:443″; ma=2592000; v=“43,42,41,39,35″
Ansonsten sind wir uns wohl einig, dass wir uns nicht einig sind. Denn letztendlich wird sich diese Diskussion vermutlich immer im Kreis drehen.