Dlaczego w ogóle warto o tym pomyśleć
Zmniejszyć wagę czcionek to jeden z najszybszych sposobów na przyspieszenie ładowania stron i poprawę Core Web Vitals. Gdy prosimy przeglądarkę o pobranie rodziny z Google Fonts, często nieświadomie ściągamy kilka plików: różne wagi (400, 500, 700…), kursywę, a czasem nawet niepotrzebne podzestawy znaków. Każdy z tych elementów to osobny transfer. Efekt? Zbędne kilkadziesiąt, a czasem kilkaset kilobajtów na każdej odsłonie i widoczna zwłoka w wyrenderowaniu tekstu.
Dobra wiadomość jest taka, że większość tego balastu da się zredukować w kilka minut — a część optymalizacji można zautomatyzować.
Jak działa Google Fonts i co faktycznie się pobiera
Google Fonts serwuje zasoby przez CSS, który wskazuje przeglądarce dokładne pliki fontów do pobrania. Każda kombinacja: rodzina + waga + styl (normal/italic) + podzestaw znaków (subset) to osobny plik, zwykle w formacie WOFF2. Jeśli w motywie zadeklarujesz 6 wariantów tej samej czcionki, przeglądarka ściągnie 6 plików. Jeśli dodasz drugi krój — mnożysz liczbę żądań.
Do tego dochodzą subsety. Dla języka polskiego niezbędny jest zazwyczaj „latin-ext”. Jeśli nie określisz niczego, Google dobierze subset automatycznie, ale czasem motyw wymusi szeroki zakres (np. łaciński + cyrylica), co niepotrzebnie zwiększa objętość.
Jak zmniejszyć wagę czcionek krok po kroku
Poniżej znajdziesz zestaw technik, które realnie zmniejszają paczkę pobieranych fontów — od „szybkich zwycięstw”, po opcje dla perfekcjonistów.
Ogranicz liczbę rodzin
- Największy zysk daje prosta decyzja: jedna rodzina do treści + ewentualnie druga do nagłówków. Dwie różne rodziny serwów to już najczęściej kompromis estetyczny vs. wydajność. Trzy i więcej — to zwykle zbyt dużo.
Zredukuj odmiany (wagi i kursywy)
- Zamiast pełnej skali 100–900 użyj np. 400 (regular) i 700 (bold). Jeśli możesz, zrezygnuj z 500/600 i z kursywy, albo włącz ją tylko dla jednej wagi.
- Gdy naprawdę potrzebujesz półpogrubienia, rozważ użycie 600 zamiast 500, by pozostać przy dwóch plikach (400 i 600/700).
Dobierz właściwy subset (podzestaw znaków)
- Dla polskiego zazwyczaj wystarczy „latin-ext”. Unikaj ładowania wielojęzycznych zestawów, jeśli nie publikujesz w tych językach.
- Jeśli strona jest dwujęzyczna, ładuj różne subsety tylko tam, gdzie są potrzebne.
Użyj parametru text= do mikrosubsetu
- Gdy masz stronę typu landing page z ograniczonym zestawem znaków (np. nagłówek, kilka zdań), dodaj do URL Google Fonts parametr „text=” z dokładnym zestawem znaków użytych na stronie. Dzięki temu serwer zwróci mikro-wersję fontu zawierającą tylko te glify.
- Uwaga: świetne dla statycznych treści, ryzykowne dla dynamicznych (komentarze, tłumaczenia, wyszukiwarka).
Rozważ variable fonts, ale mądrze
- Czcionki zmienne potrafią zastąpić kilka plików jednym, który obsługuje zakres wag i stylów. Jeśli używasz wielu wariantów, variable font bywa lżejszy sumarycznie i upraszcza konfigurację.
- Jeżeli jednak potrzebujesz tylko dwóch wag, statyczne pliki 400 i 700 zwykle będą mniejsze niż jeden plik VF.
Serwuj tylko WOFF2, gdy to możliwe
- Google Fonts robi to automatycznie dla nowoczesnych przeglądarek. Jeśli kiedykolwiek przejdziesz na hostowanie lokalne, trzymaj w produkcji wyłącznie WOFF2 (a WOFF/EOT tylko jeśli naprawdę wspierasz bardzo stare przeglądarki).
Połącz rodzinę i wagi w jednym żądaniu
- API Google Fonts pozwala łączyć warianty: np. Inter:wght@400;700. Mniej żądań = mniejszy overhead HTTP, szybszy TTFB dla fontów.
Użyj local() i systemowych alternatyw
- W deklaracji @font-face ustaw najpierw local(). Jeśli użytkownik ma krój zainstalowany, przeglądarka użyje go zamiast pobierać. Alternatywnie, rozważ system font stack (Inter, Roboto, SF Pro, Segoe UI, system-ui), by całkiem zrezygnować z zewnętrznych czcionek na częściach serwisu.
Unikaj niepotrzebnych efektów i opcji
- Dodatkowe opcje (np. optyczne rozmiary, rzadkie style) to zazwyczaj większa paczka. Ładuj tylko to, co rzeczywiście widać.
Zadbaj o cache i spójne adresy
- Długi cache (immutable) i identyczny URL na wszystkich podstronach sprawi, że fonty pobiorą się tylko raz. Zmienianie kolejności wag albo różne parametry per podstrona utrudniają cache.
Pamiętaj: font-display nie zmniejsza wagi, ale poprawia UX
- „font-display: swap” nie obniża rozmiaru plików, lecz eliminuje „niewidzialny tekst” (FOIT) i przyspiesza perceived performance. Warto włączyć zawsze.
Praktyka w WordPress (Gutenberg): szybkie recepty
Wybór mniejszej liczby wag w motywie
- W nowoczesnych motywach z plikiem theme.json ogranicz listę dostępnych wag do 400 i 700. Dzięki temu edytor i front nie będą wymuszać pobierania zbędnych wariantów.
- W ustawieniach „Typografia” (Customizer, panel motywu lub wtyczka do czcionek) odznacz kursywy i półpogrubienia, jeśli nie są potrzebne.
Łączenie i optymalizacja zapytań do Google Fonts
- Wtyczki typu WP Rocket lub Perfmatters potrafią połączyć zapytania, wymusić „display=swap” i ograniczyć liczbę żądań.
Hostowanie lokalne + subsetting
- Wtyczka OMGF (Optimize My Google Fonts) pobiera czcionki z Google i pozwala je hostować lokalnie oraz wykonać subsetting (ograniczenie do wybranych znaków).
- Alternatywnie użyj narzędzi deweloperskich (np. fonttools/pyftsubset), by wygenerować własne, ultra-lekkie warianty i załadować je przez functions.php lub theme.json.
Dequeue zbędnych fontów
- Jeśli motyw i wtyczka ładują różne kroje „w tle”, użyj Perfmatters, Asset CleanUp lub ręcznych hooków, by wyrejestrować nieużywane zasoby.
Testuj Lighthouse i WebPageTest
- Po każdej zmianie sprawdź metryki: Transfer Size dla fontów, czas do renderu (FCP/LCP), liczbę żądań. Cel: minimalna liczba plików i jak najmniejszy rozmiar.
Przykładowe adresy i parametry, które naprawdę robią różnicę
Dwie wagi, jeden subset i swap:
Wariant z parametrem text= (landing, statyczny nagłówek):
Variable font (gdy potrzebujesz wielu wag):
Pamiętaj: parametr text= jest świetny dla stałych treści. W dynamicznych sekcjach lepiej trzymać pełny zestaw znaków, by nie „zgubić” polskich liter lub znaków z wyszukiwarki.
Najczęstsze błędy i jak ich uniknąć
Ładowanie kursywy dla każdej wagi
- Jeśli kursywa pojawia się tylko w podpisach, wystarczy jedna waga italic. Unikaj duplikacji.
Zbyt szerokie subsety
- Polska wersja nie potrzebuje cyrylicy czy greki. Zostaw latin-ext, o ile publikujesz po polsku.
Dwie rodziny robiące to samo
- Headline w Display i treść w Sans — OK. Dwie podobne sansy „bo ładne”? To tylko koszt.
Nieoptymalna konfiguracja URL
- Rozdzielanie wag na kilka adresów CSS zwiększa liczbę żądań. Konsoliduj je w jeden link.
Brak cache lub zmienny URL per podstrona
- Każda drobna różnica parametru to nowy plik w cache. Utrzymuj spójność konfiguracji.
Kiedy postawić na systemowe kroje zamiast zewnętrznych
Jeśli Twoja strona stawia na szybkość i prostotę (blog, dokumentacja, panel), rozważ stack systemowy: system-ui, -apple-system, Segoe UI, Roboto, Helvetica, Arial. Nie pobierasz żadnego zasobu, a typografia nadal wygląda nowocześnie i czytelnie. To największa „redukcja wagi” z możliwych — do zera.
Podsumowanie: co da najwięcej w najkrótszym czasie
- Ogranicz do 1–2 rodzin i dwóch wag (400/700).
- Włącz subset „latin-ext” i nic więcej dla polskiego.
- Połącz warianty w jednym żądaniu do Google Fonts i ustaw display=swap.
- Rozważ variable font, gdy rzeczywiście korzystasz z wielu wag/stylów.
- Dla landingów użyj parametru text=, by stworzyć mikro-subset.
- W WordPress skorzystaj z OMGF/Perfmatters/WP Rocket, by zautomatyzować optymalizację i hostowanie lokalne.
Wdrożenie tych kilku zmian potrafi ściąć rozmiar zasobów fontów o kilkadziesiąt procent, a czasem nawet bardziej. Efekt jest odczuwalny: szybsze renderowanie, lepsze FCP/LCP i bardziej responsywne wrażenia użytkownika — bez kompromisów w jakości typografii.
