2025-07-02 · Redakcja Baduno · 8 blog.readMin · Blog & Wiedza
Czcionki internetowe dla 24 języków: Wybór krojów, subsetting, wydajność
Czcionka, która obsługuje niemiecki, grecki, maltański i arabski? Rzadko się zdarza – a jeśli już, jest ciężka. Strategie szybkiej i pięknej wielojęzyczności.
Problem pokrycia
Łacina ze wszystkimi znakami diakrytycznymi UE, greka, cyrylica, a do tego pismo arabskie: Niewiele rodzin krojów pokrywa to wszystko dobrze. Praktycznym rozwiązaniem są pary krojów – rodzina łacińsko-grecko-cyrylicka plus specjalistyczny krój RTL, dopasowane do siebie pod względem szarości i wysokości.
Subsetting oszczędza ogromnie
Pełne fonty Unicode ważą setki kilobajtów. Podzbiory dla poszczególnych systemów pisma – ładowane tylko tam, gdzie potrzebne – redukują je do ułamka: Wersja RTL ładuje krój RTL, niemiecka nie.
Ładowanie bez skoków
font-display:swap natychmiast wyświetla tekst czcionką systemową, a potem zamienia – przed skokami układu chronią metrycznie kompatybilne fallbacki i size-adjust. Hostowane lokalnie zamiast z obcego CDN: szybciej i z większą ochroną prywatności.
Typografia dla każdego systemu pisma
Pismo arabskie wymaga większej interlinii i często o jeden punkt więcej stopnia; spacjonowanie wielkich liter działa tylko w łacinie. System projektowy, który zna takie reguły dla każdego systemu pisma, zamienia 24 języki w jeden układ – zamiast 25 kompromisów.
Czcionki zmienne: Elastyczność z przeszkodami
Czcionki zmienne obiecują zmniejszoną liczbę plików, łącząc kilka krojów (pogrubiony, kursywa itp.) w jednym pliku. Dla wielojęzycznych stron z 24 językami jest to kuszące: zamiast 24 × 4 = 96 statycznych plików tylko 24 zmienne? Jednak ostrożnie: Czcionki zmienne o szerokim zakresie językowym (łacina, greka, cyrylica, arabski) są rzadkie i często duże. Subsetting staje się ponadto bardziej złożony, ponieważ osie zmienności wpływają na zestaw znaków. Subsetowana czcionka zmienna może w zależności od wartości osi wymagać innych glifów, dlatego trzeba albo przechowywać wszystkie subzbiory, albo generować je dynamicznie. Praktyczne jest zastosowanie czcionek zmiennych dla jednej rodziny systemów pisma (np. łacina + greka) i statycznych dla drugiej (np. arabski), aby kontrolować rozmiar plików. Wczytuj czcionki zmienne za pomocą font-weight: 100 900 i font-stretch: 75% 125%, zamiast pojedynczych krojów – ale przetestuj wyświetlanie we wszystkich językach i przeglądarkach, ponieważ czcionki zmienne przy subsettingu i rasteryzacji czasami dają nieoczekiwane wyniki.
Zgodne z licencją użycie czcionek w 24 językach
Strona prawna jest często niedoceniana. Licencja na czcionkę zwykle dotyczy określonej liczby wyświetleń strony lub domeny; przy 24 wariantach językowych możesz napotkać ograniczenia w zależności od licencji. Niektórzy dostawcy wyraźnie zabraniają subsettingu lub osadzania w dynamicznych treściach. Upewnij się, że licencja obejmuje wszystkie języki – zwłaszcza znaki specjalne, takie jak tureckie İ, rumuńskie Ș czy maltańskie Ħ, często są traktowane jako rozszerzony zestaw znaków i nie zawsze wchodzą w skład standardowego pakietu. W przypadku projektów unijnych zaleca się licencję Unlimited lub Enterprise, która pozwala na subsetting i użycie na wielu domenach. Sprawdź również, czy licencja na czcionkę jest ważna dla używanej przez Ciebie technologii czcionek (np. WOFF2). Narzędzie do doradztwa licencyjnego (np. od Fontstand) może pomóc uniknąć konfliktów – zapisz warunki licencji dla każdej czcionki w swoim przewodniku stylu, aby nie były potrzebne poprawki.
Konkurencja formatów: WOFF2, subsetowane czcionki zmienne i zakres Unicode
Wybór formatu pliku wpływa na czas ładowania i kompatybilność. WOFF2 jest dziś standardem i zapewnia około 30-50% lepszą kompresję niż WOFF. Jeśli używasz czcionek zmiennych, powinieneś sprawdzić, czy docelowa przeglądarka obsługuje WOFF2 z osiami zmiennymi (obecnie wszystkie nowoczesne przeglądarki). W przypadku starszych przeglądarek (IE11) musisz przygotować statyczne pliki WOFF jako fallback. Skuteczna sztuczka: użyj zakresu Unicode w @font-face, aby wczytać tylko faktycznie potrzebny zestaw znaków – podobnie jak subsetting, ale sterowane po stronie serwera. Połącz to z font-display: swap; optymalizację ładowania możesz wesprzeć przez preload dla krytycznych wariantów czcionek (np. podstawowa czcionka dla łaciny). Przykład praktyczny: dla strony niemieckiej wczytuj tylko subset łacina+umlauty (ok. 30 KB), dla strony greckiej subset łacina+greka (ok. 50 KB), dla strony arabskiej subset łacina+arabski (ok. 80 KB). Dzięki temu nawet przy 24 językach całkowity pobór danych na odwiedzającego pozostaje poniżej 100 KB czcionek.
Czcionka, która obsługuje niemiecki, grecki, maltański i arabski? Rzadko się zdarza – a jeśli już, jest ciężka. Strategie szybkiej i pięknej wielojęzyczności.
Automatyczna kontrola jakości wyświetlania czcionek
Aby we wszystkich 24 wariantach językowych nie brakowało glifów lub nie wyglądały one na poszarpane, należy wbudować automatyczne testy w swój potok CI/CD. Narzędzia takie jak FontProof, Wakamai Fondue czy skrypt Pythona fontdiff porównują renderowane zrzuty ekranu każdej wersji językowej z referencyjnym zrzutem ekranu. Można też użyć Puppeteer, aby otworzyć każdą stronę, załadować czcionkę i sprawdzić luki (za pomocą właściwości CSS font-family: …; font-unicode-range). Jeszcze bardziej systematycznie: wyodrębnij wszystkie punkty kodowe Unicode występujące w HTML dla każdej wersji językowej i porównaj je z glifami obecnymi w podzbiorze. Jeśli brakuje znaku, kompilacja zostaje przerwana lub wyświetlane jest ostrzeżenie. Testy te powinny również sprawdzać czytelność ligatur lub alternatywnych znaków (np. arabskie formy inicjalne). Zintegruj również kontrolę budżetu wydajności: rozmiar czcionki na język nie może przekraczać określonego progu. W ten sposób zapewniasz, że wielojęzyczność nie wpływa negatywnie na czas ładowania.
Wspomagane przez AI wyodrębnianie podzbiorów: efektywność dzięki automatyzacji z zapewnieniem jakości
Ręczne zarządzanie subsettingiem dla 24 języków jest czasochłonne i podatne na błędy. Nowoczesne narzędzia budowlane, takie jak glyphhanger czy HarfBuzz, mogą automatycznie generować zestawy znaków na podstawie faktycznie występujących w treści znaków. Proces staje się jeszcze bardziej wydajny, gdy użyjesz modeli AI, które przewidują potrzebne bloki Unicode na podstawie wersji językowych. Sieć neuronowa wytrenowana na wielojęzycznych stronach internetowych może z dużą trafnością określić, które glify są wymagane dla danego języka – od podstawowych znaków łacińskich przez cyrylickie uzupełnienia po arabskie ligatury. Automatycznie wygenerowany subset jest następnie poddawany ręcznej weryfikacji przez native speakera, aby upewnić się, że nie brakuje rzadkich, ale ważnych znaków (np. cytaty historyczne, znaki specjalne w nazwach firm). To połączenie przyspieszenia przez AI i ludzkiej kontroli redukuje tworzenie subsetów z dni do godzin, przy zachowaniu równie wysokiej jakości. Zintegruj skrypt ze swoim potokiem CI/CD, aby przy każdej aktualizacji treści zestawy znaków były automatycznie generowane i testowane. W ten sposób zapewniasz, że pliki czcionek są zawsze aktualne, nie wpływając na wydajność ładowania.
Strategie fallbacku specyficzne dla języka dla spójnej typografii
Nawet przy optymalnym subsettingu może się zdarzyć, że plik czcionki nie zostanie załadowany – z powodu błędu sieci, niekompatybilności przeglądarki lub ograniczeń licencyjnych. Wtedy zadziała stos fallbacku. Dla 24 języków globalny stos czcionek nie wystarczy: systemowa czcionka, która dobrze wygląda po niemiecku, może być nieodpowiednia dla arabskiego. Dlatego zdefiniuj dla każdej wersji językowej oddzielne stosy fallbacku dostosowane do typowych czcionek systemowych w danym regionie. Użyj do tego funkcji CSS @font-face z unicode-range, aby ładować tylko te znaki, które są faktycznie potrzebne dla danej rodziny czcionek. Dla wersji arabskiej możesz podać jako fallback 'Traditional Arabic' lub 'Tahoma', dla greckiej 'GFS Didot' lub 'Times New Roman'. Zwróć uwagę na zgodność metryczną: za pomocą size-adjust i ascent-override dostosuj wizualnie czcionkę fallbackową do czcionki podstawowej, aby zminimalizować skoki układu. Przetestuj te fallbacki we wszystkich językach za pomocą zautomatyzowanego porównania zrzutów ekranu, aby upewnić się, że czytelność jest zachowana nawet w przypadku błędu. W ten sposób unikniesz niespodzianek i zapewnisz spójne doświadczenie użytkownika we wszystkich wariantach językowych.
Optymalizacja po stronie serwera: self-hosting, caching i strategie CDN
Dostarczanie czcionek internetowych za pośrednictwem zewnętrznych usług, takich jak Google Fonts czy Adobe Fonts, jest wygodne, ale niesie ze sobą wady dla projektów wielojęzycznych: po pierwsze, przy 24 wariantach językowych często trzeba wysyłać wiele zapytań do różnych serwerów, co wydłuża czas ładowania. Po drugie, nie znasz strategii buforowania dostawcy i nie masz kontroli nad przestojami ani ochroną danych. Dlatego zalecamy self-hosting wszystkich plików czcionek na własnym serwerze lub dedykowanym CDN. Dzięki self-hostingowi możesz precyzyjnie dostosować podzbiory czcionek do swoich wersji językowych i priorytetyzować krytyczne czcionki za pomocą HTTP/2 Server Push lub Preload-Hints. Ponadto można kontrolować buforowanie za pomocą nagłówków Cache-Control, tak aby czcionki były ładowane tylko raz dla wszystkich odwiedzających daną wersję językową. CDN z serwerami brzegowymi w pobliżu użytkowników skraca opóźnienia. Dla 24 języków o różnych regionach docelowych CDN jest niezbędny: użytkownicy w Finlandii ładują fiński podzbiór czcionek z pobliskiego węzła brzegowego, użytkownicy na Malcie odpowiednio. Ważne: ustaw dla każdej wersji językowej osobną regułę buforowania, aby np. niemiecki plik podzbioru był buforowany z długim okresem ważności (np. rok), a podczas aktualizacji czcionek unieważniaj pamięć podręczną poprzez zmianę nazwy pliku (fingerprinting). W ten sposób zapewnisz szybkie dostarczanie czcionek i ich aktualność, bez zmuszania użytkowników do oczekiwania na aktualizacje.
Dostępność i czytelność: wybór czcionek dla wszystkich grup użytkowników
Wielojęzyczność oznacza nie tylko prawidłowe wyświetlanie znaków, ale także to, że czcionka jest dobrze czytelna dla wszystkich użytkowników – niezależnie od zdolności widzenia, rozmiaru ekranu czy urządzenia. Dlatego przy wyborze czcionki należy zwrócić uwagę na wystarczającą rozróżnialność liter, szczególnie w przypadku podobnych znaków, takich jak 'rn' vs 'm' czy '0' vs 'O'. W przypadku pism łacińskich sprawdzają się czcionki bezszeryfowe z dużą wysokością x i otwartymi formami; w przypadku pism arabskich ważne są czcionki z wyraźnymi połączeniami i wystarczającą przestrzenią wewnętrzną. Upewnij się, że czcionka przy powiększeniu do 200% nie postrzępia się ani nie powoduje zmiany odstępów między znakami. W CSS użyj font-size-adjust: from-font lub ustaw jawne czcionki zastępcze o podobnych proporcjach, aby uniknąć skoków układu podczas powiększania. Kolejnym aspektem jest poziom kontrastu: tekst na tle powinien spełniać co najmniej WCAG-AA (4,5:1), a przy małej czcionce lepiej AAA (7:1). Dla 24 języków oznacza to: przetestuj każdą wersję językową za pomocą narzędzia do sprawdzania kontrastu, ponieważ niektóre czcionki przy określonych grubościach kresek lub kursywie tracą kontrast. Długość wiersza i odstępy między wierszami również powinny być dostosowane do języka – teksty arabskie często wymagają większej wysokości wiersza niż łacińskie. Zintegruj te testy ze zautomatyzowanym zapewnianiem jakości (patrz sekcja 4), aby mieć pewność, że wszyscy użytkownicy – także starsi lub z wadami wzroku – mogą optymalnie odbierać Twoje treści.
blog.faqT
Czy mogę używać Google Fonts na wielojęzycznych stronach UE?
Technicznie tak, ale problematyczne pod względem ochrony danych, ponieważ Google rejestruje adresy IP odwiedzających. W przypadku stron UE zaleca się samodzielne hostowanie czcionek. Ponadto Google Fonts oferuje tylko ograniczony wybór czcionek wielojęzycznych; konieczne może być łączenie kilku rodzin, co zwiększa obciążenie ładowania.
Jak sprawdzić, czy moja czcionka obejmuje wszystkie potrzebne glify?
Skorzystaj z narzędzi takich jak GlyphChecker lub test zakresu Unicode od Wakamai Fondue. Wprowadź znaki swoich języków docelowych (np. tureckie İ, rumuńskie Ș). Alternatywnie przetwórz system zarządzania treścią i wyodrębnij wszystkie punkty kodowe Unicode dla każdej strony językowej, aby porównać je z czcionką. W ten sposób wykryjesz luki przed publikacją.
