2025-07-02 · Redaktion Baduno · 8 blog.readMin · Blog & Wissen
Webfonts für 24 Sprachen: Schriftwahl, Subsetting, Performance
Eine Schrift, die Deutsch, Griechisch, Maltesisch und Arabisch trägt? Gibt es selten – und wenn, dann schwer. Strategien für schnelle, schöne Mehrsprachigkeit.
Das Abdeckungsproblem
Lateinisch mit allen EU-Diakritika, Griechisch, Kyrillisch, dazu arabische Schrift: Kaum eine Schriftfamilie deckt alles gut ab. Die pragmatische Lösung sind Schriftpaare – eine Latein/Griechisch/Kyrillisch-Familie plus eine spezialisierte RTL-Schrift, aufeinander abgestimmt in Grauwert und Höhe.
Subsetting spart massiv
Vollständige Unicode-Fonts wiegen hunderte Kilobyte. Subsets pro Schriftsystem – geladen nur, wo gebraucht – reduzieren das auf Bruchteile: Die RTL-Fassung lädt die RTL-Schrift, die deutsche nicht.
Laden ohne Springen
font-display:swap zeigt sofort Text mit Systemschrift und tauscht dann – gegen Layout-Sprünge helfen metrisch kompatible Fallbacks und size-adjust. Selbst gehostet statt vom Fremd-CDN: schneller und datenschutzfreundlicher.
Typografie je Schriftsystem
Arabische Schrift braucht mehr Zeilenhöhe und oft einen Punkt mehr Grad; Versal-Spationierung funktioniert nur lateinisch. Ein Design-System, das solche Regeln je Schriftsystem kennt, macht aus 24 Sprachen ein Layout – statt 25 Kompromisse.
Variable Fonts: Flexibilität mit Hürden
Variable Fonts versprechen eine reduzierte Dateianzahl, indem mehrere Schnitte (fett, kursiv etc.) in einer Datei gebündelt werden. Für mehrsprachige Seiten mit 24 Sprachen ist das verlockend: Statt 24 × 4 = 96 statischen Dateien nur 24 variable? Doch Vorsicht: Variable Fonts mit breitem Sprachumfang (Latein, Griechisch, Kyrillisch, Arabisch) sind selten und oft groß. Subsetting wird zudem komplexer, da die Variationsachsen den Zeichensatz beeinflussen. Ein subsettierter variabler Font kann je nach Achsenausprägung andere Glyphen benötigen, sodass Sie entweder alle Subsets vorhalten oder dynamisch generieren müssen. Praktikabel ist der Einsatz variabler Fonts für eine Schriftsystem-Familie (z. B. Latein + Griechisch) und statischer Fonts für das andere (z. B. Arabisch), um die Dateigröße zu kontrollieren. Laden Sie variable Fonts per font-weight: 100 900 und font-stretch: 75% 125% aus, statt einzelner Schnitte – aber testen Sie die Darstellung in allen Sprachen und Browsern, da variable Fonts bei Subsetting und Rasterung manchmal unerwartete Ergebnisse liefern.
Lizenzkonforme Schriftnutzung in 24 Sprachen
Die rechtliche Seite wird oft unterschätzt. Eine Schriftlizenz gilt meist für eine bestimmte Anzahl von Webseitenaufrufen oder für eine Domain; bei 24 Sprachvarianten können Sie je nach Lizenz schon an Grenzen stoßen. Manche Anbieter verbieten explizit das Subsetting oder die Einbettung in dynamische Inhalte. Achten Sie darauf, dass die Lizenz alle Sprachen abdeckt – insbesondere Sonderzeichen wie türkisches İ, rumänisches Ș oder maltesisches Ħ gelten oft als erweiterter Zeichensatz und sind nicht immer im Standardpaket enthalten. Für EU-Projekte empfiehlt sich eine Unlimited- oder Enterprise-Lizenz, die auch Subsetting und Mehrdomain-Nutzung erlaubt. Prüfen Sie außerdem die Schrift-Lizenz auf Gültigkeit für die von Ihnen verwendete Font-Technologie (z. B. WOFF2). Ein Lizenzberatungs-Tool (z. B. von Fontstand) kann helfen, Konflikte zu vermeiden – notieren Sie die Lizenzbedingungen pro Schriftart in Ihrem Styleguide, damit keine Nachbesserungen nötig werden.
Formatwettbewerb: WOFF2, subsettierte variable Fonts und Unicode-Range
Die Wahl des Dateiformats beeinflusst Ladezeit und Kompatibilität. WOFF2 ist heute Standard und bietet etwa 30-50% bessere Kompression als WOFF. Wenn Sie variable Fonts einsetzen, sollten Sie prüfen, ob Ihr Target-Browser WOFF2 mit variablen Achsen unterstützt (aktuell alle modernen Browser). Für ältere Browser (IE11) müssen Sie statische WOFF-Dateien als Fallback bereithalten. Ein effektiver Trick: Nutzen Sie Unicode-Range im @font-face, um nur den tatsächlich benötigten Zeichensatz zu laden – ähnlich wie Subsetting, aber serverseitig gesteuert. Kombinieren Sie das mit font-display: swap; die Ladeoptimierung können Sie via preload für kritische Schriftvarianten (z. B. Grundschrift für Latein) unterstützen. Ein Praxisbeispiel: Für die deutsche Seite laden Sie nur die Latein+Umlaute-Subset (ca. 30 KB), für die griechische Seite das Latein+Griechisch-Subset (ca. 50 KB), für die arabische Seite das Latein+Arabisch-Subset (ca. 80 KB). So bleiben selbst bei 24 Sprachen die Gesamt-Downloads pro Besucher unter 100 KB Schriftdaten.
Eine Schrift, die Deutsch, Griechisch, Maltesisch und Arabisch trägt? Gibt es selten – und wenn, dann schwer. Strategien für schnelle, schöne Mehrsprachigkeit.
Automatisierte Qualitätssicherung der Schriftdarstellung
Damit in allen 24 Sprachvarianten keine Glyphen fehlen oder zerstückelt wirken, sollten Sie automatisierte Tests in Ihre CI/CD-Pipeline einbauen. Tools wie FontProof, Wakamai Fondue oder der Python-Skript fontdiff vergleichen gerenderte Screenshots jeder Sprachversion mit einem Referenz-Screenshot. Oder Sie nutzen Puppeteer, um jede Seite zu öffnen, die Schrift zu laden und auf Lücken zu prüfen (über die CSS-Eigenschaft font-family: …; font-unicode-range). Noch systematischer: Extrahieren Sie alle im HTML vorkommenden Unicode-Codepoints pro Sprachversion und gleichen Sie sie mit den im Subset vorhandenen Glyphen ab. Fehlt ein Zeichen, wird der Build abgebrochen oder eine Warnung ausgegeben. Diese Tests sollten auch die Lesbarkeit von Ligaturen oder alternativen Zeichen (z. B. arabische Initialformen) prüfen. Integrieren Sie zudem einen Performance-Budget-Check: Die Schriftgröße pro Sprache darf einen gewissen Schwellwert nicht überschreiten. So stellen Sie sicher, dass die Mehrsprachigkeit nicht auf Kosten der Ladezeit geht.
KI-gestütztes Subsetting: Effizienz durch Automatisierung mit Qualitätssicherung
Das Subsetting für 24 Sprachen manuell zu verwalten ist aufwendig und fehleranfällig. Moderne Build-Tools wie glyphhanger oder HarfBuzz können anhand der tatsächlich im Content vorkommenden Zeichen automatisch Subsets generieren. Noch effizienter wird der Prozess, wenn Sie KI-Modelle einsetzen, die aus den Sprachversionen die benötigten Unicode-Blöcke vorhersagen. Ein neuronales Netz, trainiert auf multilingualen Webseiten, kann mit hoher Treffsicherheit bestimmen, welche Glyphen für eine bestimmte Sprache erforderlich sind – von lateinischen Basiszeichen über kyrillische Ergänzungen bis hin zu arabischen Ligaturen. Der automatisch erzeugte Subset wird dann einer manuellen Prüfung durch einen Muttersprachler unterzogen, um sicherzustellen, dass keine seltenen, aber wichtigen Zeichen (z. B. historische Zitate, Sonderzeichen in Firmennamen) fehlen. Diese Kombination aus KI-Beschleunigung und menschlicher Kontrolle reduziert die Subset-Erstellung von Tagen auf Stunden bei gleichbleibend hoher Qualität. Integrieren Sie das Skript in Ihre CI/CD-Pipeline, sodass bei jedem Content-Update die Subsets automatisch neu generiert und getestet werden. So stellen Sie sicher, dass Schriftdateien stets auf dem neuesten Stand sind, ohne die Ladeperformance zu beeinträchtigen.
Sprachspezifische Fallback-Strategien für konsistente Typografie
Selbst bei optimalem Subsetting kann es vorkommen, dass eine Schriftdatei nicht geladen wird – ob durch Netzwerkfehler, Browserinkompatibilität oder Lizenzbeschränkungen. Dann greift der Fallback-Stapel. Für 24 Sprachen reicht ein globaler Font-Stack nicht aus: Eine Systemschrift, die für Deutsch gut aussieht, kann für Arabisch ungeeignet sein. Definieren Sie daher pro Sprachversion separate Fallback-Stacks, die auf die typischen Systemschriften der Zielregion abgestimmt sind. Verwenden Sie dafür die CSS-Funktion @font-face mit unicode-range, um für jede Schriftfamilie nur die Zeichen zu laden, die tatsächlich benötigt werden. Für die arabische Version könnten Sie als Fallback 'Traditional Arabic' oder 'Tahoma' angeben, für die griechische 'GFS Didot' oder 'Times New Roman'. Achten Sie auf metrische Kompatibilität: Mittels size-adjust und ascent-override passen Sie die Fallback-Schrift visuell an die Primärschrift an, sodass Layout-Sprünge minimiert werden. Testen Sie diese Fallbacks in allen Sprachen mit einem automatisierten Screenshot-Vergleich, um sicherzustellen, dass die Lesbarkeit auch im Fehlerfall gewahrt bleibt. So vermeiden Sie Überraschungen und sorgen für eine konsistente Benutzererfahrung über alle Sprachvarianten hinweg.
Serverseitige Optimierung: Self-Hosting, Caching und CDN-Strategien
Die Auslieferung von Webfonts über externe Dienste wie Google Fonts oder Adobe Fonts ist bequem, bringt aber Nachteile für mehrsprachige Projekte: Erstens müssen Sie bei 24 Sprachvarianten oft mehrere Anfragen an verschiedene Server stellen, was die Ladezeit erhöht. Zweitens kennen Sie die Caching-Strategie des Anbieters nicht und haben keine Kontrolle über Ausfallzeiten oder Datenschutz. Daher empfehlen wir Self-Hosting aller Schriftdateien auf Ihrem eigenen Server oder einem dedizierten CDN. Durch Self-Hosting können Sie die Schrift-Subsets genau auf Ihre Sprachversionen zuschneiden und mittels HTTP/2 Server Push oder Preload-Hints kritische Schriften priorisieren. Zudem lässt sich das Caching über Cache-Control-Header so steuern, dass die Schriften für alle Besucher einer Sprachversion nur einmal geladen werden. Ein CDN mit Edge-Servern in der Nähe Ihrer Nutzer verkürzt die Latenz. Für 24 Sprachen mit unterschiedlichen Zielregionen ist ein CDN essenziell: Nutzer in Finnland laden die finnische Schrift-Subset von einem nahen Edge-Knoten, Nutzer in Malta entsprechend. Wichtig: Richten Sie für jede Sprachversion eine eigene Cache-Regel ein, sodass z. B. die deutsche Subset-Datei mit langer Gültigkeit (z. B. ein Jahr) gecached wird, während Sie bei Schrift-Updates den Cache durch Ändern des Dateinamens (Fingerprinting) invalidieren. So stellen Sie sicher, dass die Schriften schnell ausgeliefert werden und stets aktuell sind, ohne dass Nutzer auf Aktualisierungen warten müssen.
Barrierefreiheit und Lesbarkeit: Schriftwahl für alle Nutzergruppen
Mehrsprachigkeit bedeutet nicht nur, Zeichen richtig darzustellen, sondern auch, dass die Schrift für alle Nutzer gut lesbar ist – unabhängig von Sehfähigkeit, Bildschirmgröße oder Endgerät. Achten Sie daher bei der Schriftwahl auf ausreichende Buchstabenunterscheidbarkeit, besonders bei ähnlichen Zeichen wie 'rn' vs. 'm' oder '0' vs. 'O'. Für lateinische Schriften eignen sich serifenlose Fonts mit großer x-Höhe und offenen Formen; für arabische Schriften sind Fonts mit klaren Verbindungen und ausreichendem Innenraum wichtig. Stellen Sie sicher, dass die Schrift bei Vergrößerung auf 200 % nicht ausfranst oder die Zeichenabstände kippen. Nutzen Sie im CSS font-size-adjust: from-font oder legen Sie explizite Fallback-Schriften fest, die ähnliche Proportionen haben, um Layout-Sprünge bei Zoom zu vermeiden. Ein weiterer Aspekt ist die Kontraststufe: Schrift auf Hintergrund sollte mindestens WCAG-AA (4,5:1) einhalten, bei kleiner Schrift besser AAA (7:1). Für 24 Sprachen bedeutet das: Testen Sie jede Sprachversion mit einem Kontrast-Checker, da manche Schriftarten bei bestimmten Strichstärken oder in kursiven Schnitten an Kontrast verlieren. Auch die Zeilenlänge und der Zeilenabstand sollten je Sprache angepasst werden – arabische Texte benötigen oft mehr Zeilenhöhe als lateinische. Integrieren Sie diese Tests in Ihre automatisierte Qualitätssicherung (siehe Abschnitt 4), um sicherzustellen, dass alle Nutzer – auch ältere oder sehbehinderte – Ihre Inhalte optimal erfassen können.
blog.faqT
Kann ich Google Fonts für mehrsprachige EU-Seiten nutzen?
Technisch ja, aber datenschutzrechtlich problematisch, da Google die IP-Adressen der Besucher erfasst. Für EU-Seiten ist ein selbst gehosteter Font empfehlenswert. Zudem bieten Google Fonts nur eine begrenzte Auswahl an multilingualen Schriften; Sie müssten ggf. mehrere Familien kombinieren, was den Ladeaufwand erhöht.
Wie prüfe ich, ob meine Schrift alle benötigten Glyphen abdeckt?
Nutzen Sie Tools wie GlyphChecker oder den Unicode-Range-Test von Wakamai Fondue. Geben Sie die Zeichen Ihrer Zielsprachen ein (z. B. türkisches İ, rumänisches Ș). Alternativ parsen Sie Ihr Content-Management-System und extrahieren alle Unicode-Codepoints pro Sprachseite, um sie mit der Schrift zu vergleichen. So entdecken Sie Lücken vor dem Livegang.
