2025-07-02 · Redaktion Baduno · 7 blog.readMin · Blog & Viden
Webfonts til 24 sprog: skriftvalg, subsetting, ydeevne
En skrift, der bærer tysk, græsk, maltesisk og arabisk? Det findes sjældent – og hvis, så tungt. Strategier for hurtig, smuk flersprogethed.
Dækningsproblemet
Latinsk med alle EU-diakritiske tegn, græsk, kyrillisk, samt arabisk skrift: Næsten ingen skriftfamilie dækker alt godt. Den pragmatiske løsning er skriftpar – en latinsk/græsk/kyrillisk-familie plus en specialiseret RTL-skrift, afstemt efter gråværdi og højde.
Subsetting sparer massivt
Fuldstændige Unicode-skrifttyper vejer hundreder af kilobyte. Subsets pr. skriftsystem – indlæst kun hvor nødvendigt – reducerer det til brøkdele: RTL-versionen indlæser RTL-skriften, den tyske gør ikke.
Indlæsning uden hop
font-display:swap viser straks tekst med systemskrift og udskifter derefter – mod layout-spring hjælper metrisk kompatible fallbacks og size-adjust. Selvhostet i stedet for fra fremmed CDN: hurtigere og mere privatlivsvenligt.
Typografi pr. skriftsystem
Arabisk skrift kræver mere linjehøjde og ofte en punkt større grad; versalspatiering fungerer kun på latin. Et designsystem, der kender sådanne regler pr. skriftsystem, gør 24 sprog til ét layout – i stedet for 25 kompromiser.
Variable skrifttyper: Fleksibilitet med forhindringer
Variable skrifttyper lover et reduceret antal filer ved at samle flere snit (fed, kursiv osv.) i én fil. For flersprogede sider med 24 sprog er det fristende: I stedet for 24 × 4 = 96 statiske filer kun 24 variable? Men forsigtig: Variable skrifttyper med bred sprogdækning (Latin, Græsk, Kyrillisk, Arabisk) er sjældne og ofte store. Subsetting bliver desuden mere komplekst, da variationsakserne påvirker tegnsættet. En subsettet variabel skrifttype kan afhængigt af aksens udtryk have brug for andre glyffer, så du enten skal have alle subsets klar eller generere dem dynamisk. Praktisk kan man anvende variable skrifttyper til én skriftsystemfamilie (f.eks. Latin + Græsk) og statiske skrifttyper til den anden (f.eks. Arabisk) for at kontrollere filstørrelsen. Indlæs variable skrifttyper via font-weight: 100 900 og font-stretch: 75% 125% i stedet for enkelte snit – men test visningen på alle sprog og browsere, da variable skrifttyper ved subsetting og rastering nogle gange giver uventede resultater.
Licensoverholdelse af skrifttypebrug på 24 sprog
Den juridiske side undervurderes ofte. En skrifttypelicens gælder normalt for et bestemt antal sidevisninger eller for et domæne; med 24 sprogvarianter kan du allerede støde på grænser afhængigt af licensen. Nogle udbydere forbyder eksplicit subsetting eller indlejring i dynamisk indhold. Sørg for, at licensen dækker alle sprog – især specialtegn som tyrkisk İ, rumænsk Ș eller maltesisk Ħ betragtes ofte som udvidet tegnsæt og er ikke altid inkluderet i standardpakken. For EU-projekter anbefales en Unlimited- eller Enterprise-licens, der også tillader subsetting og brug på flere domæner. Kontroller desuden skrifttypelicensens gyldighed for den anvendte skrifttypeteknologi (f.eks. WOFF2). Et licensrådgivningsværktøj (f.eks. fra Fontstand) kan hjælpe med at undgå konflikter – noter licensbetingelserne pr. skrifttype i din styleguide, så der ikke senere skal foretages justeringer.
Formatkonkurrence: WOFF2, subsettede variable skrifttyper og Unicode-Range
Valget af filformat påvirker indlæsningstid og kompatibilitet. WOFF2 er i dag standard og tilbyder ca. 30-50% bedre komprimering end WOFF. Hvis du anvender variable skrifttyper, bør du kontrollere, om din målbrowser understøtter WOFF2 med variable akser (aktuelt alle moderne browsere). For ældre browsere (IE11) skal du have statiske WOFF-filer som fallback. Et effektivt trick: Brug Unicode-Range i @font-face for kun at indlæse det faktisk nødvendige tegnsæt – ligesom subsetting, men serverstyret. Kombiner det med font-display: swap; understøt indlæsningsoptimering via preload for kritiske skrifttypevarianter (f.eks. grundskrift til Latin). Et praktisk eksempel: For den tyske side indlæser du kun Latin+Umlaut-subset (ca. 30 KB), for den græske side Latin+Græsk-subset (ca. 50 KB), for den arabiske side Latin+Arabisk-subset (ca. 80 KB). På den måde forbliver de samlede downloads pr. besøgende under 100 KB skrifttypedata, selv med 24 sprog.
En skrift, der bærer tysk, græsk, maltesisk og arabisk? Det findes sjældent – og hvis, så tungt. Strategier for hurtig, smuk flersprogethed.
Automatiseret kvalitetssikring af skriftgengivelse
For at sikre, at der ikke mangler glyffer eller de fremstår fragmenterede i alle 24 sprogvarianter, bør du integrere automatiserede tests i din CI/CD-pipeline. Værktøjer som FontProof, Wakamai Fondue eller Python-scriptet fontdiff sammenligner gengivne skærmbilleder af hver sprogversion med et referenceskærmbillede. Alternativt kan du bruge Puppeteer til at åbne hver side, indlæse skrifttypen og kontrollere for mangler (via CSS-egenskaben font-family: …; font-unicode-range). Endnu mere systematisk: Udtræk alle Unicode-kodepunkter, der forekommer i HTML per sprogversion, og afstem dem med de glyffer, der findes i subsettet. Mangler et tegn, afbrydes bygget, eller der udsendes en advarsel. Disse tests bør også kontrollere læsbarheden af ligaturer eller alternative tegn (f.eks. arabiske initialformer). Integrer desuden et performance-budget-tjek: Skriftstørrelsen per sprog må ikke overskride en bestemt tærskel. Sådan sikrer du, at flersprogethed ikke går ud over indlæsningstiden.
AI-understøttet subsetting: Effektivitet gennem automatisering med kvalitetssikring
Det er tidskrævende og fejlbehæftet manuelt at administrere subsetting for 24 sprog. Moderne build-værktøjer som glyphhanger eller HarfBuzz kan automatisk generere subsets baseret på de faktiske tegn, der forekommer i indholdet. Processen bliver endnu mere effektiv, hvis du anvender AI-modeller, der forudsiger de nødvendige Unicode-blokke ud fra sprogversionerne. Et neuralt netværk trænet på flersprogede websteder kan med høj præcision bestemme, hvilke glyffer der er nødvendige for et bestemt sprog – fra latinske grundtegn over kyrilliske tilføjelser til arabiske ligaturer. Det automatisk genererede subset underkastes derefter en manuel gennemgang af en modersmålsbruger for at sikre, at ingen sjældne, men vigtige tegn (f.eks. historiske citater, specialtegn i firmanavne) mangler. Denne kombination af AI-acceleration og menneskelig kontrol reducerer subset-oprettelsen fra dage til timer med fortsat høj kvalitet. Integrer scriptet i din CI/CD-pipeline, så subsets automatisk genereres og testes på ny ved hvert indholdsopdatering. På den måde sikrer du, at skriftfiler altid er opdaterede uden at påvirke indlæsningshastigheden.
Sprogspecifikke fallback-strategier for konsistent typografi
Selv ved optimal subsetting kan det ske, at en skriftfil ikke indlæses – på grund af netværksfejl, browserinkompatibilitet eller licensbegrænsninger. Så træder fallback-stakken i kraft. For 24 sprog er en global font-stak ikke tilstrækkelig: En systemskrift, der ser godt ud på tysk, kan være uegnet til arabisk. Definer derfor separate fallback-stakke pr. sprogversion, der er tilpasset de typiske systemskrifter i målregionen. Brug CSS-funktionen @font-face med unicode-range til kun at indlæse de tegn, der faktisk er nødvendige for hver skriftfamilie. For den arabiske version kan du angive 'Traditional Arabic' eller 'Tahoma' som fallback, for den græske 'GFS Didot' eller 'Times New Roman'. Vær opmærksom på metrisk kompatibilitet: Brug size-adjust og ascent-override til visuelt at tilpasse fallback-skriften til primærskriften, så layout-spring minimeres. Test disse fallbacks på alle sprog med en automatiseret skærmbilledsammenligning for at sikre, at læsbarheden bevares selv i fejltilfælde. På den måde undgår du overraskelser og sikrer en konsistent brugeroplevelse på tværs af alle sprogvarianter.
Server-side optimering: Self-hosting, caching og CDN-strategier
Levering af webfonts via eksterne tjenester som Google Fonts eller Adobe Fonts er bekvemt, men har ulemper for flersprogede projekter: For det første kræver 24 sprogvarianter ofte flere forespørgsler til forskellige servere, hvilket øger indlæsningstiden. For det andet kender du ikke udbyderens caching-strategi og har ingen kontrol over nedetid eller databeskyttelse. Derfor anbefaler vi self-hosting af alle skriftfiler på din egen server eller et dedikeret CDN. Med self-hosting kan du skræddersy skriftsubsets præcist til dine sprogversioner og prioritere kritiske skrifter via HTTP/2 Server Push eller Preload-hints. Derudover kan caching styres via Cache-Control-headere, så skrifterne kun indlæses én gang for alle besøgende på en given sprogversion. Et CDN med edge-servere tæt på dine brugere forkorter latenstiden. For 24 sprog med forskellige målregioner er et CDN essentielt: Brugere i Finland henter det finske skriftsubset fra en nærliggende edge-node, brugere på Malta tilsvarende. Vigtigt: Opret separate caching-regler for hver sprogversion, så f.eks. den tyske subset-fil caches med lang gyldighed (f.eks. et år), mens du ved skriftopdateringer ugyldiggør cachen ved at ændre filnavnet (fingerprinting). På den måde sikrer du, at skrifterne leveres hurtigt og altid er opdaterede, uden at brugerne skal vente på opdateringer.
Tilgængelighed og læsbarhed: Skriftvalg til alle brugergrupper
Flersproglighed betyder ikke kun at vise tegn korrekt, men også at skriften er let læselig for alle brugere – uanset synsevne, skærmstørrelse eller enhed. Vær derfor opmærksom på tilstrækkelig bogstavadskillelse ved valg af skrifttype, især ved lignende tegn som 'rn' vs. 'm' eller '0' vs. 'O'. Til latinske skrifter egner sans-serif skrifttyper med stor x-højde og åbne former sig; til arabiske skrifttyper er skrifttyper med klare forbindelser og tilstrækkelig indre plads vigtige. Sørg for, at skriften ikke flosser ved forstørrelse til 200 %, eller at tegnafstandene ændrer sig. Brug i CSS font-size-adjust: from-font eller angiv eksplicitte fallback-skrifttyper med lignende proportioner for at undgå layout-spring ved zoom. Et andet aspekt er kontrastniveauet: Skrift på baggrund bør mindst opfylde WCAG-AA (4,5:1), ved lille skrift helst AAA (7:1). For 24 sprog betyder det: Test hver sprogversion med en kontrastkontrol, da nogle skrifttyper mister kontrast ved bestemte stregtykkelser eller i kursiv. Linjelængde og linjeafstand bør også tilpasses efter sprog – arabiske tekster kræver ofte større linjehøjde end latinske. Integrer disse tests i din automatiserede kvalitetssikring (se afsnit 4) for at sikre, at alle brugere – også ældre eller synshæmmede – kan opfatte dit indhold optimalt.
blog.faqT
Kan jeg bruge Google Fonts til flersprogede EU-sider?
Teknisk set ja, men databeskyttelsesmæssigt problematisk, da Google indsamler besøgendes IP-adresser. For EU-sider anbefales en selvhostet skrifttype. Derudover tilbyder Google Fonts kun et begrænset udvalg af flersprogede skrifttyper; du ville muligvis skulle kombinere flere familier, hvilket øger indlæsningsbyrden.
Hvordan kontrollerer jeg, om min skrifttype dækker alle nødvendige glyffer?
Brug værktøjer som GlyphChecker eller Unicode-områdetesten fra Wakamai Fondue. Indtast tegnene fra dine målsprog (f.eks. tyrkisk İ, rumænsk Ș). Alternativt kan du analysere dit content management system og udtrække alle Unicode-kodepunkter pr. sprogside for at sammenligne med skrifttypen. På den måde opdager du huller før lancering.
