Mehrsprachige Performance.
Auf einer mehrsprachigen Website ist die größte Performancevariable die Schrift-Teilmenge: Jede Sprache braucht andere Zeichen, und unnötige Zeichen werden auf jeder Seite heruntergeladen.
Mehrsprachig zu sein bringt der Performance keine direkten Kosten — pro Sprache werden eigene Seiten erzeugt, und jeder Nutzer lädt nur die Seite in seiner Sprache. Aber es gibt einen Posten, der unbeachtet allen Sprachen zugleich Gewicht hinzufügt: die Schriftdateien.
Eine Schriftdatei kann standardmäßig Tausende Zeichen tragen. Der für Türkisch, Englisch und Deutsch nötige Zeichensatz ist ein kleiner Teil davon — und die unnötigen werden auf jeder Seite, für jeden Nutzer heruntergeladen.
Die Teilmenge
Die Lösung ist die Teilmengenerzeugung: Die Schriftdatei wird nur mit den nötigen Zeichen neu erzeugt. Der Gewinn ist meist dramatisch — sie kann auf einen kleinen Prozentsatz der vollen Datei sinken.
Welche Teilmenge nötig ist, hängt an den Sprachen. Für Türkisch braucht es die lateinischen und erweitert-lateinischen Sätze: Der erweiterte Satz enthält das punktlose ı, das ğ und das ş des Türkischen. Für Deutsch finden sich die Umlaute und das Eszett in denselben Sätzen.
Auf dieser Website werden beide Schriftfamilien mit der lateinischen und erweitert-lateinischen Teilmenge erzeugt — die kyrillischen, griechischen und vietnamesischen Sätze kommen nie herunter. Beide sind variable Schriften, eine Datei trägt also alle Gewichte und Breiten.
- Nur die nötigen Sätze erzeugen — ungenutzte Alphabete sollen nicht auf jeder Seite herunterladen.
- Variable Schriften verwenden — eine Datei statt sechs Dateien für sechs Gewichte.
- Keine eigene Datei pro Sprache ausliefern — beim Sprachwechsel des Nutzers käme ein Neudownload.
- Die Familienzahl begrenzen — jede Familie ist eine zusätzliche Anfrage und ein zusätzliches Tauschrisiko.
- Selbst hosten — der externe Host ist zusätzliche Verbindungskosten und ein Datenschutzrisiko.
Der dritte Punkt enthält einen Kompromiss: Die eigene Datei pro Sprache entfernt die unnötigen Zeichen dieser Sprache völlig, aber beim Sprachwechsel des Nutzers lädt eine neue Datei. Auf einer Website mit drei lateinbasierten Sprachen ist die eine Datei effizienter; kommt Kyrillisch oder das arabische Alphabet hinzu, ändert sich die Gleichung.
Die anderen Posten
Jenseits der Schrift ist die Performancewirkung der Mehrsprachigkeit begrenzt, aber zwei Punkte verlangen Aufmerksamkeit.
Der erste ist die Textlänge: Deutscher Text ist länger, die deutsche Seite also etwas schwerer. Der Unterschied ist klein und wird meist von der Kompression geschluckt — aber längerer Text heißt auch mehr Layoutrechnung, und auf sehr langen Seiten wird das messbar.
Der zweite ist der Bildinhalt: Bilder mit Text müssen für jede Sprache eigens erzeugt werden, und das heißt Produktionslast und Speicher zugleich. Das ist, jenseits der Performance, ein weiterer Grund, Bilder mit Text zu meiden — zusätzlich zu den Gründen der Barrierefreiheit und Maschinenlesbarkeit.
Auf dieser Website gibt es keine Bilder mit Text; aller Text ist als Text geschrieben. Die Sozialkarten sind eine Ausnahme, aber sie werden im Browser erzeugt und kommen nicht mit der Seite herunter.
Messung und Budget
Auf einer mehrsprachigen Website sollte das Performancebudget pro Sprache gemessen werden. Die deutsche Version derselben Seite trägt längeren Text, verwendet eine andere Schriftbreite und enthält bisweilen andere Bilder — alle drei ändern das Gewicht.
- Jede Sprache eigens messen — eine zu messen und die anderen anzunehmen täuscht.
- Die Schrift-Teilmenge verifizieren — steckt ein unnötiges Alphabet in der Datei?
- Ist die Familienzahl begrenzt — jede Familie ist zusätzliche Anfrage und Tauschrisiko.
- Wurde der Textlängenunterschied gemessen — die längste Sprache setzt das Budget.
- Sind die Bilder sprachunabhängig — ein Bild mit Text heißt eigene Produktion pro Sprache.
Der vierte Punkt enthält ein Prinzip: Das Budget wird nach der längsten Sprache gesetzt. Bricht ein auf Türkisch abgestimmtes Budget im Deutschen, war das Budget falsch gesetzt.
Auf dieser Website werden die zwei Schriftfamilien mit der lateinischen und erweitert-lateinischen Teilmenge erzeugt, beide variabel und vom eigenen Server ausgeliefert. Die gemessene JavaScript-Summe beträgt nach gzip 83,7 Kilobyte — sprachunabhängig, denn der Code ist sprachunabhängig.
Und eine Architekturnotiz: Auf dieser Website werden die Seiten vorab erzeugt und als Dateien ausgeliefert, die Sprachzahl erhöht die Serverkosten also nicht. Drei Sprachen heißen dreimal so viele Seiten, aber nicht dreimal so viel Verarbeitung — jede Seite ist ohnehin eine Datei.
Wann die Sprachzahl zu Kosten wird
In der statischen Erzeugung produziert die Sprachzahl keine Serverkosten, wohl aber Bauzeit und Speicher. Fünfzig Seiten in drei Sprachen heißen hundertfünfzig Dateien — und jeder Build erzeugt sie alle neu.
Im kleinen Maßstab fällt das nicht auf. Auf dieser Website werden achtundfünfzig Seiten binnen Sekunden erzeugt. Aber eine Website mit tausend Seiten in sieben Sprachen heißt siebentausend Dateien, und in diesem Maßstab kann die Bauzeit zum Problem werden — besonders wenn jede kleine Änderung eine volle Neuerzeugung auslöst.
Die Lösung ist die inkrementelle Erzeugung: Nur die geänderten Seiten werden neu erzeugt. Auf dieser Website ist eine ähnliche Logik fürs Lastmod-Register bereits gebaut — die Ausgabe jeder Seite bekommt einen Fingerabdruck, und der Stempel schreitet nur bei geändertem Abdruck voran. Derselbe Abdruck kann auch der inkrementellen Erzeugung dienen.
Und eine letzte Notiz: Mit der Sprachzahl vermehren sich auch Sitemap-, RSS- und Kartendateien. Auf dieser Website werden für die drei Sprachen drei eigene RSS-Feeds erzeugt, und alle kommen aus einem einzigen Generator — eine von Hand nicht zu verwaltende Last wird durch Automatisierung unsichtbar.
Ein Rahmen zum Schluss: Die Performancekosten der Mehrsprachigkeit sind, richtig gebaut, nahe null. Was Kosten erzeugt, ist nicht die Sprachzahl, sondern die Art der Auslieferung — die Schrift-Teilmenge, Bilder mit Text und die dynamische Erzeugung. Alle drei sind Entscheidungen der Designphase, und alle drei sind später teuer zu korrigieren.
Ein letzter Messvorschlag: Das Gewicht jeder Sprachversion sollte eigens berichtet und der Unterschied zwischen ihnen beobachtet werden. Ist der Unterschied größer als erwartet, steckt irgendwo eine sprachspezifische Last — meist ein Bild mit Text oder eine dieser Sprache eigene Ressource.
Auf dieser Website werden die Seitengewichte in der Bauausgabe Sprache für Sprache gelistet, und der Unterschied bleibt klein; die größte Abweichung liegt auf den deutschen Seiten, und ihre Ursache ist eine bekannte — die Textlänge.