Jak hostować fonty lokalnie zamiast używać Google Fonts

Dlaczego warto hostować Google Fonts samodzielnie?

Google Fonts ułatwiło dobrą typografię. Dodajesz arkusz stylów, wybierasz kilka grubości i publikujesz stronę. Przez lata był to rozsądny domyślny wybór dla małych zespołów.

Kompromis polega na tym, że przeglądarka każdego odwiedzającego kontaktuje się z usługą strony trzeciej, aby pobrać CSS fontu i pliki fontów. Ma to dwie konsekwencje.

Po pierwsze, dodaje zewnętrzną zależność do renderowania. Jeśli CSS fontu jest wolny, zablokowany albo niedostępny w regionie lub sieci użytkownika, strona czeka albo przechodzi na font zastępczy.

Po drugie, pojawia się kwestia prywatności. Żądanie fontu może ujawnić stronie trzeciej adres IP użytkownika, user agent, kontekst polityki referrera oraz informacje o czasie. Google Fonts deklaruje, że nie ustawia plików cookie przez Fonts API, ale „brak cookies” to nie to samo co „brak danych osobowych”. W ramach GDPR/RODO adres IP nadal może być w określonym kontekście daną osobową.

Samodzielne hostowanie fontów nie jest automatycznie wymagane dla każdej witryny i nie jest to porada prawna. Jednak dla stron europejskich, sektora publicznego, ochrony zdrowia, edukacji, finansów albo każdego zespołu, który chce ograniczyć niepotrzebne żądania do stron trzecich, lokalne hostowanie jest zwykle czystszym wyborem.

Często jest też korzystne dla wydajności, jeśli zostanie wykonane dobrze. Kluczowe jest „wykonane dobrze”. Skopiowanie sześciu plików fontów do /assets/fonts/ i ładowanie ich wszystkich na każdej stronie może być gorsze niż używanie hostowanej usługi. Jeśli chcesz poznać szerszy kontekst wydajności, nasz wcześniejszy tekst o tym, dlaczego fonty webowe nadal są najłatwiejszą wygraną wydajnościową na większości stron, omawia typowe wzorce marnotrawstwa.

Co się zmienia przy samodzielnym hostowaniu

Gdy używasz Google Fonts w typowy sposób, strona robi to:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

Przeglądarka najpierw pobiera CSS z fonts.googleapis.com, a następnie pliki fontów z fonts.gstatic.com.

Gdy hostujesz fonty samodzielnie, strona powinna pobierać zarówno CSS, jak i pliki fontów z Twojej własnej domeny:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

To usuwa żądanie fontu do strony trzeciej. Sprawia też, że to Ty odpowiadasz za wybór formatów plików, nagłówki cache, fonty zastępcze i aktualizacje.

Warto potraktować tę odpowiedzialność poważnie. Fonty znajdują się na krytycznej ścieżce renderowania. Słaba konfiguracja fontów może powodować niewidoczny tekst, przesunięcia układu i wolne pierwsze renderowanie.

Krok 1: Sprawdź, czego naprawdę używasz

Zanim cokolwiek pobierzesz, wypisz rodziny fontów, grubości, style i zestawy znaków, których Twoja strona naprawdę potrzebuje.

Typowa strona marketingowa może potrzebować:

• Regular 400 dla tekstu głównego
• Semibold 600 albo bold 700 dla nagłówków i przycisków
• Italic 400 tylko wtedy, gdy projekt rzeczywiście używa kursywy
• Tylko zestawu Latin, chyba że strona obsługuje więcej języków

Podchodź sceptycznie do starych ustawień domyślnych design systemu. Wiele stron ładuje 300, 400, 500, 600, 700, kursywy i wiele skryptów tylko dlatego, że ktoś kiedyś zaznaczył je w selektorze fontów.

W DevTools przeglądarki otwórz panel Network, przefiltruj po „font”, przeładuj stronę i sprawdź, które pliki są pobierane. Następnie przejrzyj CSS pod kątem użycia font-weight. Jeśli Twój CSS nigdy nie używa 300, nie hostuj 300.

Jeśli później oceniasz wpływ zmian, Lighthouse może pomóc, ale nie traktuj jego wyniku jako całej historii. Używaj go jako narzędzia diagnostycznego, a nie sędziego. Mamy osobny przewodnik o czytaniu raportu Lighthouse bez paniki, który przydaje się przy ustalaniu priorytetów poprawek związanych z fontami.

Krok 2: Pobierz właściwe pliki fontów

Google Fonts oferuje fonty open-source. Możesz pobrać je ze strony Google Fonts albo z odpowiedniego repozytorium projektu fontu. Sprawdź licencję, ale większość Google Fonts jest rozpowszechniana na otwartych licencjach, takich jak SIL Open Font License albo Apache License.

Dla webu preferuj WOFF2. Jest szeroko wspierany przez nowoczesne przeglądarki i zwykle znacznie mniejszy niż TTF lub OTF. W 2026 roku bezpośrednie serwowanie TTF przeglądarkom rzadko jest uzasadnione w publicznych witrynach.

Rozsądna struktura katalogów wygląda tak:

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

Używaj opisowych nazw plików. Po sześciu miesiącach font.woff2 będzie irytujące. inter-latin-600.woff2 jest nudne i użyteczne.

Jeśli Twoja strona korzysta z systemu budowania, przechowuj fonty źródłowe w jasnym miejscu i pozwól pipeline’owi budowania kopiować zoptymalizowane pliki do publicznego katalogu zasobów.

Krok 3: Stosuj subsetting fontów tam, gdzie ma to sens

Subsetting oznacza usunięcie znaków, których nie potrzebujesz. Pełny font może zawierać Latin, Cyrillic, Greek, Vietnamese, symbole i wiele funkcji OpenType. Jeśli Twoja anglojęzyczna landing page potrzebuje tylko znaków Latin, subset może być dramatycznie mniejszy.

Są dwa popularne podejścia:

1. Użyć gotowego subsetu od dostawcy fontu lub z repozytorium.
2. Wygenerować własny subset narzędziem fontowym, takim jak pyftsubset z fonttools.

Dla wielu zespołów gotowe subsety Latin wystarczą. Własny subsetting przydaje się przy bardzo ograniczonych stronach, takich jak pojedyncza strona kampanii z niewielką ilością tekstu albo interfejs produktu z przewidywalnym pokryciem znaków.

Uważaj przy stronach wielojęzycznych. Brakujące glify powodują mieszanie fontów zastępczych, co może wyglądać na zepsute i szkodzić czytelności. Jeśli obsługujesz wiele języków, mapuj subsety fontów do tras językowych, zamiast wymuszać jeden mały subset wszędzie.

Krok 4: Napisz reguły @font-face

Minimalna lokalna konfiguracja wygląda tak:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

Kilka szczegółów ma tutaj znaczenie.

Dla większości stron z treścią używaj font-display: swap. Informuje to przeglądarkę, aby szybko pokazała tekst fontem zastępczym, a potem podmieniła go na font webowy, gdy ten dotrze. Pozwala to uniknąć najgorszej wersji FOIT: błysku niewidocznego tekstu.

Ustaw jawny stos fontów zastępczych. Jeśli font niestandardowy się nie załaduje, użytkownicy nadal powinni dostać czytelny tekst. Fonty zastępcze nie są dodatkiem na koniec; są częścią projektu. Jeśli musisz wrócić do rozmiarów, długości wiersza i wyborów dla tekstu głównego, zacznij od praktycznego przewodnika po czytelnej typografii we współczesnym webie.

Dopasuj grubości poprawnie. Jeśli CSS prosi o font-weight: 500, ale definiujesz tylko 400 i 700, przeglądarka może zsyntetyzować pośrednią grubość. Nie zawsze jest to fatalne, ale może wyglądać niespójnie.

Krok 5: Usuń zewnętrzne wywołania Google Fonts

Po dodaniu lokalnego CSS fontów usuń stare zdalne wywołania z szablonów.

Szukaj:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Sprawdź też:

• Ustawienia motywu w platformach CMS
• Panele typografii w page builderach
• Widgety stron trzecich
• Tag managers
• Stare importy CSS, takie jak @import url('https://fonts.googleapis.com/...')

Ten ostatni przypadek jest częsty. CSS @import dla fontów zwykle pogarsza wydajność, ponieważ opóźnia ich wykrycie. Jeśli hostujesz fonty samodzielnie, definiuj je bezpośrednio w głównym CSS albo w pliku CSS fontów ładowanym wcześnie.

Prace nad prywatnością często zawodzą, bo zespoły naprawiają oczywisty szablon, ale pomijają skrypty, widgety i stare osadzenia. Ten sam wzorzec pojawia się przy zgodach; nasz przewodnik po tym, co zmieniło się w cookies w 2026 roku, będzie dobrym uzupełnieniem, jeśli szerzej ograniczasz powierzchnię kontaktu ze stronami trzecimi.

Krok 6: Ustaw nagłówki cache

Pliki fontów są zasobami statycznymi. Powinny być agresywnie cache’owane, jeśli ich nazwy plików są wersjonowane albo zawierają hash treści.

Dobry nagłówek produkcyjny to:

Cache-Control: public, max-age=31536000, immutable

Używaj długotrwałego cache’owania immutable tylko wtedy, gdy URL zmienia się po zmianie pliku. Na przykład:

inter-latin-400.a8f3c2.woff2

albo wersjonowana ścieżka:

/fonts/v2/inter-latin-400.woff2

Jeśli nadpiszesz /fonts/inter-latin-400.woff2 bez zmiany URL, część użytkowników może trzymać stary plik przez długi czas. To jest w porządku, dopóki nie przestanie być. Wersjonowanie unika problemu.

Serwuj też fonty z poprawnym typem MIME:

Content-Type: font/woff2

Większość nowoczesnych platform hostingowych obsługuje to automatycznie, ale warto to zweryfikować.

Krok 7: Rozważ preload tylko krytycznego fontu

Preloading może pomóc przeglądarce wcześniej odkryć ważny font:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

Używaj tego oszczędnie. Preloaduj główny font tekstu widocznego above-the-fold, a nie każdą grubość. Nadmierny preloading konkuruje z CSS, obrazami i JavaScript.

Nawet dla fontów z tego samego originu dodawaj crossorigin przy preloadach fontów. Pobieranie fontów używa trybu CORS, a pominięcie tego atrybutu może w niektórych konfiguracjach powodować podwójne pobrania.

Jeśli nie masz pewności, testuj. Nie kopiuj preloadów bezrefleksyjnie tylko dlatego, że tak mówi checklist.

Krok 8: Przetestuj prywatność i wydajność

Testowanie jest proste.

Otwórz DevTools, przeładuj stronę z wyłączonym cache i przefiltruj panel Network po:

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

Powinieneś zobaczyć pliki fontów serwowane z własnej domeny i brak żądań do Google Fonts.

Następnie przetestuj z zimnym i ciepłym cache. Przy pierwszej wizycie fonty powinny pobrać się raz. Przy kolejnych powinny pochodzić z pamięci albo cache dyskowego, zależnie od przeglądarki.

Sprawdź przesunięcia układu, gdy font zostaje podmieniony. Jeśli nagłówki skaczą, metryki fontu zastępczego za bardzo różnią się od fontu webowego. Widoczne przesunięcie możesz zmniejszyć, wybierając bliższy font zastępczy albo używając nowszych nadpisań metryk fontu w CSS, takich jak size-adjust, ascent-override, descent-override i line-gap-override. To bardziej zaawansowane techniki, ale przydatne w dopracowanych interfejsach.

Na koniec przetestuj strony w trybie prywatnym albo z włączonymi content blockerami. Jedną z zalet samodzielnego hostowania jest to, że narzędzia prywatności rzadziej przypadkowo zablokują Twoją typografię.

Typowe błędy, których warto unikać

Hostowanie zbyt wielu grubości

To najczęstsza porażka. Dwie grubości często wystarczą. Trzy zwykle są w pełni wystarczające. Pięć to sygnał ostrzegawczy w design systemie, chyba że masz mocny powód.

Zapominanie o kursywie

Jeśli Twoje treści używają prawdziwego wyróżnienia, załaduj prawdziwy plik italic. Syntetyczna kursywa może wyglądać słabo, szczególnie w długich treściach redakcyjnych.

Zostawienie starego linku CSS do Google

To niweczy cel migracji. Po migracji żadne żądanie fontu nie powinno trafiać do Google, chyba że wstrzykuje je inny komponent.

Serwowanie fontów bez długoterminowego cache

Samodzielne hostowanie daje Ci kontrolę. Wykorzystaj ją. Fonty są idealnymi kandydatami do długiego czasu życia cache.

Ignorowanie pracy prawnej i dokumentacyjnej

Jeśli Twoja polityka prywatności wcześniej wspominała o Google Fonts albo ładowaniu fontów od stron trzecich, zaktualizuj ją po migracji. Jeśli prowadzisz rejestr przetwarzania danych, zaktualizuj również jego. Zmiana techniczna i dokumentacja zgodności powinny się zgadzać.

<!-- tool-cta:start -->

💡 Wypróbuj to: Przekonwertuj pliki TTF pobrane z Google Fonts na WOFF2 do samodzielnego hostowania oraz CSS za pomocą Webfont Generator.

<!-- tool-cta:end -->

Prosta lista kontrolna migracji

1. Wypisz rodziny fontów, grubości, style i skrypty, których rzeczywiście używasz.
2. Pobierz pliki WOFF2 i potwierdź licencję.
3. Zastosuj subsetting fontów, jeśli strona ma ograniczone potrzeby językowe.
4. Dodaj lokalne reguły @font-face z font-display: swap.
5. Usuń wszystkie odwołania Google Fonts typu link, preconnect i @import.
6. Serwuj fonty z własnej domeny z długotrwałymi nagłówkami cache.
7. Preloaduj tylko najważniejszy font above-the-fold, jeśli testy to potwierdzają.
8. Zweryfikuj w DevTools, że nie zostały żadne żądania do Google Fonts.
9. W razie potrzeby zaktualizuj dokumentację prywatności.

Samodzielne hostowanie fontów nie jest efektowną pracą. To ten rodzaj drobnego porządkowania infrastruktury, który zmniejsza ryzyko zależności, poprawia podejście do prywatności i daje bardziej przewidywalne renderowanie. Zwykle jest to warte godziny lub dwóch pracy.