Wo im Styleseet font-face notieren? Geschwindigkeit bei selbst gehosteten webfonts optimieren

[Matinee]

Hallo,

ist es egal oder doch von Vorteil, die @font-face-Blöcke für die eingebetteten Schriften gleich als Erstes im Stylesheet zu notieren?

Wenn besser zu Beginn, dann nach dem CSS-Reset, das ja üblicherweise als Erstes kommt?

Was den Einfluss der webfonts auf die Geschwindigkeit angeht, so würde ich neben dem Browsercaching ein preload für alle drei fonts anwenden.

Das Erste, was der User ganz oben auf den Webseiten sieht, ist allerding eine Headergrafik, kein Lesetext.

---

Grüße,

Matinee

[Rolf B]

Hallo Matinee,

da Du keine @font-face Angaben resetten kannst, kannst Du die @font-face Einträge auch vor dem CSS Reset machen. Den <link rel="preload"> (der in unserem Wiki kaum erwähnt wird 😟) kannst Du auf jeden Fall als erstes machen.

Wenn es wirklich SCHNELL gehen muss und Du die erforderliche Kontrolle über die HTTP Antwort hast, dann überlege, den HTTP-Header Link für die Preload-Anforderung zu verwenden. Im Wiki erwähnt und bei MDN steht ein Beispiel. Das <link rel="stylesheet"> Element brauchst Du im Dokument aber immer noch.

Bedenke dabei aber, dass die Anzahl von Requests, die der Browser gleichzeitig absetzt, begrenzt ist. Viele Preloads können andere Requeste ausbremsen.

Übrigens werden CSS-Reset heute eher überschätzt. Etliche Autoren im Netz empfehlen mittlerweile Jen Simmons' remedy.css: https://github.com/jensimmons/cssremedy

Rolf

[Gunnar Bittersmann]

@@Rolf B

Bedenke dabei aber, dass die Anzahl von Requests, die der Browser gleichzeitig absetzt, begrenzt ist. Viele Preloads können andere Requeste ausbremsen.

Genau. Alles priorisiert heißt nichts priorisiert.

Übrigens werden CSS-Reset heute eher überschätzt.

Wurden sie das nicht schon immer?

Etliche Autoren im Netz empfehlen mittlerweile Jen Simmons' remedy.css: https://github.com/jensimmons/cssremedy

Das sieht brauchbar aus.

🖖 Live long and prosper

[Matinee]

Hallo Rolf,

da Du keine @font-face Angaben resetten kannst, kannst Du die @font-face Einträge auch vor dem CSS Reset machen. Den <link rel="preload"> (der in unserem Wiki kaum erwähnt wird 😟) kannst Du auf jeden Fall als erstes machen.

Ich dachte halt, weil man beim font-face neben dem frei wählbaren Namen und src-Quelle auch verschiedene Angaben wie font-weight, font-style (und wer weiß, was sonst noch alles, später vielleicht mal...) machen kann. Aber wenn da wirklich keine Stylings erfolgen können, die betroffen sein könnten vom Reset... Mein CSS-Reset ist jetzt nicht ewig lang, aber schon etwas länger und bislang habe ich es nicht bereut. Gerade für einen Laien ist es u.U. verwirrend und man recherchiert dann herum, bis man drauf kommt, dass etwas vom Browser "automatisch" gestylt wird, woran man als Gelegenheitsarbeiter nicht denkt.

Wenn es wirklich SCHNELL gehen muss und Du die erforderliche Kontrolle über die HTTP Antwort hast, dann überlege, den HTTP-Header Link für die Preload-Anforderung zu verwenden. Im Wiki erwähnt und bei MDN steht ein Beispiel. Das <link rel="stylesheet"> Element brauchst Du im Dokument aber immer noch.

Na ja, insgesamt dürften die Seiten relativ schnell sein, da nur ein (allerdings langes) Stylesheet existiert und keine Datenbank mehr dabei ist. Nur ein Vanilla-JS am Ende der Seiten für die beiden Menüs. Die Artikelseiten selbst haben mitsamt der Bilder aber schon ein paar hundert KB.

Das mit dem HTTP-Header-Link ist mir etwas zu kompliziert und werde ich im Gedächtnis behalten, aber erst mal ohne probieren. Wenn nötig, dann kann ich es noch ergänzen. Aber danke für den Hinweis.

Bedenke dabei aber, dass die Anzahl von Requests, die der Browser gleichzeitig absetzt, begrenzt ist. Viele Preloads können andere Requeste ausbremsen.

Tja, was sind viele. Es geht um drei Schriftarten mit je 2 bis 4 Dateien (z.B. regular, bold und italic), die im woff2 offenbar so um die 30-35KB jeweils haben. Ich habe gestern noch einen Artikel gefunden, da wird empfohlen, nur die above the fold benötigten Dateien per preload zu laden. Das klingt sinnvoll, wobei das je nach responsivem Viewport ja etwas unterschiedlich ist.

Immer als Erstes ist die Headergrafik zu sehen, die immer ganz oben ist, egal, welcher Viewport. Danach kommen Navs, h1, TOC; alle drei mit unterschiedlichen fonts. Was man davon above the fold sieht, ist unterschiedlich.

---

Grüße,

Matinee

[Gunnar Bittersmann]

@@Matinee

Tja, was sind viele. Es geht um drei Schriftarten mit je 2 bis 4 Dateien (z.B. regular, bold und italic), die im woff2 offenbar so um die 30-35KB jeweils haben. Ich habe gestern noch einen Artikel gefunden, da wird empfohlen, nur die above the fold benötigten Dateien per preload zu laden. Das klingt sinnvoll, wobei das je nach responsivem Viewport ja etwas unterschiedlich ist.

Und je nach Seiteninhalt unterschiedlich.

Was vermutlich sinnvoll ist: Nur die Normalschnitte per preload laden. Dann wird der Großteil des Textes gleich richtig gerendert; Fett- und Kusivschrift wird erstmal vom Browser gefaket.

Innerhalb weniger Sekunden oder i.d.R. in Bruchteilen davon, wenn die anderen Fonts geladen wurden, wird der Text mit den richtigen Schriftschnitten neu gerendert. Im Idealfall ändern sich dadurch keine Zeilenumbrüche, sodass Nutzer davon kaum was mitbekommen.

🖖 Live long and prosper

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Was vermutlich sinnvoll ist: Nur die Normalschnitte per preload laden. Dann wird der Großteil des Textes gleich richtig gerendert; Fett- und Kusivschrift wird erstmal vom Browser gefaket.

Innerhalb weniger Sekunden oder i.d.R. in Bruchteilen davon, wenn die anderen Fonts geladen wurden, wird der Text mit den richtigen Schriftschnitten neu gerendert. Im Idealfall ändern sich dadurch keine Zeilenumbrüche, sodass Nutzer davon kaum was mitbekommen.

Beim Tagesspiegel haben wir die Font-Dateien zum schnellen Laden noch kleiner gemacht: subsetting.

Es gibt jeweils <font-name>-basic.woff2-, <font-name>-extended.woff2- und <font-name>-other.woff2-Dateien. Welche Zeichen jeweils in basic und extended enthalten sind, ist auf Slide 14 zu sehen.

Solange ein Text außer deutschen Umlauten und é (wegen „Café“) keine Buchstaben mit diakritischen Zeichen enthält, werden nur die basic-Varianten geladen.

Enthält ein Artikel (Beispiel) Namen mit mit diakritischen Zeichen, wird außerdem die hierzu benötigte extended-Datei geladen (aber eben nur dann). Nur in sehr seltenen Fällen wird eine other-Datei geladen.

Slide 18 zeigt, wie die Dateien im Stylesheet referenziert werden. Und dass nur die basic als Preload angegeben sind – und da auch nur der Normalschnitt. (Beim Tagesspiegel von der Abril Display auch der fette Schnitt, weil er in allen Überschriften vorkommt.)

So kriegt man performantes Rendern ohne „Zwiebelfische“ hin.

🖖 Live long and prosper

PS: Die Forumsoftware hindert mich immer noch daran, Postings wie dieses normal abzuschicken. Kann das mal bitte behoben werden?

[Rolf B]

Hallo Matinee,

ein Nachtrag: Wenn Du ernsthafte Probleme mit dem Flash of Unstyled Text (FOUT) hast, solltest Du auch überlegen, ob Du zu viele oder zu große Webfonts einbindest. Insbesondere bei Google Fonts (die man eh selbst hosten soll) loht ein Blick in die @font-face Definitionen und ein Ausmisten unnötiger Sprachversionen.

Wenn Du dann preload eingebaut hast, prüfe bitte im Netzwerk-Teil der Developer Tools, ob der Preload sich tatsächlich bis auf die WOFF-Dateien durchzieht oder nur die CSS-Datei mit den Deklarationen vorgeladen wird. Ich habe nämlich irgendwo im Kleinhirn die Ahnung, dass der Browser eine Font-Datei nur lädt, wenn die dafür gelisteten Codepoints im Dokument auch verwendet werden.

Rolf

[Matinee]

Hallo Rolf,

ein Nachtrag: Wenn Du ernsthafte Probleme mit dem Flash of Unstyled Text (FOUT) hast, solltest Du auch überlegen, ob Du zu viele oder zu große Webfonts einbindest. Insbesondere bei Google Fonts (die man eh selbst hosten soll) loht ein Blick in die @font-face Definitionen und ein Ausmisten unnötiger Sprachversionen.

Ich konvertiere jede Datei in woff und woff2 auf fontsquirrel und binde aber wirklich nur die benötigten ein (regular, italic, bold, semibold sind max. vier bei einer Schriftart, bei der zweiten regular, bold und semibold, bei der dritten nur regular und bold).

Im font-face wird dann primär woff2 genannt und sekundär woff als Fallback. Das ist wohl das übliche und sinnvolle Vorgehen.

Wenn Du dann preload eingebaut hast, prüfe bitte im Netzwerk-Teil der Developer Tools, ob der Preload sich tatsächlich bis auf die WOFF-Dateien durchzieht oder nur die CSS-Datei mit den Deklarationen vorgeladen wird. Ich habe nämlich irgendwo im Kleinhirn die Ahnung, dass der Browser eine Font-Datei nur lädt, wenn die dafür gelisteten Codepoints im Dokument auch verwendet werden.

Da erinnert sich dein Kleinhirn wahrscheinlich richtig, ich habe gestern auch etwas in der Richtung gelesen und mich noch gewundert, aber die fonts werden im Regelprocedere wohl tatsächlich nur bei aktuellem, tatsächlichen Bedarf des Users geladen und nicht automatisch mit der ganzen Seite. War mir auch neu, ist aber ja kein Nachteil.

Eins fällt mir noch ein, was ich gelesen haben und offenbar wichtig ist: Man soll unbedingt woff2 als primäre Alternative angeben und nur woff2-Dateien dann preloaden. Ich habe es nicht im Detail verstanden, aber so wie die Browser arbeiten kann es sonst zu deutlichen Verzögerungen kommen.

---

Grüße,

Matinee

[Gunnar Bittersmann]

@@Matinee

Ich konvertiere jede Datei in woff und woff2 auf fontsquirrel […] Im font-face wird dann primär woff2 genannt und sekundär woff als Fallback. Das ist wohl das übliche und sinnvolle Vorgehen.

Nein. WOFF ist nicht sinnvoll. Browser, die WOFF2 nicht unterstützen, gibt es nicht mehr.

Und falls doch einer von tausenden mit solch einem veraltenen Browser ankommen sollte, sind nicht geladene Webfonts wohl das geringste Problem.

Also: WOFF2 und sonst gar nichts. (Und schon gar nicht OTF, SVG u.dgl.)

🖖 Live long and prosper

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Also: WOFF2 und sonst gar nichts. (Und schon gar nicht OTF, SVG u.dgl.)

Zurückgeblättert: Letzteres war auch schon 2018 so. ☞ FOIT, FOUT, FUCK^[1][2], Slide 2.

Und gleich danach hatte ich erklärt, was die Abkürzung WOFF bedeutet. (Slide 3) 😉

🖖 Live long and prosper

---

1. Beim Titel macht sich wohl der Einfluss von Heydon Pickering bemerkbar. 😆 ↩︎

2. Und schon wieder musste ich den Codepoint von n raussuchen. 😡 Kann mal bitte jemand diesem Schwachsinn ein Ende machen? ↩︎

[Matinee]

@@Matinee

Ich konvertiere jede Datei in woff und woff2 auf fontsquirrel […] Im font-face wird dann primär woff2 genannt und sekundär woff als Fallback. Das ist wohl das übliche und sinnvolle Vorgehen.

Nein. WOFF ist nicht sinnvoll. Browser, die WOFF2 nicht unterstützen, gibt es nicht mehr.

Besagt caniuse denn nicht, dass es noch 3,6% gibt? Wäre auch nur ein Fallback, der selten zum Einsatz kommt. Was schadet es da, wenn man die zweite Zeile für woff im font-face-Code einfügt?

P.S. an Matthias: Warum werden Forenlinks eigentlich im gleichen Tab geöffnet, wäre es nicht besser in einem neuen?

---

Grüße,

Matinee

[Rolf B]

Hallo Matinee,

mit WOFF hatte ich natürlich WOFF2 gemeint. WOFF habe ich für mich gestrichen.

Wegen der 3,6% bei Caniuse: man weiß nicht,

(a) wie gut die Caniuse Statistiken sind und
(b) welche Browser die nicht unterstützten sind (denn wenn ich die roten Felder aufaddiere, bleibe ich unter 0,5% und 0,44% davon kommen vom IE).

Der Grundsatz lautet: Eine Webseite muss auf jedem Gerät darstellbar sein. Sie muss nicht auf jedem Gerät gleich aussehen. Wenn deine Seite mit den Default-Fonts nicht schick ist, aber lesbar, dann ist das okay.

Sonderfall: Wenn Du FontAwesome benutzt und einen speziellen Icon-Font verwendest. Ohne diesen wäre deine Seite vermutlich unbedienbar. Hier wären dann title-Attribute pro Schaltfläche eine Krücke, aber auch nicht toll. Weshalb Icon-Fonts ein Bedienbarkeitsrisiko darstellen.

Wegen Forum: Könnte man machen, ist aber letztlich ein "Know your Browser" Thema: mit rechter Maustaste klicken und "Link in neuem Tab öffnen" (auf Mobilgeräten durch long tap).

Rolf

[Matinee]

Hallo Rolf,

danke für deine und Gunnars Beiträge.

mit WOFF hatte ich natürlich WOFF2 gemeint. WOFF habe ich für mich gestrichen.

Wegen der 3,6% bei Caniuse: man weiß nicht,

(a) wie gut die Caniuse Statistiken sind und
(b) welche Browser die nicht unterstützten sind (denn wenn ich die roten Felder aufaddiere, bleibe ich unter 0,5% und 0,44% davon kommen vom IE).

O.K., dann nehme ich auch nur woff2. In den meisten YT-Videos und Web-Artikeln zum Thema werden beide im CSS vermerkt, aber die sind meistens auch 2 bis 3 Jahre alt.

Wenn ich dich und Gunnar richtig verstehe, ist der Ort für font-face im Stylesheet also egal. Da in meinem Stylesheet gleich nach dem CSS-Reset die allgemeinen Basisstyles kommen und dort als Erstes einige Schrift-Styles, werde ich alle font-face-Blöcke dort notieren. Diese "Definitionen" aller Schriftdateien gelten dann auch für alle MQ automatisch.

Beim font-face-Code ist mir aufgefallen, dass nicht alle, aber die meisten Quellen zu diesem Thema (Websites im Web, YT-Videos, auch Selfhtml-Wiki) für die Werte beim font-face nicht die doppelten Anführungszeichen, sondern die einfachen nehmen, also die kleinen, geraden Striche. Auf meiner Tastatur sind die bei der Raute. Ich kenne im CSS eigentlich immer nur die doppelten, z.B. beim Referenzieren der Bilder oder bei grid-template-areas. Ist da bei font-face etwas anders?

Das Preload beträfe bei mir drei Schriftdateien, wenn ich nach dem Krierium "was ist above the fold" gehe. Nehme ich alle regular-Dateien, wie Gunnar vorschlägt, wären es auch drei. Google scheint auf "above the fold" zu achten. Ich vermute, drei sind noch nicht zu viel?

Google PageSpeed scheint großen Wert auf während des Ladens stets sichtbaren Text zu legen. "Ensure text remains visible during webfont load" und "Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading" sind Meldungen, mit denen sich offenbar viele Webmaster rumschlagen.

Wäre in meinem Szenario mit insgesamt 9 selbst gehosteten Schriftdateien plus preload die Nutzung von font-display zusätzlich sinnvoll? Und wenn ja, mit was, swap oder optional?

---

Grüße,

Matinee

[Rolf B]

Hallo Matinee,

die Anführungszeichen können einfach oder doppelt sein, Hauptsache paarig.

Rolf

[Gunnar Bittersmann]

@@Rolf B

die Anführungszeichen können einfach oder doppelt sein, Hauptsache paarig.

… und die in diesem Kontext richtigen Anführungszeichen: ' oder ", nicht „/“/”. 😎

🖖 Live long and prosper

[MudGuard]

Hi,

… und die in diesem Kontext richtigen Anführungszeichen: ' oder ",

hattest Du nicht neulich erst behauptet, daß das gar keine Anführungszeichen sind? 😀

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

… und die in diesem Kontext richtigen Anführungszeichen: ' oder ",

hattest Du nicht neulich erst behauptet, daß das gar keine Anführungszeichen sind? 😀

Ja, sind’s ja auch nicht. In diesem Kontext sind es string delimiters. Zu deutsch: Zeichenkettenbegrenzungszeichen.

Aber ich wollte hier nicht unnötig Unruhe stiften. 😊

🖖 Live long and prosper

[Gunnar Bittersmann]

@@Matinee

P.S. an Matthias: Warum werden Forenlinks eigentlich im gleichen Tab geöffnet, wäre es nicht besser in einem neuen?

Nein. Auf gar keinen Fall.

Wie Jakob Nielsen sagt: “Opening up new browser windows is like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer’s carpet. Don’t pollute my screen with any more windows, thanks.”

Wenn du das willst, dann nutze das Kontextmenü (wie @Rolf B schon sagte) oder stell dir das in deinen persönlichen Einstellungen (oben im Menü zu finden) so ein.

🖖 Live long and prosper

[MudGuard]

Hi,

Wenn du das willst, dann nutze das Kontextmenü (wie @Rolf B schon sagte)

in vielen Browsern geht auch Klick mit gleichzeitig gehaltener Ctrl- oder Command-Taste.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@Matinee

Ich konvertiere jede Datei in woff und woff2 auf fontsquirrel […] Im font-face wird dann primär woff2 genannt und sekundär woff als Fallback.

Besagt caniuse denn nicht, dass es noch 3,6% gibt?

Rolf hat ja schon die Mathematik betrieben und die roten Boxen zusammenaddiert. Da bleiben noch etliche Prozente, die sich wohl auf übrige, nicht namentlich erwähnte Browser beziehen. Welche Relevanz haben die in Bezug auf deine Zielgruppe?

Oder nehmen wir Opera Mini, der gar keine Webfonts unterstützt. In einigen Teilen der Welt hat der als sparsamer Browser durchaus seine Verbreitung. Hierzulande wohl eher gar nicht.

Und es mag noch andere Browser geben, die WOFF2 nicht unterstützen, aber auch WOFF nicht. Für die also die zusätzliche Bereitstellung von WOFF keinerlei Mehrwert bringt.

Da bleibt dann nur ein Bruchteil eines Prozents übrig an Browsern, die WOFF können, aber WOFF2 nicht.

Was schadet es da, wenn man die zweite Zeile für woff im font-face-Code einfügt?

Es ist den Aufwand nicht wert, die WOFF-Dateien zu erstellen und auf den Server zu schieben.

Jetzt, wo du das einmal gemacht hast, musst du natürlich auch keinen Aufwand betreiben, die Referenzen zu den WOFF-Dateien aus dem Stylesheet zu löschen; es ist ja nicht falsch (solange du die Reihenfolge richtig hast und so gut wie immer die WOFF2-Dateien geladen werden).

In Zukunft: nur noch WOFF2.

🖖 Live long and prosper

[Matinee]

Hallo Gunnar,

Rolf hat ja schon die Mathematik betrieben und die roten Boxen zusammenaddiert. Da bleiben noch etliche Prozente, die sich wohl auf übrige, nicht namentlich erwähnte Browser beziehen. Welche Relevanz haben die in Bezug auf deine Zielgruppe?

Vermutlich keine große. Meine Zielgruppe sind keine technikaffinen Menschen, aber vermutlich etwas mehr von denen, die Barrierefreiheit brauchen und evtl. solche spezielleren Geräte wie screenrader nutzen. Kann es nicht genauer sagen.

Oder nehmen wir Opera Mini, der gar keine Webfonts unterstützt.

Sowas gibt's?

Und es mag noch andere Browser geben, die WOFF2 nicht unterstützen, aber auch WOFF nicht. Für die also die zusätzliche Bereitstellung von WOFF keinerlei Mehrwert bringt.

Da bleibt dann nur ein Bruchteil eines Prozents übrig an Browsern, die WOFF können, aber WOFF2 nicht.

Was schadet es da, wenn man die zweite Zeile für woff im font-face-Code einfügt?

Es ist den Aufwand nicht wert, die WOFF-Dateien zu erstellen und auf den Server zu schieben.

Jetzt, wo du das einmal gemacht hast, musst du natürlich auch keinen Aufwand betreiben, die Referenzen zu den WOFF-Dateien aus dem Stylesheet zu löschen; es ist ja nicht falsch (solange du die Reihenfolge richtig hast und so gut wie immer die WOFF2-Dateien geladen werden).

Ich habe nur noch woff2 angelegt.

Was denkst du zu den vermutlich drei Schriftdateien, die ein preload bekommen werden. Das ist noch nicht zu viel, oder? Im Zweifelsfall mache ich das einfach mal und wenn das Wasserfall-Diagramm mir keine roten Balken/Ausrufezeichen ins Gesicht schleudert und das Laden auffällig dauert, wird es wohl passen. Eine einfache, immer richtige Antwort gibt es da vermutlich nicht. Manche Quellen sagen "max. 1 oder 2", andere "nur die, die above the fold auftauchen", was aber desktop schon mehrere sein können.

Wie im gestrigen post von 11:57 Uhr erwähnt, sollte man Google PageSpeed nicht aus dem Auge verlieren. Google mag es wohl gar nicht, wenn während des Ladens zeitweise kein Text zu sehen ist und kennt einige Werte (LCP und FCP), die von Webfonts berührt werden.

Falls es mich trotz sicher sinnvollen preloads betreffen sollte, könnte "font-display" helfen? Würde es aber erst mal "ohne" probieren wollen, nur mit preload. Wahrscheinlich reicht das, denke ich. Kann es aber erst probieren, wenn alles online ist.

---

Grüße,

Matinee

[Gunnar Bittersmann]

@@Matinee

Hallo,

ist es egal oder doch von Vorteil, die @font-face-Blöcke für die eingebetteten Schriften gleich als Erstes im Stylesheet zu notieren?

Wenn besser zu Beginn, dann nach dem CSS-Reset, das ja üblicherweise als Erstes kommt?

AFAIK blockt das Laden und Parsen von Stylesheets das Rendern der Seite. Das heißt: CSS wird nicht parallel zum HTML ausgewertet, sondern in Gänze mittendrin an der Stelle, wo die Referenz im HTML steht.

Die Reihenfolge der Regeln im Stylesheet hat auf die Performanz also keinen Einfluss.

🖖 Live long and prosper

[Rolf B]

Hallo Gunnar,

ja, aber WOFF2 Files sind kein Stylesheet. Der Browser stoppt also das Rendern während er die @font-face Regeln lädt, macht dann aber weiter und lädt die WOFFs im Hintergrund. Glaube ich…

Man kann aber für die wichtigsten Font-Dateien einen Font-Preload anfordern.

<link rel="preload" as="font" href="/fonts/xyz.woff2" />

Rolf

[Gunnar Bittersmann]

@@Rolf B

ja, aber WOFF2 Files sind kein Stylesheet. Der Browser stoppt also das Rendern während er die @font-face Regeln lädt, macht dann aber weiter und lädt die WOFFs im Hintergrund. Glaube ich…

Der Browser lädt Webfonts, wenn er sie braucht.^[1] Also erst nach dem Laden und Parsen des (der) gesamten Stylesheets, wenn er wieder dabei ist, die Seite zu rendern.

Wo also die @font-face-Regeln im Stylesheet stehen, sollte für die Performanz irrelevant sein.

Man kann aber für die wichtigsten Font-Dateien einen Font-Preload anfordern.

Yep. Und wie gesagt: nur für die wichtigsten.

🖖 Live long and prosper

---

1. Nachtrag: d.h. der Browser lädt Webfonts nicht dann, wenn er im Stylesheet @font-face-Regeln findet, sondern erst dann, wenn er feststellt, dass auf der Seite Text vorkommt, der per Styleangabe in einem Webfont gesetzt werden sollte. ↩︎

[Rolf B]

Hallo Gunnar,

sondern erst dann, wenn er feststellt, dass auf der Seite Text vorkommt, der per Styleangabe in einem Webfont gesetzt werden sollte

Genau hier bin ich unsicher. Die Google-Fonts werden ja nicht nur nach Schriftschnitt, sondern auch nach Codepoints getrennt. Es gibt eine Font-Datei für Normal-Latin, eine für Italic-Cyrillic, etc.

Ich kann's gerade nicht ausprobieren. Wenn ich zwei @font-face Definitionen habe, eine für die Latin-Codepoints und eine für die Cyrillic-Codepoints, und auf meiner Seite kein einziges kyrillisches Zeichen habe, sollte er dann die Font-Datei mit den kyrillischen Glyphen laden?

Rolf

[Gunnar Bittersmann]

@@Rolf B

Ich kann's gerade nicht ausprobieren. Wenn ich zwei @font-face Definitionen habe, eine für die Latin-Codepoints und eine für die Cyrillic-Codepoints, und auf meiner Seite kein einziges kyrillisches Zeichen habe, sollte er dann die Font-Datei mit den kyrillischen Glyphen laden?

Nein, sollte er nicht. Tut er auch nicht.

Siehe dieses Posting. (Und dortiges PS!)

🖖 Live long and prosper