Welchen Sprachausbau für Webfont

[[Mitglied Micr…]]

Ich habe für die Website eines Kunden gerade einige Schnitte der PT Serif Pro Narrow erworben und frage mich nun welche Version sich für die deutschsprachige Website anbietet. Im Zweifelsfall doch Latin Extended oder? Oder wäre auch Multilingual & OT Features nutzbar? Die OT Features wären eventuell ganz hilfreich sofern man im Web auf die zugreifen kann. Ich kenne mich im Bereich Webfonts leider gar nicht aus ...

 

 

[Ralf Herrmann]

So pauschal lässt sich das nicht beantworten. Hängt erstens natürlich davon ab, was auf der Website erscheinen wird (z.B. osteuropäische Namen?, Kapitälchen-Ansprache etc.). Und letztlich muss einfach abgewogen werden, ob der entsprechende Ballast gerechtfertigt ist. Man müsste also konkret prüfen, wie groß die Webfont-Pakete sind und wie sehr sie Auslieferung der Website verzögern. Das kann gegebenenfalls entscheidend sein. Google macht hier in den letzten Jahren ziemlichen Druck und Webfonts könnten im Zweifel dazu führen, dass das Suchmaschinen-Ranking leidet, weil die Website einfach zu langsam lädt. Also kurzum: eigentlich müssten das die Webdesigner im Gesamtkontext der Website-Gestaltung testen und entscheiden. 

[[Mitglied Micr…]]

Danke für die Info.

 

Dann lade ich mal die verschiedenen Versionen und stimme mich mit dem Programmierer ab. Die Ansprache von OT-Features wäre wichtig, da in der Standardbelegung die Tabellenziffern drin sind die ich gerne durch normale Versalziffern ersetzen möchte. Osteuropäische Namen wird es auch öfter geben ...

[[Mitglied Micr…]]

Gerade geschaut:

 

Latin Extended (Variante 1)

Enthält 368 Zeichen und ist als woff2 28 kb groß. 

 

Latin Extended (Variante 2)

Enthält 369 Zeichen und ist als woff2 28 kb groß. 

 

Multilingual (Variante 1)

Enthält 1390 Zeichen und ist als woff2 65 kB groß.

 

Multilingual (Variante 2)

Enthält 1390 Zeichen und ist als woff2 82 kB groß.

 

Desktop Compatible

Enthält 1390 Zeichen und ist als woff2 62 kB groß.

 

[[Mitglied D2C…]]

vor 2 Stunden schrieb Microboy:

Oder wäre auch Multilingual & OT Features nutzbar? Die OT Features wären eventuell ganz hilfreich sofern man im Web auf die zugreifen kann. Ich kenne mich im Bereich Webfonts leider gar nicht aus ...

Mittlerweile werden OT-Features im Web auf breiter Ebene unterstützt. Du kannst davon ausgehen, dass grundlegende Features wie Tabellen- oder Mediävalziffern und Kapitälchen wie gewünscht angezeigt werden, wenn das CSS korrekt geschrieben ist.

[[Mitglied Micr…]]

Danke auch für diese Info. Dann wird es wohl auf eine der Varianten mit OT-Features hinauslaufen ...

[[Mitglied R::b…]]

Und wenn Ihr Euch bzgl. Dateigrößen, Sprachunterstützung, Google etc. noch unsicher seid, könntet Ihr ja auch erstmal mit sprachbegabten Freefonts wie Noto oder Fira eine Testphase starten, bevor Ihr die Lizenzierung vollzieht.

[[Mitglied Micr…]]

Die Schrift ist fix da sie bereits in Print-Produkten des Kunden zum Einsatz kommt und es ging wirklich nur um die Auswahl der Sprachabdeckung. Gekauft ist das Web-Paket bereits ...

[[Mitglied mark…]]

Dieses Thema beschäftigt mich gerade. Ich sehe viele Webseiten, die aus aktuellem Anlass Informationen auf ukrainisch anbieten, und der kyrillische Zeichensatz fehlt und wird ersetzt – obwohl die Schrift diesen hätte. (Beispiel: voebb.de mit PT Sans).  Sind diese paar KB Speicher-Unterschied wirklich so gewaltig bei der Ladezeit?

 

Gerade öffentliche Institutionen, die im Gegensatz zu Unternehmen nicht unter großem Konkurrenzdruck stehen und nicht so sehr SEO-abhängig sind, sollten doch wohl den kompletten Language-Support anbieten ... Oder wie seht Ihr das?

 

[[Mitglied Seba…]]

Kurze Antwort

Die paar Kilobyte zusätzlich sind kein Problem – einfach machen.

 

Lange Antwort

Die paar Kilobyte zusätzlich für einen weiter ausgebauten Font sind in der Regel (in Mitteleuropa) kein Problem. Insbesondere handelt es sich dabei nicht um eine weitere Anfrage beim Server (Kontaktanfrage, Kontaktantwort, Daten anfordern, Daten liefern) sondern um die selbe Anfrage, die nur ein bisschen mehr Daten überträgt. Das ist nur ein kleiner Teil des ganzen Prozesses der da aufgeschlagen wird.

Klar kann man sagen "jetzt haben wir aber 47% mehr font-Daten" und das klingt dann schlimm, aber Fonts sind in Relation zu anderen geladenen Daten recht klein, und es lohnt sich fast immer viel mehr, seine Bilder gerätespezifisch, inhaltsbezogen und mit modernen Dateiformaten auszuliefern, als sich zu sehr über die Fonts gedanken zu machen. Da ist dann oft in einem einzigen Bild das nicht optimal komprimiert oder viel zu groß ist viel mehr verschwendet, als ein Font jemals einsparen könnte. Ich kenne eigentlich keine reguläre Webseite die bereits so hochoptimiert ist, als dass die paar KB an Font-Daten irgend einen Unterschied machen könnten (Facebook und Google machen so Zeug, aber aus ganz anderen Gründen, da sind dann plötzlich auch die Server weniger beschäftigt, die zu übertragenden Datenmengen nach außen reduziert, etc.).

Um das Google-Ranking zu beruhigen ("First contentfull paint" / "Largest contentful paint"), kann man die wenigen Fonts, Bilder, CSS, etc., die beim ersten Aufruf einer Seite als erstes erscheinen werden, auch ganz gezielt als erstes laden und rendern lassen ("above the fold"), und alles was außerhalb des Bildschirms geschieht (weitere Fonts, Bilder, ...), erst hinterher. Da muss man dann ein wenig in die Technik schauen, in welcher Reihenfolge was wie vom Browser geladen wird, und was ihn zur Anzeige der ersten Inhalte noch aufhält, und diese Hindernisse aus dem Weg räumen – aber damit lässt sich eine Starsteite oft "schnell" machen, ohne irgendwas an der geladenen Datenmenge an sich zu verändern.

[[Mitglied mark…]]

vor einer Stunde schrieb Sebastian Nagel:

Kurze Antwort

Die paar Kilobyte zusätzlich sind kein Problem – einfach machen.

 

Lange Antwort

Die paar Kilobyte zusätzlich für einen weiter ausgebauten Font sind in der Regel (in Mitteleuropa) kein Problem. Insbesondere handelt es sich dabei nicht um eine weitere Anfrage beim Server (Kontaktanfrage, Kontaktantwort, Daten anfordern, Daten liefern) sondern um die selbe Anfrage, die nur ein bisschen mehr Daten überträgt. Das ist nur ein kleiner Teil des ganzen Prozesses der da aufgeschlagen wird.

Klar kann man sagen "jetzt haben wir aber 47% mehr font-Daten" und das klingt dann schlimm, aber Fonts sind in Relation zu anderen geladenen Daten recht klein, und es lohnt sich fast immer viel mehr, seine Bilder gerätespezifisch, inhaltsbezogen und mit modernen Dateiformaten auszuliefern, als sich zu sehr über die Fonts gedanken zu machen. Da ist dann oft in einem einzigen Bild das nicht optimal komprimiert oder viel zu groß ist viel mehr verschwendet, als ein Font jemals einsparen könnte. Ich kenne eigentlich keine reguläre Webseite die bereits so hochoptimiert ist, als dass die paar KB an Font-Daten irgend einen Unterschied machen könnten (Facebook und Google machen so Zeug, aber aus ganz anderen Gründen, da sind dann plötzlich auch die Server weniger beschäftigt, die zu übertragenden Datenmengen nach außen reduziert, etc.).

Um das Google-Ranking zu beruhigen ("First contentfull paint" / "Largest contentful paint"), kann man die wenigen Fonts, Bilder, CSS, etc., die beim ersten Aufruf einer Seite als erstes erscheinen werden, auch ganz gezielt als erstes laden und rendern lassen ("above the fold"), und alles was außerhalb des Bildschirms geschieht (weitere Fonts, Bilder, ...), erst hinterher. Da muss man dann ein wenig in die Technik schauen, in welcher Reihenfolge was wie vom Browser geladen wird, und was ihn zur Anzeige der ersten Inhalte noch aufhält, und diese Hindernisse aus dem Weg räumen – aber damit lässt sich eine Starsteite oft "schnell" machen, ohne irgendwas an der geladenen Datenmenge an sich zu verändern.

Super, vielen Dank für die ausführliche Erklärung!