Eine Möglichkeit den „Flash of unstyled text“ bei Webfonts zu vermeiden

Datum: 9. November 2017
Autor*in: Benjamin Hofmann


Es gibt nicht viele Newsletter, die ich abonniert habe. Einer davon ist aber der Newsletter vom Smashing Magazine, da die Qualität davon bisher dauerhaft sehr gut war und dessen die Inhalte nicht nur einfache Links auf die ohnehin vorhandenen Beiträge der Seite selbst darstellen, sondern immer eine sehr schöne Ergänzung zu diesen liefern und auch andere Themen beleuchten.

Eines der Themen im letzten Newsletter (Issue #193) war das kleine und sehr nützliche Online-Tool Font style matcher und wahrscheinlich ist jeder schon einmal über das damit anzugehende Problem gestoßen. Man besucht eine Website, fängt an den Text zu lesen und erst mitten in einem der ersten Absätze wird dann die eigentliche Schriftart geladen, der Text verschiebt sich und man muss von vorne anfangen.

Dieses Phänomen nennt sich FOUT (flash of unstyled text) bzw. FOUC (flash of unstyled content) und kommt daher, dass Browser versuchen eine Website zu rendern bevor alle dafür benötigten Stylings geladen wurden. Da Schriften neben Bildern zu den mitunter größten Ressourcen einer Website gehören, haben die verschiedenen Browserhersteller hier verschiedene Wege gefunden die Anzeige dieser etwas zu optimieren. Das allein reicht jedoch nicht aus und es gibt diverse Strategien Webfonts effizienter zu laden und den FOUT bzw. FOUC gezielt zu vermeiden. Viele dieser Mechanismen sehen eine websichere Schrift als Fallback vor und wenden den Webfont selbst erst dann im Styling an, wenn dieser auch tatsächlich geladen wurde und damit bereit zur Anzeige ist.

Animiertes GIF, welches die Vorschau des Font style matcher in Aktion zeigt.

Dieses Vorgehen führt aber oft genug dazu, dass sich der Text dann verschiebt, da die websichere Schrift natürlich eine ganz andere Laufweite und Größe hat als die im Design vorgesehene Schrift. Und genau an dieser Stelle versucht der Font style matcher einzugreifen und erlaubt es über ein paar Schieberegler den Fallback-Font in seinem Aussehen weitestmöglich dem eigentlichen Font anzupassen, damit der Wechsel zwischen diesen beiden weniger gravierend ausfällt. Im animierten GIF oberhalb dieses Absatzes habe ich das einmal mit den Schriften „Lato“ und „Verdana“ als Fallback ausprobiert und bin durchaus begeistert vom Resultat.


Kommentare

Selber kommentieren:






Weitere Beiträge zum Thema User Experience & Design


video.js – HTML5-Video-Kmponente mit Polyfill für alte Browser

Autor*in: Stefan Oswald


Projekte // Technologie // User Experience & Design


Webseite: http://www.videojs.com/ Ich habe es mir noch nicht im Detail angeschaut, aber rein von der Beschreibung her könnte das für uns mal ganz nützlich sein. Man kann per API auch Loader für eigene Video-Provider umsetzen. Kostenlos einsetzbar dank Apache 2.0 Lizenz.


Beitrag lesen
14
MAI
13

Inhouse Hallway Testing bei infomax

Autor*in: Anna Zsófia Höfler


Strategie & Konzeption // User Experience & Design


Bei der Bereitstellung einer neuen Leistung für unsere Kunden gehörte „Testing“ bisher selbstverständlich zur Umsetzung dazu. Nach der Fertigstellung einer Umsetzung wurde die Funktionalität vom Entwickler, dem Projektmanager und vor Abnahme der Leistung auch von unseren Kunden getestet, sodass eine Qualitätssicherung durch mehrere Stufen erfolgte. Ein gerne vernachlässigter Fakt ist jedoch, dass diese Personen bereits …


Beitrag lesen
14
MAI
20

font-face rendering Problem

Autor*in: Steven Schöning


User Experience & Design


Vielen ist bestimmt bekannt, dass Schriftarten auf Mac oder iOS anders dargestellt werden. Hier gab es einen Interessanten Beitrag, der sich mit dem Problem befasst und es einfach löst. Ihr müsst einfach diesen Styling hinzufügen: -webkit-font-smoothing: antialiased; Laut der Quelle ist es nicht möglich den Styling Global auf den body zu setzen, doch anscheinend ist …


Beitrag lesen
24
AUG
16

WebKit Sibling Bug

Autor*in: Benjamin Hofmann


Technologie // User Experience & Design


Bei kleineren Anpassungen in einem unserer Projekte ist heute im alten Standard-Browser von Android ein Bug[1] aufgefallen, der dazu führte, dass die Listenelemente mit initial verstecktem Inhalt diesen beim Anklicken nicht anzeigten. Nach einer kurzen Recherche bin ich hier auch auf die Lösung gestoßen, den Checkbox Hack on Mobile Webkit[2]. Klingt fies, ist aber nur …


Beitrag lesen
13
MRZ
15