Jak zoptymalizować czcionki na stronie

Fonty mają realny wpływ na doświadczenie użytkownika: mogą spowalniać pierwsze renderowanie, powodować migotanie tekstu i przesunięcia układu, ale też budują spójność marki i czytelność. Ten przewodnik przeprowadzi Cię krok po kroku od audytu, przez wybór formatów i strategię ładowania, po wdrożenie i monitoring. Zobaczysz, jak małymi zmianami zmniejszyć rozmiar plików, przyspieszyć render i poprawić wydajność bez poświęcania jakości typografii.

Audyt i planowanie optymalizacji fontów

Inwentaryzacja fontów i glifów

Zacznij od spisu wszystkich rodzin, stylów i wag używanych w serwisie. Zanotuj każdy plik, jego rozmiar, format i miejsce ładowania. Ustal zestaw znaków potrzebny dla języków, które obsługujesz (np. łaciński rozszerzony dla polskiego). W wielu projektach realnie używasz niewielkiego podzbioru glifów w porównaniu do pełnych rodzin wspierających kilkadziesiąt alfabetów.

• Zidentyfikuj, czy ikony to plik fontu – rozważ migrację do SVG symboli.
• Policz faktycznie używane wagi (czy naprawdę potrzebujesz 100, 300, 400, 500, 600, 700?).
• Sprawdź, czy italiki są potrzebne w całym serwisie, czy tylko w blogu.

Mapowanie użycia i priorytety

Przejrzyj kluczowe ścieżki użytkownika: strona główna, listing, karta produktu, koszyk. Oznacz teksty krytyczne dla pierwszego wrażenia (np. nagłówek hero, cena produktu) oraz elementy wtórne (drobne podpisy, stopka). Im mniej stylów krytycznych na start, tym prostsze i szybsze ładowanie. Wprowadź zasadę: minimalny zestaw dla pierwszego widoku, reszta na żądanie lub po osadzeniu w pamięci podręcznej przeglądarki.

Metryki i budżety wydajnościowe

Zdefiniuj budżety: maksymalny łączny rozmiar fontów na widok, maksymalny czas blokowania renderu przez CSS oraz akceptowalny poziom przesunięcia układu (CLS). Dodaj do tego wskaźniki wpływu na LCP, FCP i INP. Dobrą praktyką jest traktowanie fontów jak zasób o krytycznym znaczeniu dla UX, ale ograniczony budżetem podobnie jak obrazy czy skrypty.

Format, kompresja i dystrybucja

Wybór formatów

Domyślnym wyborem powinien być format WOFF2 – zapewnia najlepszą kompresję i szerokie wsparcie w nowoczesnych przeglądarkach. Dla zgodności możesz opcjonalnie udostępnić WOFF jako fallback dla starszych środowisk. Unikaj TTF/OTF w produkcji (za duże) oraz EOT/SVG (przestarzałe). Upewnij się, że serwer zwraca poprawny typ MIME (font/woff2 dla WOFF2, font/woff dla WOFF).

Przycinanie glifów i unicode-range

Największą oszczędność przynosi subsetting – wycięcie z pliku znaków nieużywanych w Twojej witrynie. Dla wersji łacińskich z polskimi diakrytykami to zwykle kilkaset glifów zamiast tysięcy. Kolejnym krokiem jest podział według skryptu (np. Latin, Cyrillic) lub funkcji (cyfry, symbole), a następnie zastosowanie selektywnego ładowania przez unicode-range w deklaracjach fontu. Przeglądarka pobierze tylko te pliki, które pokrywają znaki występujące na stronie.

• Twórz osobne subsety dla krytycznego tekstu interfejsu i dla rzadko używanych znaków.
• Zadbaj o pełny zestaw polskich liter: ą, ć, ę, ł, ń, ó, ś, ź, ż (małe i wielkie).
• Przetestuj znaki walut, symbole matematyczne, strzałki – często są w innym zakresie Unicode.

Kompresja i transport

Serwuj pliki jako statycznie skompresowane, najlepiej Brotli na najwyższym sensownym poziomie dla WOFF i Gzip dla nietypowych fallbacków. Wykorzystaj HTTP/2 lub HTTP/3 dla lepszego multipleksowania i ograniczenia opóźnień. Utrzymuj krótką ścieżkę sieciową – im bliżej użytkownika, tym lepiej, ale unikaj zewnętrznych dostawców, jeśli nie masz gwarancji stabilności, kontroli wersji i licencji.

Gdzie hostować: własny origin czy CDN

Samodzielne hostowanie daje kontrolę nad nagłówkami, wersjonowaniem i zgodnością z polityką prywatności. CDN jest przydatny, gdy masz globalną publiczność i chcesz zmniejszyć TTFB dzięki punktom brzegowym. Pamiętaj o CORS, jeśli fonty będą ładowane z innego hosta niż dokument – bez odpowiednich nagłówków żądania mogą się nie powieść lub font nie zostanie z-cache’owany współdzielone.

Strategia ładowania i renderowania

Preconnect, DNS-prefetch i preload

Jeśli fonty pochodzą z innego hosta, rozpocznij od wczesnego nawiązania połączenia (preconnect) i ewentualnie DNS-prefetch. Dla kluczowych zestawów użyj preload, aby przeglądarka pobrała pliki równolegle z CSS. Preload stosuj rozważnie: tylko dla zasobów faktycznie używanych w pierwszym widoku i koniecznie z atrybutem as=font oraz crossorigin, jeśli pochodzą z innego hosta. Utrzymuj spójne ścieżki i nazwy, aby uniknąć podwójnych pobrań.

Kontrola renderu przez font-display

W deklaracji @font-face ustaw font-display zgodnie z rolą danego kroju:

• swap – szybki tekst fallback, a po pobraniu płynna zamiana; dobry dla treści głównych.
• optional – przeglądarka może w ogóle nie pobrać fontu przy wolnym łączu; świetne dla ozdobnych napisów.
• fallback – krótka faza blokady, potem zamiana; kompromis między estetyką a szybkością.
• block – unikać; powoduje niewidoczny tekst (czarna dziura) do czasu pobrania.

Zapobieganie FOIT/FOUT i dopasowanie metryk

FOIT to niewidoczny tekst, FOUT to zauważalna zmiana kroju. Minimalizujesz je przez dobór fallbacków o zbliżonych metrykach i przez CSS-owe dopasowanie. Dobierz rodzinę zapasową (np. system-ui, Arial) tak, by szerokości i wysokości x były zbliżone do docelowego kroju. Nowoczesne przeglądarki obsługują size-adjust, ascent-override, descent-override i line-gap-override w @font-face – pozwalają one dostroić metryki fallbacków, ograniczając przesunięcia układu i skoki linii.

Jeśli mimo wszystko pojawia się FOIT lub nadmierny FOUT, rozważ zmniejszenie liczby wag w pierwszym widoku, włączenie optional dla niekrytycznych krojów oraz skrócenie czasu blokady przez preload i odpowiednie priorytety.

Krytyczny zestaw FOFT i ładowanie etapowe

Skuteczny wzorzec to FOFT (Flash of Faux Text) w wersji krytycznego subsetu: najpierw ładujesz bardzo mały plik z podstawowymi glifami używanymi nad linią załamania (może nawet bez znaków rzadkich), a następnie w tle dogrywasz pełniejszy zestaw. Dla wagą regularną i bold przygotuj mini-subset tylko dla nagłówków i CTA, a pozostałe style i skrypty doładuj po interakcji lub gdy sieć jest szybka (Network Information API lub lazy-load po onload).

Implementacja w CSS i aplikacjach

Deklaracje @font-face, nazewnictwo i porządek

Utrzymuj spójne, krótkie nazwy rodzin i wag. Dla każdej wagi i stylu użyj osobnego @font-face, deklarując font-style, font-weight oraz unicode-range dla subsetów. Wyłącz sztuczne generowanie kursywy i pogrubienia (font-synthesis: none) tam, gdzie estetyka ma znaczenie. Unikaj local() w @font-face, jeśli chcesz pełnej kontroli nad wersją kroju – lokalne instalacje użytkowników mogą wprowadzać różnice w metrykach i kształtach.

Umieść krytyczne deklaracje blisko topu arkusza krytycznego. Jeżeli korzystasz z bundlera, rozważ rozdzielenie CSS: krytyczny inline w dokumencie, reszta ładowana asynchronicznie. Pamiętaj, by preloadać tylko te pliki, które pokrywa krytyczny CSS – inaczej przeglądarka wykona zbędne pobrania.

Fonty zmienne (variable fonts)

Kroje zmienne pozwalają jednym plikiem obsłużyć wiele wag i szerokości. To często mniejszy koszt niż kilka osobnych plików, zwłaszcza przy inteligentnym subsecie i WOFF2. Kluczowe praktyki: korzystaj z zarejestrowanych osi (wght, wdth, ital, opsz), ustaw font-optical-sizing na auto, a font-variation-settings zmieniaj tylko tam, gdzie to potrzebne. Pamiętaj, że pełny zestaw osi i glifów może być cięższy – subsetuj również fonty zmienne.

• Ogranicz liczbę używanych wartości osi; mapuj design system na 2–3 stopnie wagi i szerokości.
• Dla starszych przeglądarek przygotuj statyczne fallbacki (wght 400/700).
• Utrzymuj spójność metryk między wersją zmienną a fallbackiem, by uniknąć CLS.

Skalowanie typografii i stylów

Zdefiniuj siatkę typograficzną: skale dla nagłówków, akapitów, podpisów, z wyraźną hierarchią. Ustal domyślną wysokość linii i odstępy tak, aby mieściły się w metrykach fallbacku. W miejscach, gdzie treść dynamicznie się zmienia (np. ceny, liczby), używaj szerokości cyfr tablicowych (font-variant-numeric: tabular-nums), by minimalizować skoki układu. W formularzach i komponentach o ścisłej geometrii stawiaj na bezpieczne fallbacki systemowe.

SSR i SPA: integracja z frameworkami

W aplikacjach SSR preloadaj kluczowe pliki w HTML i wstrzykuj krytyczny CSS inline, aby uniknąć flashu nieostylowanego tekstu. W SPA zadbaj, by deklaracje @font-face były dostępne od pierwszego renderu – nie ładuj ich dopiero po hydratacji. Frameworkowe narzędzia do fontów potrafią automatyzować subset, preload i self-hosting; korzystaj z nich, ale kontroluj rozmiary i wyniki w audytach.

Cache, wersjonowanie, monitoring i bezpieczeństwo

Nagłówki cache i strategia

Skonfiguruj długie cache dla fontów: Cache-Control public, max-age na rok i immutable dla wersjonowanych plików. Zadbaj o ETag lub najlepiej fingerprint w nazwie pliku, aby unieważnianie było natychmiastowe po wdrożeniu nowej wersji. Dla serwerów proxy i CDN ustaw właściwe Vary tam, gdzie to konieczne. Stosuj rozsądne cachowanie także w Service Workerze, jeśli używasz PWA – strategia cache-first z rzadką rewalidacją zwykle się sprawdza.

Wersjonowanie i porządek plików

Wprowadź konwencję nazewnictwa z hashami treści (np. Family-regular-latin-7f3a.woff2). Utrzymuj katalogi per rodzina i per subset, a mapę importów trzymaj w jednym miejscu w repozytorium. Zautomatyzuj generowanie subsetów i publikację poprzez skrypty w CI, aby uniknąć ręcznych pomyłek i niespójności między środowiskami.

Monitoring i testy

Regularnie uruchamiaj audyty Lighthouse i mierniki RUM, aby ocenić wpływ fontów na Core Web Vitals. W DevTools śledź Waterfall, priorytety zasobów i Coverage, aby wykryć nieużywane subsety. WebPageTest i testy na wolniejszych łączach pomogą zobaczyć, czy strategia optional lub swap rzeczywiście poprawia czas do czytelnego tekstu. Zdefiniuj alerty, jeżeli rozmiary plików lub czas pobrania przekroczą budżety.

Bezpieczeństwo, licencje i zgodność

Fonty ładowane z innego hosta wymagają CORS (nagłówki Access-Control-Allow-Origin). W polityce CSP ustaw font-src na zaufane domeny i najlepiej ograniczaj do własnego hosta i CDN. Weryfikuj licencje – niektóre zabraniają self-hostingu lub wymagają atrybucji. Kontroluj MIME type i unikaj inline’owania dużych fontów w CSS – utrudnia to cache i wersjonowanie.

Checklist przed wdrożeniem

• Minimalny zestaw rodzin, wag i stylów na pierwszy widok.
• Subsekcja glifów i unicode-range dla języków i rzadkich symboli.
• WOFF2 jako domyślny format, poprawne typy MIME.
• Preload tylko dla realnie używanych plików, z crossorigin i as=font.
• font-display dopasowany do roli kroju (swap/optional/fallback).
• Dopasowanie metryk fallbacków przez size-adjust i override’y.
• Długie cache z fingerprintami, polityka unieważniania.
• RUM i audyty pod kątem LCP/FCP/CLS/INP.
• Polityka CSP i CORS dla fontów, zgodność licencyjna.