2025-07-02 · Redaktionen Baduno · 7 blog.readMin · Blog & Kunskap
Webbtypsnitt för 24 språk: Teckensnittsval, subsetting, prestanda
Ett typsnitt som bär tyska, grekiska, maltesiska och arabiska? Det finns sällan – och om det gör det, tungt. Strategier för snabb, vacker flerspråkighet.
Täckningsproblemet
Latinskt med alla EU-diakritiska tecken, grekiska, kyrilliska, plus arabisk skrift: Knappast en teckensnittsfamilj täcker allt bra. Den pragmatiska lösningen är teckensnittspar – en latin/grekiska/kyrilliska-familj plus ett specialiserat RTL-typsnitt, anpassade till varandra i gråvärde och höjd.
Subsetting sparar massivt
Fullständiga Unicode-typsnitt väger hundratals kilobyte. Subset per skriftsystem – laddas endast där de behövs – reducerar det till bråkdelar: RTL-versionen laddar RTL-typsnittet, den tyska inte.
Laddning utan hopp
font-display:swap visar omedelbart text med systemteckensnitt och byter sedan – mot layout-hopp hjälper metriskt kompatibla fallbacks och size-adjust. Egen hosting istället för extern CDN: snabbare och mer dataskyddsvänligt.
Typografi per skriftsystem
Arabisk skrift kräver större radhöjd och ofta en punkt större grad; versal spacing fungerar endast latinskt. Ett designsystem som känner till sådana regler per skriftsystem gör 24 språk till en layout – istället för 25 kompromisser.
Variabla typsnitt: Flexibilitet med hinder Variabla typsnitt lovar ett minskat antal filer genom att bunta ihop flera snitt (fet, kursiv etc.) i en fil. För flerspråkiga sidor med 24 språk är det lockande: istället för 24 × 4 = 96 statiska filer bara 24 variabla? Men var försiktig: Variabla typsnitt med brett språkomfång (latin, grekiska, kyrilliska, arabiska) är sällsynta och ofta stora. Subsetting blir dessutom mer komplext eftersom variationsaxlarna påverkar teckenuppsättningen. Ett subsettat variabelt typsnitt kan beroende på axelutslag kräva andra glyfer, så du måste antingen hålla alla delmängder tillgängliga eller generera dynamiskt. Praktiskt är att använda variabla typsnitt för en skriftsystemfamilj (t.ex. latin + grekiska) och statiska typsnitt för det andra (t.ex. arabiska) för att kontrollera filstorleken. Ladda variabla typsnitt med font-weight: 100 900 och font-stretch: 75% 125% istället för enskilda snitt – men testa visningen på alla språk och webbläsare eftersom variabla typsnitt ibland ger oväntade resultat vid subsetting och rastering.
Variable typsnitt lovar ett minskat antal filer genom att flera snitt (fet, kursiv etc.) slås samman i en fil. För flerspråkiga sidor med 24 språk är detta lockande: Istället för 24 × 4 = 96 statiska filer bara 24 variabla? Men var försiktig: Variable typsnitt med brett språkomfång (latin, grekiska, kyrilliska, arabiska) är sällsynta och ofta stora. Subsetting blir dessutom mer komplext eftersom variationsaxlarna påverkar teckenuppsättningen. Ett subsettat variabelt typsnitt kan beroende på axelutslag kräva andra glyfer, så du måste antingen hålla alla subsets tillgängliga eller generera dem dynamiskt. Praktiskt är att använda variabla typsnitt för en skriftsystemfamilj (t.ex. latin + grekiska) och statiska typsnitt för den andra (t.ex. arabiska) för att kontrollera filstorleken. Ladda variabla typsnitt via font-weight: 100 900 och font-stretch: 75% 125% istället för enskilda snitt – men testa visningen på alla språk och webbläsare, eftersom variabla typsnitt vid subsetting och rasterisering ibland ger oväntade resultat.
Licensenlig användning av typsnitt på 24 språk Den juridiska aspekten underskattas ofta. En typsnittslicens gäller oftast för ett visst antal sidvisningar eller för en domän; med 24 språkvarianter kan du beroende på licens redan nå gränser. Vissa leverantörer förbjuder uttryckligen subsetting eller inbäddning i dynamiskt innehåll. Se till att licensen täcker alla språk – särskilt specialtecken som turkiska İ, rumänska Ș eller maltesiska Ħ anses ofta vara utökad teckenuppsättning och ingår inte alltid i standardpaketet. För EU-projekt rekommenderas en obegränsad eller företagslicens som även tillåter subsetting och användning på flera domäner. Kontrollera också att typsnittslicensen gäller för den fontteknologi du använder (t.ex. WOFF2). Ett licensrådgivningsverktyg (t.ex. från Fontstand) kan hjälpa till att undvika konflikter – anteckna licensvillkoren per typsnitt i din stilguide så att inga justeringar blir nödvändiga.
Den juridiska sidan underskattas ofta. En typsnittslicens gäller vanligtvis för ett visst antal sidvisningar eller för en domän; med 24 språkvarianter kan du beroende på licens redan nå gränser. Vissa leverantörer förbjuder uttryckligen subsetting eller inbäddning i dynamiskt innehåll. Se till att licensen täcker alla språk – särskilt specialtecken som turkiska İ, rumänska Ș eller maltesiska Ħ anses ofta vara utökad teckenuppsättning och ingår inte alltid i standardpaketet. För EU-projekt rekommenderas en Unlimited- eller Enterprise-licens som även tillåter subsetting och flerdomänsanvändning. Kontrollera dessutom typsnittslicensens giltighet för den font-teknologi du använder (t.ex. WOFF2). Ett licensrådgivningsverktyg (t.ex. från Fontstand) kan hjälpa till att undvika konflikter – anteckna licensvillkoren per typsnitt i din styleguide så att inga justeringar behövs i efterhand.
Formatkonkurrens: WOFF2, subsettade variabla typsnitt och Unicode-Range Valet av filformat påverkar laddningstid och kompatibilitet. WOFF2 är idag standard och erbjuder cirka 30-50% bättre kompression än WOFF. Om du använder variabla typsnitt bör du kontrollera om din målwebbläsare stöder WOFF2 med variabla axlar (för närvarande alla moderna webbläsare). För äldre webbläsare (IE11) måste du ha statiska WOFF-filer som reserv. Ett effektivt knep: Använd Unicode-Range i @font-face för att bara ladda den teckenuppsättning som faktiskt behövs – liknande subsetting men styrs serversidan. Kombinera detta med font-display: swap; laddningsoptimeringen kan du stödja via preload för kritiska typsnittsvarianter (t.ex. grundtypsnitt för latin). Ett praktiskt exempel: För den tyska sidan laddar du bara subsetet Latin+Umlaut (ca 30 KB), för den grekiska sidan subsetet Latin+Grekiska (ca 50 KB), för den arabiska sidan subsetet Latin+Arabiska (ca 80 KB). På så sätt hålls den totala nedladdningen per besökare under 100 KB typsnittsdata även vid 24 språk.
Valet av filformat påverkar laddningstid och kompatibilitet. WOFF2 är idag standard och ger cirka 30–50 % bättre komprimering än WOFF. Om du använder variabla typsnitt bör du kontrollera om din målwebbläsare stöder WOFF2 med variabla axlar (för närvarande alla moderna webbläsare). För äldre webbläsare (IE11) måste du ha statiska WOFF-filer som fallback. Ett effektivt knep: Använd Unicode-Range i @font-face för att endast ladda den teckenuppsättning som faktiskt behövs – liknande subsetting, men styrt på serversidan. Kombinera detta med font-display: swap; laddningsoptimeringen kan du stödja via preload för kritiska typsnittsvarianter (t.ex. grundtypsnitt för latin). Ett praktiskt exempel: För den tyska sidan laddar du endast subset för latin+umlaut (ca 30 kB), för den grekiska sidan subset för latin+grekiska (ca 50 kB), för den arabiska sidan subset för latin+arabiska (ca 80 kB). På så sätt hålls den totala nedladdningen per besökare under 100 kB typsnittsdata även vid 24 språk.
Ett typsnitt som bär tyska, grekiska, maltesiska och arabiska? Det finns sällan – och om det gör det, tungt. Strategier för snabb, vacker flerspråkighet.
Automatiserad kvalitetssäkring av typsnittsvisning
För att inga glyfer ska saknas eller se fragmenterade ut i alla 24 språkvarianter bör du integrera automatiska tester i din CI/CD-pipeline. Verktyg som FontProof, Wakamai Fondue eller Python-skriptet fontdiff jämför renderade skärmbilder av varje språkversion med en referensskärmbild. Eller så använder du Puppeteer för att öppna varje sida, ladda typsnittet och kontrollera luckor (via CSS-egenskapen font-family: …; font-unicode-range). Ännu mer systematiskt: Extrahera alla Unicode-kodpunkter som förekommer i HTML per språkversion och jämför dem med de glyfer som finns i subsetet. Saknas ett tecken avbryts bygget eller en varning utfärdas. Dessa tester bör även kontrollera läsbarheten av ligaturer eller alternativa tecken (t.ex. arabiska initialformer). Integrera dessutom en prestandabudgetkontroll: Typsnittsstorleken per språk får inte överskrida ett visst tröskelvärde. På så sätt säkerställer du att flerspråkigheten inte sker på bekostnad av laddningstiden.
AI-baserad subsetting: Effektivitet genom automatisering med kvalitetssäkring
Att manuellt hantera subsetting för 24 språk är tidskrävande och felbenäget. Moderna byggverktyg som glyphhanger eller HarfBuzz kan automatiskt generera subset baserat på de tecken som faktiskt förekommer i innehållet. Processen blir ännu effektivare om du använder AI-modeller som förutsäger vilka Unicode-block som behövs baserat på språkversionerna. Ett neuralt nätverk, tränat på flerspråkiga webbplatser, kan med hög träffsäkerhet avgöra vilka glyfer som krävs för ett visst språk – från latinska bastecken till kyrilliska tillägg och arabiska ligaturer. Det automatiskt genererade subsetet genomgår sedan en manuell granskning av en modersmålstalare för att säkerställa att inga sällsynta men viktiga tecken (t.ex. historiska citat, specialtecken i företagsnamn) saknas. Denna kombination av AI-acceleration och mänsklig kontroll minskar subset-skapandet från dagar till timmar med bibehållen hög kvalitet. Integrera skriptet i din CI/CD-pipeline så att subseten automatiskt genereras och testas vid varje innehållsuppdatering. På så sätt säkerställer du att typsnittsfilerna alltid är uppdaterade utan att påverka laddningsprestandan.
Språkspecifika fallback-strategier för konsekvent typografi
Även vid optimal subsetting kan det hända att en typsnittsfil inte laddas – på grund av nätverksfel, webbläsarinkompatibilitet eller licensbegränsningar. Då aktiveras fallback-stacken. För 24 språk räcker inte en global font-stack: Ett systemtypsnitt som ser bra ut på tyska kan vara olämpligt för arabiska. Definiera därför separata fallback-stackar per språkversion, anpassade efter de typiska systemtypsnitten i målregionen. Använd CSS-funktionen @font-face med unicode-range för att endast ladda de tecken som faktiskt behövs för varje typsnittsfamilj. För den arabiska versionen kan du ange 'Traditional Arabic' eller 'Tahoma' som fallback, för den grekiska 'GFS Didot' eller 'Times New Roman'. Var uppmärksam på metrisk kompatibilitet: Med size-adjust och ascent-override anpassar du fallback-typsnittet visuellt till huvudtypsnittet så att layout-hopp minimeras. Testa dessa fallbacks på alla språk med en automatiserad skärmjämförelse för att säkerställa att läsbarheten bibehålls även vid fel. På så sätt undviker du överraskningar och skapar en konsekvent användarupplevelse över alla språkvarianter.
Serveroptimering: Self-Hosting, cachning och CDN-strategier
Att leverera webbteckensnitt via externa tjänster som Google Fonts eller Adobe Fonts är bekvämt men medför nackdelar för flerspråkiga projekt: För det första måste du vid 24 språkvarianter ofta skicka flera förfrågningar till olika servrar, vilket ökar laddningstiden. För det andra känner du inte till leverantörens cachningsstrategi och har ingen kontroll över driftavbrott eller dataskydd. Därför rekommenderar vi self-hosting av alla teckensnittsfiler på din egen server eller ett dedikerat CDN. Genom self-hosting kan du skräddarsy teckensnittsdelmängderna exakt för dina språkversioner och prioritera kritiska teckensnitt med HTTP/2 Server Push eller Preload-hints. Dessutom kan cachningen styras via Cache-Control-huvuden så att teckensnitten bara laddas en gång för alla besökare av en språkversion. Ett CDN med edge-servrar nära dina användare minskar latensen. För 24 språk med olika målregioner är ett CDN avgörande: Användare i Finland laddar den finska teckensnittsdelmängden från en nära edge-nod, användare på Malta motsvarande. Viktigt: Skapa en egen cachningsregel för varje språkversion så att t.ex. den tyska delmängdsfilen cachas med lång giltighetstid (t.ex. ett år), medan du vid teckensnittsuppdateringar ogiltigförklarar cachen genom att ändra filnamnet (fingeravtryck). På så sätt säkerställer du att teckensnitten levereras snabbt och alltid är aktuella, utan att användare behöver vänta på uppdateringar.
Tillgänglighet och läsbarhet: Teckensnittsval för alla användargrupper
Flerspråkighet innebär inte bara att visa tecken korrekt, utan också att teckensnittet är lättläst för alla användare – oavsett synförmåga, skärmstorlek eller enhet. Var därför noga med tillräcklig bokstavsskillnad vid val av teckensnitt, särskilt vid liknande tecken som 'rn' vs. 'm' eller '0' vs. 'O'. För latinska skrifter är sans-serif-teckensnitt med stor x-höjd och öppna former lämpliga; för arabiska skrifter är teckensnitt med tydliga kopplingar och tillräckligt inre utrymme viktiga. Se till att teckensnittet inte fransar sig eller att teckenavstånden blir snedda vid förstoring till 200 %. Använd font-size-adjust: from-font i CSS eller ange explicita reservteckensnitt med liknande proportioner för att undvika layoutsprång vid zoomning. En annan aspekt är kontrastnivån: text på bakgrund bör uppfylla minst WCAG-AA (4,5:1), för liten text helst AAA (7:1). För 24 språk innebär det: testa varje språkversion med en kontroll av kontrasten, eftersom vissa teckensnitt tappar kontrast vid vissa strecktjocklekar eller i kursiv stil. Även radlängd och radavstånd bör anpassas per språk – arabiska texter kräver ofta större radhöjd än latinska. Integrera dessa tester i din automatiserade kvalitetssäkring (se avsnitt 4) för att säkerställa att alla användare – även äldre eller synskadade – optimalt kan ta till sig ditt innehåll.
blog.faqT
Kan jag använda Google Fonts för flerspråkiga EU-sidor?
Tekniskt ja, men dataskyddsmässigt problematiskt eftersom Google samlar in besökarnas IP-adresser. För EU-sidor rekommenderas ett självhostat typsnitt. Dessutom erbjuder Google Fonts endast ett begränsat urval av flerspråkiga typsnitt; du måste eventuellt kombinera flera familjer, vilket ökar laddningstiden.
Hur kontrollerar jag om mitt typsnitt täcker alla nödvändiga glyfer?
Använd verktyg som GlyphChecker eller Unicode-Range-testet från Wakamai Fondue. Ange tecken för dina målspråk (t.ex. turkiskt İ, rumänskt Ș). Alternativt kan du analysera ditt innehållshanteringssystem och extrahera alla Unicode-kodpunkter per språksida för att jämföra med typsnittet. På så sätt upptäcker du luckor innan lansering.
