2025-07-02 · Redazione Baduno · 9 blog.readMin · Blog & Conoscenza
Webfont per 24 lingue: scelta dei caratteri, subsetting, prestazioni
Un carattere che supporti tedesco, greco, maltese e arabo? Raro – e quando esiste, è pesante. Strategie per una multilingualità veloce e bella.
Il problema della copertura
Latino con tutti i diacritici UE, greco, cirillico, più arabo: quasi nessuna famiglia di caratteri copre tutto bene. La soluzione pragmatica sono coppie di caratteri – una famiglia latino/greco/cirillico più un carattere RTL specializzato, abbinati per tono e altezza.
Il subsetting fa risparmiare molto
I font Unicode completi pesano centinaia di kilobyte. I subset per sistema di scrittura – caricati solo dove necessario – li riducono a frazioni: la versione RTL carica il font RTL, quella tedesca no.
Caricare senza salti
font-display:swap mostra subito il testo con il carattere di sistema e poi lo sostituisce – contro i salti di layout aiutano fallback metricamente compatibili e size-adjust. Hosting proprio invece di CDN esterno: più veloce e rispettoso della privacy.
Tipografia per sistema di scrittura
La scrittura araba richiede più altezza di riga e spesso un punto in più di gradazione; la spaziatura tra maiuscole funziona solo in latino. Un sistema di progettazione che conosce tali regole per sistema di scrittura trasforma 24 lingue in un layout – invece di 25 compromessi.
Font Variabili: Flessibilità con Ostacoli
I font variabili promettono un numero ridotto di file raggruppando più stili (grassetto, corsivo, ecc.) in un unico file. Per siti multilingue con 24 lingue, è allettante: invece di 24 × 4 = 96 file statici, solo 24 variabili? Ma attenzione: i font variabili con un'ampia copertura linguistica (latino, greco, cirillico, arabo) sono rari e spesso grandi. Il subsetting diventa più complesso perché gli assi di variazione influenzano il set di caratteri. Un font variabile subsettato potrebbe richiedere glifi diversi a seconda dell'asse, quindi è necessario mantenere tutti i subset o generarli dinamicamente. È pratico utilizzare font variabili per una famiglia di sistemi di scrittura (ad es. latino + greco) e font statici per l'altra (ad es. arabo) per controllare la dimensione dei file. Caricare font variabili tramite font-weight: 100 900 e font-stretch: 75% 125% invece di singoli stili, ma testare la resa in tutte le lingue e browser, poiché i font variabili a volte producono risultati imprevisti durante il subsetting e la rasterizzazione.
Utilizzo Conforme delle Licenze dei Font in 24 Lingue
L'aspetto legale viene spesso sottovalutato. Una licenza di font di solito vale per un certo numero di visualizzazioni di pagina o per un dominio; con 24 varianti linguistiche si può facilmente incontrare dei limiti. Alcuni fornitori vietano esplicitamente il subsetting o l'incorporazione in contenuti dinamici. Assicurarsi che la licenza copra tutte le lingue – in particolare caratteri speciali come la İ turca, la Ș rumena o la Ħ maltese sono spesso considerati set di caratteri estesi e non sempre inclusi nel pacchetto standard. Per progetti UE si consiglia una licenza Unlimited o Enterprise che permetta anche il subsetting e l'uso su più domini. Verificare inoltre che la licenza del font sia valida per la tecnologia di font utilizzata (ad es. WOFF2). Uno strumento di consulenza sulle licenze (ad es. di Fontstand) può aiutare a evitare conflitti – annotare i termini di licenza per ogni font nel proprio styleguide per evitare necessità di revisioni.
Competizione di Formati: WOFF2, Font Variabili Subsettati e Intervallo Unicode
La scelta del formato file influisce sui tempi di caricamento e sulla compatibilità. WOFF2 è oggi lo standard e offre una compressione migliore del 30-50% rispetto a WOFF. Se si utilizzano font variabili, verificare che il browser target supporti WOFF2 con assi variabili (attualmente tutti i browser moderni). Per browser più vecchi (IE11) è necessario fornire file WOFF statici come fallback. Un trucco efficace: utilizzare Unicode-range in @font-face per caricare solo il set di caratteri effettivamente necessario – simile al subsetting, ma gestito lato server. Combinarlo con font-display: swap; l'ottimizzazione del caricamento può essere supportata tramite preload per varianti critiche di font (ad es. font di base per il latino). Un esempio pratico: per la pagina tedesca caricare solo il subset latino+umlaut (circa 30 KB), per la pagina greca il subset latino+greco (circa 50 KB), per la pagina araba il subset latino+arabo (circa 80 KB). In questo modo, anche con 24 lingue, i download totali per visitatore rimangono sotto i 100 KB di dati di font.
Un carattere che supporti tedesco, greco, maltese e arabo? Raro – e quando esiste, è pesante. Strategie per una multilingualità veloce e bella.
Assicurazione qualità automatizzata della resa dei caratteri
Per garantire che in tutte le 24 varianti linguistiche non manchino glifi o appaiano frammentati, è opportuno integrare test automatizzati nella propria pipeline CI/CD. Strumenti come FontProof, Wakamai Fondue o lo script Python fontdiff confrontano gli screenshot renderizzati di ogni versione linguistica con uno screenshot di riferimento. In alternativa, è possibile utilizzare Puppeteer per aprire ogni pagina, caricare il font e verificare la presenza di lacune (tramite la proprietà CSS font-family: …; font-unicode-range). In modo ancora più sistematico: estrarre tutti i punti codice Unicode presenti nell'HTML per ogni versione linguistica e confrontarli con i glifi presenti nel subset. Se manca un carattere, la build viene interrotta o viene visualizzato un avviso. Questi test dovrebbero verificare anche la leggibilità di legature o caratteri alternativi (ad esempio le forme iniziali arabe). Inoltre, integrare un controllo del budget di performance: la dimensione del font per lingua non deve superare una certa soglia. In questo modo si garantisce che il multilinguismo non vada a scapito del tempo di caricamento.
Subsetting basato sull'IA: efficienza tramite automazione con garanzia di qualità
Gestire manualmente il subsetting per 24 lingue è complesso e soggetto a errori. Moderni strumenti di build come glyphhanger o HarfBuzz possono generare automaticamente subset basandosi sui caratteri effettivamente presenti nei contenuti. Il processo diventa ancora più efficiente se si utilizzano modelli di IA che prevedono i blocchi Unicode necessari a partire dalle versioni linguistiche. Una rete neurale, addestrata su siti web multilingue, può determinare con elevata precisione quali glifi sono richiesti per una determinata lingua – dai caratteri latini di base alle estensioni cirilliche, fino alle legature arabe. Il subset generato automaticamente viene poi sottoposto a una verifica manuale da parte di un madrelingua per assicurarsi che non manchino caratteri rari ma importanti (ad es. citazioni storiche, caratteri speciali in nomi aziendali). Questa combinazione di accelerazione tramite IA e controllo umano riduce la creazione dei subset da giorni a ore, mantenendo una qualità costantemente elevata. Integrate lo script nella vostra pipeline CI/CD, in modo che a ogni aggiornamento dei contenuti i subset vengano automaticamente rigenerati e testati. In questo modo garantite che i file dei font siano sempre aggiornati, senza compromettere le prestazioni di caricamento.
Strategie di fallback specifiche per lingua per una tipografia coerente
Anche con un subsetting ottimale, può accadere che un file di font non venga caricato – a causa di errori di rete, incompatibilità del browser o limitazioni di licenza. In tal caso entra in gioco lo stack di fallback. Per 24 lingue, un font-stack globale non è sufficiente: un font di sistema che funziona bene per il tedesco potrebbe non essere adatto per l'arabo. Definite quindi stack di fallback separati per ogni versione linguistica, tarati sui font di sistema tipici della regione di destinazione. Utilizzate la funzione CSS @font-face con unicode-range per caricare, per ogni famiglia di font, solo i caratteri effettivamente necessari. Per la versione araba potreste indicare come fallback 'Traditional Arabic' o 'Tahoma', per quella greca 'GFS Didot' o 'Times New Roman'. Prestate attenzione alla compatibilità metrica: tramite size-adjust e ascent-override adattate visivamente il font di fallback a quello primario, riducendo al minimo i salti di layout. Testate questi fallback in tutte le lingue con un confronto automatizzato di screenshot, per assicurarvi che la leggibilità sia preservata anche in caso di errore. In questo modo evitate sorprese e garantite un'esperienza utente coerente in tutte le varianti linguistiche.
Ottimizzazione lato server: self-hosting, caching e strategie CDN
La distribuzione di web font tramite servizi esterni come Google Fonts o Adobe Fonts è comoda, ma presenta svantaggi per i progetti multilingue: in primo luogo, con 24 varianti linguistiche spesso è necessario effettuare più richieste a server diversi, aumentando i tempi di caricamento. In secondo luogo, non si conosce la strategia di caching del fornitore e non si ha controllo su tempi di inattività o privacy. Pertanto raccomandiamo il self-hosting di tutti i file dei font sul proprio server o su un CDN dedicato. Con il self-hosting potete ritagliare i subset dei font esattamente sulle vostre versioni linguistiche e dare priorità ai font critici tramite HTTP/2 Server Push o Preload Hints. Inoltre, il caching può essere controllato tramite intestazioni Cache-Control in modo che i font vengano caricati una sola volta per tutti i visitatori di una determinata versione linguistica. Un CDN con server edge vicini agli utenti riduce la latenza. Per 24 lingue con diverse regioni di destinazione, un CDN è essenziale: gli utenti in Finlandia caricano il subset finlandese da un nodo edge vicino, quelli a Malta corrispondentemente. Importante: impostate una regola di cache specifica per ogni versione linguistica, in modo che ad esempio il file subset tedesco venga memorizzato nella cache con una lunga validità (es. un anno), mentre per gli aggiornamenti dei font invalidate la cache cambiando il nome del file (fingerprinting). In questo modo garantite che i font vengano distribuiti rapidamente e siano sempre aggiornati, senza che gli utenti debbano attendere gli aggiornamenti.
Accessibilità e leggibilità: scelta dei font per tutti i gruppi di utenti
Il multilinguismo non significa solo rappresentare correttamente i caratteri, ma anche che il carattere tipografico sia ben leggibile per tutti gli utenti, indipendentemente da capacità visiva, dimensioni dello schermo o dispositivo. Pertanto, nella scelta del font, assicuratevi che le lettere siano sufficientemente distinguibili, specialmente per caratteri simili come 'rn' vs 'm' o '0' vs 'O'. Per le scritture latine sono adatti font sans-serif con grande x-height e forme aperte; per le scritture arabe sono importanti font con connessioni chiare e spazio interno sufficiente. Assicuratevi che il font non sgrani o che la spaziatura tra i caratteri non si alteri quando ingrandito al 200%. Utilizzate nel CSS font-size-adjust: from-font o impostate font di fallback espliciti con proporzioni simili per evitare salti di layout durante lo zoom. Un altro aspetto è il livello di contrasto: il testo sullo sfondo dovrebbe rispettare almeno WCAG-AA (4,5:1), per testi piccoli meglio AAA (7:1). Per 24 lingue ciò significa: testate ogni versione linguistica con un checker di contrasto, poiché alcuni font perdono contrasto in determinati spessori o stili corsivi. Anche la lunghezza della riga e l'interlinea dovrebbero essere adattati per ogni lingua – i testi arabi spesso richiedono un'altezza di riga maggiore rispetto a quelli latini. Integrate questi test nella vostra garanzia di qualità automatizzata (vedi sezione 4) per assicurarvi che tutti gli utenti – anche anziani o ipovedenti – possano cogliere al meglio i vostri contenuti.
blog.faqT
Posso utilizzare Google Fonts per siti multilingue nell'UE?
Tecnicamente sì, ma problematico dal punto di vista della privacy, poiché Google registra gli indirizzi IP dei visitatori. Per i siti UE è consigliabile un font ospitato autonomamente. Inoltre, Google Fonts offre solo una selezione limitata di caratteri multilingue; potresti dover combinare più famiglie, aumentando il carico di caricamento.
Come verifico se il mio font copre tutti i glifi necessari?
Utilizza strumenti come GlyphChecker o il test dell'intervallo Unicode di Wakamai Fondue. Inserisci i caratteri delle tue lingue target (es. İ turco, Ș rumeno). In alternativa, analizza il tuo sistema di gestione dei contenuti ed estrai tutti i codepoint Unicode per pagina linguistica per confrontarli con il font. In questo modo individui le lacune prima del lancio.
