Das Problem ist: 1) Benutzerdefinierte Schriftarten sind großartig und wir wollen sie verwenden. 2) Benutzerdefinierte Schriftarten verlangsamen unsere Seiten, da sie zusätzliche, große Ressourcen darstellen. Die Bewältigung dessen ist in letzter Zeit ein Thema, daher dachte ich, ich fasse einige der Ideen zusammen und füge meine eigenen Gedanken hinzu.
Nur für große Bildschirme laden
Die erste Idee, die ich sah, waren Dave Ruperts Tests zum Laden von @font-face nur auf großen Bildschirmen. Es stellt sich heraus, dass, wenn Sie @font-face verwenden, aber die Schriftartfamilie nie anwenden, die Schriftart nicht heruntergeladen wird. Ziemlich clever, Browser. Daves Demo.
@font-face {
font-family: 'Dr Sugiyama';
font-style: normal;
font-weight: 400;
src: local("Dr Sugiyama Regular"), local("DrSugiyama-Regular"), url(http://themes.googleusercontent.com/static/fonts/drsugiyama/v2/rq_8251Ifx6dE1Mq7bUM6brIa-7acMAeDBVuclsi6Gc.woff) format("woff");
}
body {
font-family: sans-serif;
}
@media (min-width: 1000px) {
body {
font-family: 'Dr Sugiyama', sans-serif;
}
}Jordan Moore hat im Typekit Blog einen Artikel „Fallback Fonts on Mobile Devices“, der dieselbe Überlegung verwendet.
Ich habe diese Überlegung auf mein eigenes Projekt angewendet, indem ich zwei separate Schriftartensätze erstellt habe: einen „vollständigen“ Satz mit allen typografischen Stilen, die ich ursprünglich verwenden wollte, und einen „leichten“ Satz mit weniger Schriftarten (und dementsprechend deutlich geringerem Gewicht). Ich habe die Sätze per JavaScript geladen, abhängig von der Bildschirmbreite des Benutzers, wobei der Wert auf dem kleinsten Breakpoint basierte.
Mit Daves Technik müssten Sie sich keine Sorgen um FOUT (Flash of Unstyled Text) machen, da nativer @font-face-Code verwendet wird und die meisten Browser damit umgehen können. Jordans Technik wäre meiner Meinung nach stärker von FOUT betroffen, da die Schriftarten nach einem Test geladen werden müssten, aber Sie könnten das so beheben, wie Sie es immer mit Typekit beheben: mit visibility: hidden, während die Schriftarten geladen werden.
Schriftarten über Ajax laden
Wenn Ihr größtes Anliegen die Verlangsamung der Renderzeit ist (nicht unbedingt die Zeit bis zum vollständigen Laden der Seite), könnten Sie das Stylesheet, das den @font-face-Inhalt enthält, nach "document ready" über Ajax laden. Omar Al Zabir hat ein Tutorial dazu. (Danke Kevin)
$(document).ready(function(){
$.ajax({
url: fontFile,
beforeSend: function ( xhr ) {
xhr.overrideMimeType("application/octet-stream");
},
success: function(data) {
$("<link />", {
'rel': 'stylesheet'
'href': 'URL/TO/fonts.css'
}).appendTo('head');
}
});
});Sicherzustellen, dass die Schriftartdateien "far expires headers" haben, ist ebenfalls wichtig. Um hier FOUT zu vermeiden, würden Sie der <html>-Element ein Klasse hinzufügen (sofort per JavaScript), die Sie verwenden, um das zu Verbergende mit visibility: hidden zu versehen, bis die Schriftarten geladen sind, und diese dann im Ajax-Erfolgs-Callback entfernen.
Schriftarten per Lazy Load laden, auf nachfolgenden Seitenaufrufen nach dem Caching laden
Diese Idee erweiternd könnten wir benutzerdefinierte Schriftarten nur anzeigen, wenn wir ziemlich sicher wären, dass die Schriftartdateien zwischengespeichert sind. Auf dem Backend prüfen wir auf ein Cookie (das wir später selbst setzen), das anzeigt, dass die Schriftarten zwischengespeichert sind.
// Check if cookie exists suggesting fonts are cached
if (fonts_are_cached) {
echo "<link rel='stylesheet' href='/URL/TO/fonts.css'>";
}Auf dem Frontend machen wir genau das Gegenteil. Wenn das Cookie nicht vorhanden ist, laden wir diese Schriftarten per Lazy Load und setzen dann das Cookie.
// Check if cookie exists suggesting fonts are cached
if (!fonts_are_cached) {
// Don't slow down rendering
$(window).load(function() {
// Load in custom fonts
$.ajax({
url: 'URL/TO/font.woff'
});
$.ajax({
url: 'URL/TO/font.eot'
});
// Don't actually do anything with them, just request them so they are cached.
// Set cookie indicating fonts are cached
});
}Nicht narrensicher, da dieses Cookie nicht zu 100% beweist, dass die Schriftart zwischengespeichert ist. Aber wenn Sie es beispielsweise auf einen Tag Laufzeit setzen, hat es eine gute Chance. Keine FOUT hier, da entweder die Schriftarten gar nicht geladen werden oder nativ mit @font-face. Wenn Ihnen FOUT nichts ausmacht (d.h. Sie möchten Ihre benutzerdefinierte Schriftart beim ersten Seitenaufruf auf jeden Fall anzeigen), könnten Sie das <link>-Element erstellen und das Schriftarten-Stylesheet einfügen, anstatt nur die Schriftarten anzufordern.
Eine weitere Alternative wäre, eine Data-URI-Version der Schriftart in localStorage zu speichern und sie bei Bedarf abzurufen. Sie würden ein <style>-Element erstellen, den @font-face-Code darin einfügen und die Data-URI-Version der Schriftart verwenden und diese injizieren. Angeblich versucht The Guardian das.
@scottjehl Bezugnehmend auf die Cache-Diskussion: The Guardian spielt mit localStorage. github.com/guardian/front… @davatron5000 @chriscoyier
— Tim Kadlec (@tkadlec) 17. April 2013
Als faire Warnung: localStorage kann langsamer sein als der Cache.
@tkadlec @scottjehl @davatron5000 @chriscoyier lokaler Speicher funktioniert, wenn Sie ihn unbedingt benötigen, kann aber langsamer zu lesen sein als der Browser-Cache
— Addy Osmani (@addyosmani) 17. April 2013
Ein möglicher Vorteil der Verwendung von JavaScript-Tricks ist die Kenntnis der benötigten Schriftartversionen.
@davatron5000 @sturobson @chriscoyier Wir laden Data-URI-Schriftarten per insertBefore. Standardmäßig WOFF.css, aber TTF oder EOT für Android/IE
— Scott Jehl (@scottjehl) 17. April 2013
Die Zukunft
All dies wird besser, je mehr Informationen wir über die Situation des Clients erhalten können.
Welche Bandbreite und Latenz hat er? Das ist ziemlich schwer (und aufwendig) zu testen und selbst wenn wir es können, nicht sehr zuverlässig. Vielleicht hilft irgendwann die Network Information API.
Wie groß ist sein Bildschirm? Welche Fähigkeiten hat der Browser? Wir können dies per JavaScript testen, aber was, wenn es besser wäre, es serverseitig zu wissen? Vielleicht hilft irgendwann Client-Hints.
Web-Schriftarten werden doch zwischengespeichert, oder? Es ist also nur ein Problem beim ersten Laden?
Bei Ihrer Lazy-Load-Methode... entweder ich verpasse etwas, oder die gesamte erste Seitenansicht ist ein riesiger 'FOUT'. Vielleicht meinen Sie damit „unangenehm“, oder?
Nein, die gesamte erste Seite wird keine benutzerdefinierten Schriftarten haben. Schöne Schriftarten erscheinen, wenn Sie die Website neu laden oder eine Unterseite besuchen. Liege ich richtig?
Ich wünschte, ich könnte JavaScript viel schneller lernen :)
Schauen Sie sich codecademy.com an, sie haben tolle kostenlose Lernpfade für JavaScript und jQuery
Ein weiterer schneller Tipp: Wenn Sie die Schriftartdateien selbst hosten, können diese auch komprimiert werden (außer im WOFF-Format), mit einer Größenersparnis von 40-70%. Siehe Gzip your @font-face files und @font-face and performance für weitere Details.
Die Ajax-Methode ist purer „Floss“...
Definiere „flossin“: Prahlerei mit einem Objekt, das normalerweise von großem Wert ist (Urban Dictionary).
Ich weiß nicht viel – aber ich denke, die Methode "Media Query" ist ausreichend... selbst in Südafrika #ernsthaft.
Sehr nützlicher Artikel.
Ich stimme @Archie Makuwa zu. Ich denke, die "Media-Query"-Lösung ist die einfachste und zuverlässigste. Ich wünschte, wir könnten Bandbreiten-Media-Queries verwenden! https://css-tricks.de/bandwidth-media-queries/
Für mich ist die Methode mit der Breiten-basierten Media-Query einfach falsch. Die Bildschirmgröße ist ein sehr schlechter Indikator für die Bandbreite, und auf meinem Desktop habe ich einen durchschnittlichen Bildschirm.
Auf meinem Nexus 4 habe ich einen wunderschönen HDPI-Bildschirm und auf meinem iPad einen Retina-Bildschirm – auf welchen Geräten möchte ich gestochen scharfe, schöne Schriftarten? – gerade auf denen, die von Media-Queries ausgeschlossen werden könnten.
Meiner Meinung nach müssen wir (und ich bin sicher, das werden wir) zu einem Punkt gelangen, an dem wir die Verbindungsgeschwindigkeit des Benutzers zuverlässig erkennen können – die NetworkInformation und Connection-Schnittstellen sehen vielversprechend aus, wenn auch etwas entfernt.
Solange wir nicht wirklich wissen, wie schnell ein Benutzer die von uns gesendeten Daten herunterladen wird, können wir sein Erlebnis nicht optimieren – der beste Weg ist im Moment, für alle zu optimieren, indem wir Seiten für alle Szenarien so leicht wie möglich machen.
Dies ist ein weitaus größeres Problem für reaktionsfähige Bilder als für Schriftarten, da wir für eine schnelle, websiteweite Erfahrung nicht so effektiv zwischenspeichern können.
Oh, für "media all and (min-speed: ~1Mbps) {}" usw.!!
Für den Moment, wenn die Website eines Kunden sehr geschwindigkeitsabhängig ist (hoffentlich unterstützt durch solide Analysedaten und Benutzerforschung), verwende ich einfach Websafe-Schriftarten, langweilig, aber schnell. Oder ich gehe Kompromisse mit einem gut optimierten, leichtgewichtigen Schriftstapel (normalerweise von Typekit) ein, wenn wir keine kursiven Schriftarten verwenden, laden wir keine kursiven!
Ich stimme zu, dass der Test für "große Bildschirme" durch einen Verbindungstest ersetzt werden sollte. Jeder auf einem Mobilgerät könnte über blitzschnelles WLAN verfügen – warum sollten sie andere Schriftarten bekommen?
Ich denke, Foresight.JS wäre ein guter Ausgangspunkt dafür. Ich bin mir nicht sicher, ob Sie es als "zuverlässig" betrachten würden, aber einige Informationen sind besser als keine.
Ja, FOUT versuche ich wirklich zu vermeiden, selbst wenn es nur anfänglich ist. Dinge wie Typkit und Google Fonts sind großartig und alles, aber ich finde, dass das Speichern der tatsächlichen Schriftarten im Website-Verzeichnis und das Aufrufen im Stylesheet gut funktioniert. Sicher, es fügt etwas Gewicht zur Seite hinzu, aber ich denke, der Kompromiss ist es wert, ist es wirklich so schlimm?
Außerdem habe ich festgestellt, dass es nicht nur zu FOUT kommen kann, wenn man auf Schriftarten anderer Server verlinkt, sondern wenn die Fallback-Schriftart eine andere Zeilenhöhe oder Polsterung hat, können sich Elemente etwas verschieben. Das trägt zur Unannehmlichkeit bei...
Sie irren sich – gehostete Schriftartdateien sind fast **immer** schneller als selbst gehostete. Die meisten gehosteten Schriftarten befinden sich auf einem CDN, das immer schneller ist als nicht-CDN-Hosting. Außerdem würden Dateien, die auf Ihrer Domain gehostet werden, sequenziell geladen, normalerweise 2 gleichzeitig... während Dateien, die auf einer anderen Domain gehostet werden, parallel zu den Dateien auf Ihrer Domain geladen werden. Schließlich wird eine gehostete Schriftartdatei (wie Open Sans auf Googles CDN) wahrscheinlich bereits im Browser des Benutzers zwischengespeichert... was bedeutet, dass die Datei beim ersten Besuch Ihrer Website gar nicht geladen wird. Wenn Sie sich entscheiden, Ihr eigenes Open Sans zu hosten, müsste es für *jeden* Benutzer, der Ihre Website besucht, geladen werden.
Ich habe kürzlich ein Video darüber veröffentlicht, wie ich Schriftarten bereitstelle. Es behandelt nicht wirklich etwas in diesem Artikel, sondern befasst sich mit Subsetting, Encoding usw. Ihr Katzen könnten es sich einmal ansehen.
Exzellentes Tutorial, leicht verständliche Informationen und besonders hervorragende Audioqualität. Danke.
Ich finde auch, dass Media-Queries die beste Lösung sind.
Das alles wird besser, je mehr Informationen wir über die Situation des Clients erhalten können!
Unbenutzte Schriftarten *werden* auf IE <= 8 heruntergeladen. Hier sind die Ergebnisse für IE7 und IE8.
Danke für diesen Artikel... Ich habe nach Möglichkeiten gesucht, damit umzugehen. Manchmal verlangsamt Google Webfonts meinen Seitenaufruf bis zum Stillstand. Ich freue mich auf die Zeit, in der wir eine standardisierte Lösung dafür gefunden haben.
Sehen Sie, meine Frage ist: Wie stark ist die Performance-Belastung durch benutzerdefinierte Schriftarten? Auf einer meiner Seiten, die mobil-zuerst gestaltet wurde, scheinen die beiden Schriftarten, die ich verwende, den Ladevorgang nicht zu verlangsamen — vielleicht liegt es daran, dass das Übrige sehr leichtgewichtig ist — und ich kann die Schriftarten nicht als Faktor für die Ladezeit isolieren.
Wenn Sie Chrome verwenden, könnten Sie den Inspektor benutzen. Klicken Sie mit der rechten Maustaste irgendwo auf der Seite und gehen Sie zu "Element inspizieren", klicken Sie dann auf den Tab "Netzwerk" und laden Sie die Seite mit einem Hard-Refresh neu (STRG+SHIFT+R).
Sie sollten einige Hinweise aus der Ausgabe erhalten.
Das ist nützlich. Schon lange frage ich mich, ob es sich lohnt, die Ladezeit der Seite zu opfern, nur um eine benutzerdefinierte Schriftart zu verwenden oder nicht, weil es viele Leute mit langsamen Internetverbindungen gibt und das eine große Abneigung für sie ist. Zum Beispiel, wenn ich innerhalb der ersten Sekunden keinen Text sehe – werde ich die Seite einfach verlassen.
Persönlich kann ich nicht darauf verzichten, benutzerdefinierte Schriftarten für eine bessere Performance zu verwenden, aber ich denke, es ist einfach, etwas Seitenlast zu sparen, indem man wählt, welche Schriftarten und wie viele davon. Ich verwende normalerweise die Google Font API und wähle maximal 2 der beliebtesten Schriftarten, da die Wahrscheinlichkeit, dass beliebte Schriftarten bereits heruntergeladen und zwischengespeichert wurden, viel höher ist.
Danke für die Klarstellung... Benutzerdefinierte Schriftarten sind in Unternehmensumgebungen absolut nutzbar, z. B. für öffentliche Websites wie Facebook? Eher nicht... – völlig unabhängig von der gelieferten Performance.
Ich wusste nichts von der AJAX-Methode. Das wird mir wirklich helfen. Können Sie mir sagen, ob es eine standardisierte Methode dafür gibt?
Für Typekit laden wir nur, wenn eine Bildschirmgröße über Media Queries erkannt wird. Vor einigen Wochen haben wir dazu ein Tutorial erstellt hier (Ich habe es gerade ins Englische übersetzt, entschuldigen Sie etwaige Tippfehler!). Die Methode stammt von Jeremy Keith und einigen Tests zur bedingten Ladung. Dies ist ein weiterer Ansatz, lassen Sie uns gerne einen Kommentar da!
Gute Notizen hier. Ich würde nur eine letzte Technik hinzufügen, die die Dateigröße meiner benutzerdefinierten Schriftart von 900KB auf 17KB reduziert hat.
**Nicht immer die beste Option**, aber immer noch ziemlich interessant. Ich habe Cufón auf dieser Website verwendet. Cufón ist eine kleine JavaScript-Engine, mit der Sie die ganz spezifischen Zeichen laden können, die Sie benötigen. Ich hatte sogar die Gelegenheit, dafür ein Tutorial für Inspired Mag zu schreiben. Schauen Sie es sich an!
(Editor: Tote Links entfernt)
Es scheint, dass der Weg über Media Queries der einfachste ist. Das Problem ist, dass man keine Möglichkeit hat zu wissen, welches Gerät oder welche Verbindungsgeschwindigkeit die Person hat, basierend auf einem Breitentest. Sicher, es gibt eine "gute Chance", dass >1200px wahrscheinlich ein Desktop ist, aber es könnte alles sein.
Ich denke, es liegt am Website-Besitzer, seine Analysen zu studieren und genauer zu bestimmen, welche Art von Benutzerdemografie er hat, und dann zu entscheiden, ob es eine akzeptable Entscheidung ist, potenziell schwere Schriftarten zu verwenden.
Wirklich großartiger Artikel. Ich liebe benutzerdefinierte Schriftarten, aber ich hasse es, meine Seiten zu verlangsamen. Ich werde definitiv einige dieser Techniken anwenden!
Während Schriftarten ein Anliegen sind, sehe ich immer noch eine riesige Menge an Websites, die (buchstäblich) ein Dutzend verlinkte CSS-Dateien und vielleicht die gleiche Anzahl an verlinkten JavaScript-Dateien im Kopf des Dokuments haben. Oft ist nichts davon komprimiert, bevor es ausgeliefert wird. Ich werde bei 10 x 10kb-Dateien nervöser als bei einer einzelnen 100kb-Schriftartdatei.
Meiner Meinung nach gibt es viele andere Dinge, die Leute tun können, um die Ladezeit und Renderzeit ihrer Dokumente zu verbessern, bevor sie sich Sorgen machen, ihre Lieblingsschriftart aufzugeben. Das bedeutet aber nicht, dass wir nicht vernünftig sein sollten – es sei denn, Sie brauchen die Schriftart wirklich, wirklich in 3 verschiedenen Schriftschnitten und Kursivschrift, dann nehmen Sie diese Variationen nicht auf!
Eine Frage zu Google Fonts;
Gibt es Unterschiede bei der Ladezeit (oder Performance) zwischen der Verwendung einer Google-Schriftart nur für eine Überschrift im Vergleich zu allen Texten auf einer Website?
Da der eigentliche Download der Schriftartdateien die Ladezeit hauptsächlich beeinflusst, würde ich denken, dass die Verwendung der Schriftart für den gesamten Inhalt keinen Unterschied macht? Aber ich rate nur..
/Simon
Hat jemand Benchmarks zur Rendergeschwindigkeit (nicht Downloadgeschwindigkeit) verschiedener Schriftarten (ttf, woff, svg) gesehen? Wenn nicht, wie misst man das?
Sehr interessant, toller Artikel. Ich habe RUM (Real User Monitoring) bei PingDom eingerichtet, einem Dienst für Front-End-Benutzerüberwachung. Es bietet eine weitaus bessere Benutzererfahrungsmessung als GA (Google Analytics), da es speziell dafür entwickelt wurde, das zu messen, was der Benutzer durchmacht. Ich hatte jetzt ein paar hundert Aufrufe und sehe einige interessante Daten. Es misst
Umleitung -> DNS -> Verbindung -> Senden -> Empfangen -> DOM-Verarbeitung -> Rendern
Interessanterweise liegt meine durchschnittliche Seitenladezeit bei 1,4 Sekunden, womit ich sehr zufrieden bin. ABER, in meinem Diagramm sehe ich, dass die Renderzeit einige RIESIGE Spitzen aufweist, eine davon ist 35 Sekunden lang.
Soweit ich weiß, ist dies das einzige Tool, das ich je verwendet habe, das mir solche Daten liefert, daher dachte ich, ich würde es teilen. Alles, was Sie tun müssen, ist, Code ähnlich wie bei der Analyse einzurichten, und der Code ist asynchron und die Datei ist winzig, also keine wirkliche Auswirkung auf die Website.
Ich kratze hier aber nur an der Oberfläche, es gibt einige super interessante Daten zu mobilen und Tablet-Renderzeiten. Es enthält Browserinformationen, Erfahrungsindex, nach Land, nach Seite und mehr.
Hat jemand andere ähnliche Tools verwendet?
Wenn ich mit Kunden spreche, wie kann ich genau erklären, welchen Einfluss eine Web-Schriftart hat? Habe ich Recht, dass es sich nur um etwa 200 KB bis 400 KB an Informationen handelt, also ungefähr dasselbe wie das Hinzufügen eines weiteren Fotos zu einem großen Hero-Slider auf der Titelseite ihrer Website? Und dass, wenn es sich um etwas Gängiges wie Open Sans handelt, viele ihrer Website-Besucher die Schriftart bereits zwischengespeichert haben? Korrigieren Sie mich, wenn ich falsch liege.
400 KB hier und da können sich wirklich summieren. Deshalb wiegt die durchschnittliche Webseite heute weit über 1 MB, einschließlich aller ihrer Assets. Ja, wenn Sie Open Sans vom Google CDN bereitstellen, besteht eine gute Chance, dass Ihr Besucher es zwischengespeichert hat, aber wenn Sie eine ungewöhnliche Schriftart wählen und das CDN nicht nutzen (oder nicht nutzen können), wird es einen Performance-Einbruch im Vergleich zur Verwendung einer Websafe-Schriftart geben, die der Besucher lokal installiert hat.
Als Old-School-Denker gerate ich in Panik, wenn ein einzelnes Asset über 50 KB groß ist :-)
Meine Gedanken dazu sind:
1) Wenn Sie externe Schriftarten verwenden, versuchen Sie, solche von einem CDN zu verwenden.
2) Versuchen Sie, "Standard"-Schriftarten zu verwenden, z. B. Open Sans, Droid Sans usw. Es gibt eine höhere Wahrscheinlichkeit, dass Ihre Besucher diese zwischengespeichert haben, und sie sind erwiesenermaßen zuverlässig im Rendern/Anzeigen.
3) Versuchen Sie, nicht mehr als 1, vielleicht höchstens 2 benutzerdefinierte Schriftarten zu verwenden. Ich denke, eine Website, die 3 oder mehr verschiedene Schriftarten verwendet, wird sowieso seltsam aussehen.
4) Wenn Sie Icon-Schriftarten verwenden, leiten Sie diese durch ein Tool wie Icomoon.io, mit dem Sie nur die gewünschten Icons auswählen können und somit die Größe der Schriftart erheblich reduzieren.
Danke! Ich habe kürzlich einige Websites besucht, die drei oder vier Web-Schriftarten, verschiedene Schriftschnitte, sowie große Slider und Grafiken überall verwendet haben, und die Websites waren viel zu schwer. Aber ich denke, für meinen aktuellen Kunden wird eine gängige Web-Schriftart ausreichen – sie möchte, dass ihr Website-Update frisch und modern aussieht, und ich denke, ein Teil davon wird die Wahl einer neuen Schriftart sein.
Ich wollte nur herausfinden, welcher Weg besser und schneller ist, benutzerdefinierte Schriftarten auf einer Website zu verwenden.
Ist es über die @font-face-Methode oder Google Fonts?
Beide verwenden @font-face. Die Latenz hängt also davon ab, wie schnell Ihr Host die Datei im Vergleich zu Google bereitstellt.