Kontakt

Webfont load

veröffentlicht am:
Das gilt es bei der Performance Optimierung von Schriften für Websitebetreiber:innen zu beachten

Disclaimer: Dieser Artikel enthält Screenshots aus dem Tool webpagetest.org.
Wir haben die Tests mit folgenden Einstellungen durchgeführt:

  • Serverstandort Deutschland
  • Geschwindigkeit Fast3G
  • Device: Motorolla G4

Wir haben diese Konfiguration gewählt, da Googles Page Speed Insights eine ähnliche Konfiguration verwendet.
Alle Zeitangaben des Artikels beziehen sich auf die o.g. Einstellungen.

Website-Betreiber:innen, die Schriften unkontrolliert in ihre Website einbinden, können der Performance ihrer Website schaden, wie auf diesem Beispiel-Screenshot aus webpagetest.org deutlich wird. Nachdem die initiale Verbindung zur Website hergestellt wurde, lädt die Beispiel-Website massenweise Schriften.

Insgesamt lädt die Website 44 Schriften. Bevor irgendwelche anderen Ressourcen geladen werden. 13 Sekunden vergehen.
Die Nutzerin bzw. der Nutzer sieht nach 13 Sekunden Ladezeit das.

Laut SEMRush in dem Artikel “What Is a Good Page Load Time for SEO — How Fast Is Fast Enough?” kann man nicht pauschal sagen, was eine gute Ladezeit tatsächlich ist. Vielmehr verbirgt sich hinter dem Begriff “gute Ladezeit” eine individuelle Wahrnehmung, welche sich nach der Nutzerin bzw. dem Nutzer und ihrem bzw. seinem konkreten Bedürfnis bei Besuch einer Website richtet. Daher sollte man nicht allein nach Schnelligkeit optimieren, sondern auch Nutzer:innensignale wie die Engagementrate und die Absprungrate in Untersuchungen miteinbeziehen. 
Jedoch gibt der Artikel als Richtwert eine Ladezeit zwischen 1-2 Sekunden an.
Das oben gezeigte Beispiel lässt zurecht vermuten, dass das Ziel zufriedener Nutzer:innen verfehlt wurde. 

Wir halten zum Thema Webfont load fest: Schriften sind häufig große Dateien, die eine Weile zum Laden benötigen. Anzahl der Schriften und die Art der Einbindung hat einen großen Einfluss auf die Website-Performance. Auf was sollen Website-Betreiber:innen dabei achten?
Mit dieser Frage beschäftigt sich dieser Artikel.

1. Nur Schriften einbinden, die auch verwendet werden

Die Frage, was Fonts überhaupt sind, haben wir in in dem Artikel "Google Fonts DSGVO konform - Was Website-Betreiber:innen beachten müssen", geklärt.

Das oben erwähnte Beispiel zeigt, wie bereits erwähnt, 44 Schriften, die beim Aufruf einer Website geladen werden. Wenn man sich nun fragt, wie viele davon tatsächlich verwendet werden, dann sieht das Bild so aus:

Welche Schriften sind eingebunden, werden aber nicht genutzt? webpagetest.org gibt Auskunft

Keine der 44 Schriften sind tatsächlich für das Laden der Seite relevant. Demnach kann sich die hier betroffene Seite tatsächlich auf all diese Schriften verzichten und damit 13 Sekunden zum Laden der Seite sparen.

Wer wissen möchte, wie man mithilfe von webpagetest.org erkennt, welche Schriften von einer Seite tatsächlich verwendet werden, findet die Antwort im webpagetest.org Interface. Nach Klick auf einen Run im Menü unter View > Oppotunities & Experiments. Hier taucht der entsprechende Vermerk unter "Is it quick?" auf, wenn es Auffälligkeiten gibt.

Kurz unsere bisherigen Erkenntnisse zusammenfassend: Das bedeutet, das eine Seite immer nur die Schriften laden bzw. überhaupt einbinden sollte, die auch wirklich verwendet werden. 

2. Schriften lokal vom eigenen Server laden

Das lokale Laden von Schriftarten vom eigenen Server hat weitreichende Auswirkungen auf die Ladezeiten von Seiten. Je nach Geschick der lokalen Einbindung kann der Effekt sehr positiv sein oder aber auch negative Auswirkungen haben. Die im Artikel genannten Tipps sollen helfen, möglichst positive Performance-Ergebnisse bei der Schrifteinbindung zu erzielen.

Außerdem befinden sich Website-Betreiber:innen auch auf der rechtlich sicheren Seite, hinsichtlich DSGVO, wenn Schriften von Google auf der eigenen Website eingebunden werden.
 
Der Unterschied in den Ladezeiten zeigt sich über die Zeit, die beim Verbindungsaufbau zu externen Ressourcen benötigt wird. Vom Entdecken der Schrift auf - in diesem Beispiel - dem Google Server bis kurz vor Empfang des First Byte vergehen 1254 ms. Die verbleibenden 609 ms zu den im Screenshot gezeigten 1863 ms erstrecken sich dann auf die Zeit des First Byte Empfang zum abschließenden Download der Ressource.
In diesem Request wird zunächst nur die CSS-Datei der Schrift geladen mit der font-face-Regel.

Die CSS-Datei der Schrift wird geladen.

Für das Herunterladen der eigentliche Schrift ist ein erneuter Verbindungsaufbau zum gstatic-Server notwendig, der 1150 ms in unserem Beispiel dauert. DNS-Lookup (grüner Balken), Connection und SSL-Negotiation (orange und pinke Verbindung) sind in dem vorliegenden Beispiel zeitlich versetzt, da die Ressourcen hier durch die Hinweise DNS prefetch und den Link-Relation-Type preconnect bereits frühzeitig angegangen werden können.

Verbindung zum gstatic-Server.

Schriften, die lokal über die Website geladen werden, benötigen keinen zusätzlichen Verbindungsaufbau. 
Die Zeitersparnis für die Webperformance könnte hierbei, je nach Einbindung der lokalen Schrift, zwischen 600 bis 800ms betragen.
Demnach ist es nicht nur aus DSGVO-Gründen, sondern auch aus Webperformance-Einsparungen ratsam, Schriften lokal über die eigene Website einzubinden.

3. Webfont load: Schriften preoloaden

Schriften, die bereits Above the Fold eine wichtige Rolle spielen, sollten vorgeladen werden. 
Im Folgenden Beispiel sieht man, wie das Laden einer Schrift zu einem Layoutshift führt. 

Layout Shift, ausgelöst durch das Nachladen der Schrift.

Solche Nachlade-Erscheinungen können umgangen werden, wenn der betreffenden Schrift ein preload-Tag gegeben wird, d.h. <link rel="preload" as="font">. Damit wird die Schrift geladen, sobald die Ressourcen dafür frei sind. Sofern die Schrift deutlich vor dem FCP geladen wird, kann man erreichen, dass der Nutzer die Seite sofort Schriftarten technisch gestylt sieht und keinen nervigen Layout-Shift mehr wahrnimmt.
Google beschreibt in seinen Ressourcen zu diesem Thema unter "Preload your webfont resources" ausführlich, welche Möglichkeiten es hierfür gibt. 

4. Schriften im Rendering-Prozess sofort sichtbar machen

Auch wer preload nutzt, kann sich noch nicht sicher sein, dass der Browser die Schrift schnell genug lädt. Der Browser weiß zwar, dass er die Ressource bevorzugt laden soll, aber die Reihenfolge der zu ladenden Ressourcen ist damit immer noch nicht sicher. Bezogen auf Schriften kann dies kurzzeitig zu einem weißen Bildschirm bei Nutzern führen. SEO-Manager mag die Meldung “Avoid invisible text during font loading” in diesem Zusammenhang bei der Webperformance-Optimierung schon einmal aufgefallen sein. 

Page Speed Insights Warnung Schriften immer sichtbar zu machen während des Ladevorgangs.

Damit dies nicht passiert, schlägt Google zwei Möglichkeiten vor. 
 
Bei der ersten Möglichkeit wird ein System-Font angezeigt, bis der eigentlich Font geladen werden kann. Diese Möglichkeit basiert auf der CSS-Anweisung font-display, die nicht von allen Browsern gleichermaßen unterstützt wird: Mehr Informationen dazu bietet der Google-Guide unter "Use font display".

Bei der zweiten Möglichkeit wird inhaltlich ein ähnliches Vorgehen wie bei der erstgenannten Möglichkeit angestrebt. Der Unterschied hierbei ist, dass man quasi manuell (durch eine JavaScript-Anweisung) den Browser dazu anhält im entscheidenden Moment Systemschriften zu laden, bis die tatsächlichen Schriften geladen werden können. Der Vorteil hiervon ist, dass es browser-übergreifend durchführbar ist. Mehr Informationen hierzu finden sich auch im Google-Guide, unter "Wait to use custom fonts until they are loaded".

5. Schriften cachen

Damit Schriften bei Nutzern, die nochmal die Website besuchen, nicht immer wieder neu geladen werden müssen, gibt es die Möglichkeit sie zu cachen und für den Cache von Schriften ein “Ablaufdatum”, d.h. einen Zeitraum, wie lange eine Schrift gecached werden soll, zu definieren. Damit wird die Ladezeit der Schriften, bei einem wiederholten Besuch der Website, eingespart.

Mehr Informationen zum Caching von Schriften liefert dieser Artikel von Google “Proper caching is a must".

6. Schriften durch HTTP/2 Server Push zeitgleich zum HTML pushen

Einen weiteren Schritt, den man gehen kann, um Schriften möglichst zügig auszuliefern ist der HTTP/2 Server Push. 
Der HTTP/2 Server Push ermöglicht es, Nicht-HTML-Assets wie Schriftarten zusammen mit einem HTML-Dokument zu übertragen.
Dies unterscheidet sich von der herkömmlichen Art der Auslieferung von HTTP-Anfragen, bei der das HTML-Dokument geparst werden muss, bevor nachfolgende Anfragen zum Abrufen von Fonts und anderen Assets gestellt werden können. 

Erst nachdem das HTML geparst wurde, können die Schriften geladen werden.

Auch hier kann man gute Performance-Gewinne erzielen. Wer wissen möchte, ob Server Push für die eigene Website in Frage kommt, kann hier mehr darüber in dem Guide zu "HTTP2 Server Push" erfahren.

7. Hat die Schriftart einen Effekt auf SEO?

“Does font size affect seo?”, wurde John Müller über Twitter 2020 gefragt. Die Antwort ist deutlich: “Die Schriftart hat keinen Effekt auf SEO.”
https://twitter.com/JohnMu/status/1265191575723925504

John Muller äußert sich über Twitter zu Schriften.
Lisa Fellinger
ehem. Team Lead Data

Lisa war bis November 2023 Team Lead des Data Management Teams und davor Team Lead SEO.

Ähnliche Artikel
Zum Artikel
Paid Social

YouTube Assets - Mit der richtigen Konzeption zum Erfolg

Dieser Artikel gibt einen umfassenden Überblick, wie Sie mit angemessener Vorbereitungszeit und einer gründlichen Konzeptionsphase ein plattformkonformes Video nach dem Google ABCD-Modell erstellen können.

Zum Artikel
SEO

Marketing-Herausforderungen von Personas in Bezug auf Barrierefreiheit

Die Verwendung von Personas im Marketing ist eine weit verbreitete Methode, um Zielgruppen zu verstehen und maßgeschneiderte Kampagnen zu entwickeln. Es gibt jedoch eine wichtige Dimension, die bei der Erstellung von Personas oft vernachlässigt wird: Barrierefreie Zugänglichkeit.

Zum Artikel
Szene

Recap: SEAcamp Jena 2023

Das SEAcamp feierte 10 jähriges Jubiläum. Sebastian war mit Nadine und Sophie vor Ort und hat seine Highlights und Learnings von dem Event zusammengefasst. Privacy, Automation mit Beispielen von PMAX-Kampagnen und die Nutzung von ChatGTP im SEA waren die Hauptthemen des diesjährigen Events.

Kontakt
Projektanfrage

Wir freuen uns auf Ihre Anfrage und beraten Sie gerne individuell zu Ihren Themen.

Max Höpner, Geschäftsführer

Max Höpner Geschäftsführer

Zum Kontaktformular