Lokalny hosting czcionek w WordPressie polega na zapisaniu plików fontów na własnym serwerze zamiast pobierania ich z Google Fonts lub innej zewnętrznej domeny. Ogranicza to dodatkowe połączenia DNS, ułatwia kontrolę nad ładowaniem zasobów i zmniejsza ryzyko związane z przekazywaniem adresu IP do zewnętrznego dostawcy.
Dlaczego warto hostować czcionki lokalnie?
Przy standardowej konfiguracji motyw, Elementor lub wtyczka może pobierać arkusz stylów z fonts.googleapis.com, a pliki fontów z fonts.gstatic.com. Przeglądarka musi wtedy wykonać dodatkowe zapytania DNS i połączyć się z obcą domeną, zanim pobierze właściwy font. Nie zawsze powoduje to duże opóźnienie, ale zwiększa liczbę zależności potrzebnych do wyświetlenia strony.
Istotna jest też prywatność. Zewnętrzne żądanie może wiązać się z przekazaniem adresu IP użytkownika dostawcy czcionki. W Unii Europejskiej sądy wskazywały, że ładowanie Google Fonts z CDN bez odpowiedniej podstawy lub zgody może stwarzać problem z RODO. Lokalny hosting usuwa to konkretne połączenie, choć nie zastępuje pełnego audytu prywatności witryny.
Nieprawidłowo skonfigurowane fonty mogą też powodować FOIT, czyli chwilowy brak tekstu, albo FOUT, gdy najpierw pojawia się font zastępczy. Późniejsza zamiana kroju może przesuwać elementy i wpływać na wynik Cumulative Layout Shift.
Jaką metodę hostingu wybrać?
Najprościej skorzystać z wtyczki, która wykryje odwołania do Google Fonts, pobierze pliki na serwer i zmieni sposób ich ładowania. Ręczne wdrożenie przez @font-face daje większą kontrolę, ale wymaga znajomości CSS i samodzielnego sprawdzenia wszystkich źródeł czcionek.
| Metoda | Poziom trudności | Automatyzacja | Wpływ na wydajność | RODO |
|---|---|---|---|---|
| Wtyczka, np. OMGF | Niski | Wysoka | Dobry, zależny od konfiguracji | Ogranicza zewnętrzne żądania czcionek |
| Ręczne wdrożenie przez CSS | Średni lub wysoki | Brak | Największa kontrola nad plikami i ładowaniem | Wymaga samodzielnej kontroli źródeł |
| Wtyczka do własnych fontów | Niski lub średni | Średnia | Dobry przy ograniczonej liczbie odmian | Pliki mogą być serwowane z własnej domeny |
OMGF sprawdzi się wtedy, gdy fonty pochodzą z Google Fonts i chcesz zautomatyzować ich pobranie oraz podmianę odwołań. Custom Fonts jest przeznaczona głównie do wgrywania własnych plików. Use Any Font może pomóc, gdy otrzymasz font w formacie TTF lub OTF i potrzebujesz konwersji do WOFF2.
Jak hostować czcionki lokalnie za pomocą wtyczki?
Poniższa procedura dotyczy typowego wdrożenia z użyciem OMGF. Nazwy ekranów mogą się nieznacznie różnić zależnie od wersji wtyczki i języka panelu WordPressa.
Przed zmianą ustawień typografii wykonaj pełną kopię zapasową plików i bazy danych. Zmiana źródeł fontów może wejść w konflikt z motywem, Elementorem albo wtyczką cache. Backup pozwoli szybko przywrócić działającą konfigurację.
- Sprawdź obecne źródła czcionek – otwórz stronę w przeglądarce, uruchom narzędzia deweloperskie i sprawdź, czy pojawiają się żądania do
fonts.googleapis.comlubfonts.gstatic.com. - Zainstaluj wtyczkę – w panelu WordPressa przejdź do „Wtyczki”, wybierz „Dodaj nową”, wyszukaj OMGF, zainstaluj ją i aktywuj.
- Uruchom skanowanie – w ustawieniach wtyczki wyszukaj funkcję skanowania lub optymalizacji Google Fonts. Wtyczka powinna wykryć fonty dodawane przez motyw, kreator stron i aktywne rozszerzenia.
- Zapisz lokalną konfigurację – wybierz wykryte rodziny i odmiany, które są faktycznie używane, a następnie uruchom pobieranie lub optymalizację. Pliki zostaną zapisane w zasobach witryny, a arkusz CSS powinien wskazywać lokalne ścieżki.
- Ogranicz odmiany – pozostaw tylko potrzebne grubości i style, na przykład 400 oraz 700. Każda dodatkowa odmiana zwiększa liczbę plików i transfer.
- Wyczyść cache – usuń pamięć podręczną WordPressa, wtyczki optymalizującej, CDN oraz przeglądarki. Bez tego możesz testować starą wersję arkusza CSS.
- Sprawdź stronę po zmianie – odwiedź stronę główną, wpis, podstronę z formularzem i widok mobilny. Zwróć uwagę na nagłówki, menu, przyciski oraz elementy Elementora.
Jeżeli korzystasz z Elementora, sprawdź także ustawienia Global Fonts oraz opcje motywu. Czasem lokalnie zapisany font jest poprawny, ale pojedynczy element nadal odwołuje się do starego arkusza Google Fonts. Po zmianach może być potrzebne wygenerowanie plików CSS Elementora.
Jak sprawdzić, czy czcionki są hostowane lokalnie?
Najpewniejszą metodą jest analiza żądań w przeglądarce. Otwórz stronę w trybie prywatnym, aby ograniczyć wpływ zapisanej pamięci podręcznej, i wykonaj następujące czynności:
- Otwórz narzędzia deweloperskie klawiszem F12 albo przez menu przeglądarki.
- Przejdź do zakładki Network lub „Sieć”.
- Odśwież stronę z otwartym panelem.
- W filtrze zasobów wybierz typ „Font” albo wpisz w wyszukiwarkę
font. - Sprawdź adres każdego pliku i jego nagłówki odpowiedzi.
Poprawny wynik oznacza, że plik fontu jest pobierany z Twojej domeny, na przykład z katalogu zawierającego /wp-content/, /uploads/ albo zasoby motywu. Nie powinny pojawiać się żądania do fonts.googleapis.com ani fonts.gstatic.com.
Jeśli lokalny plik zwraca kod 404, sprawdź ścieżkę w regule @font-face, uprawnienia pliku i ustawienia CDN. Przy hostowaniu na innej subdomenie mogą być też potrzebne prawidłowe nagłówki CORS. W konsoli przeglądarki szukaj komunikatów o zablokowanym zasobie, błędzie MIME lub problemie z certyfikatem.
Po wdrożeniu przejdź przez tę krótką listę kontrolną:
- W zakładce Network nie ma żądań do domen Google Fonts.
- Lokalne pliki fontów zwracają kod odpowiedzi 200, a nie 404.
- Nagłówki odpowiedzi wskazują właściwy typ MIME dla pliku fontu.
- Fonty wyświetlają się poprawnie w Chrome, Firefox i Safari.
- Widok mobilny nie ma przesunięć nagłówków ani przycisków po załadowaniu fontu.
Jak zoptymalizować lokalne czcionki?
Najczęściej wybieranym formatem jest WOFF2. Oferuje lepszą kompresję niż starsze formaty i zwykle pozwala zmniejszyć rozmiar zasobów pobieranych przez przeglądarkę. TTF i OTF warto zachować jako pliki źródłowe, ale do publikacji w witrynie najczęściej wystarczy WOFF2, ewentualnie także WOFF dla starszych środowisk.
W regule @font-face ustaw font-display: swap. Dzięki temu tekst może pojawić się od razu przy użyciu kroju zastępczego, a właściwy font zostanie podmieniony po pobraniu pliku. Ogranicza to ryzyko niewidocznego tekstu, choć duża różnica między fontem zastępczym a docelowym nadal może powodować przesunięcia układu.
- Ładuj wstępnie tylko font potrzebny do pierwszego widoku, używając
preload. - Ogranicz liczbę rodzin i odmian do tych, które rzeczywiście występują w projekcie.
- Sprawdź, czy font zawiera polskie znaki, między innymi ą, ć, ę, ł, ń, ó, ś, ź oraz ż.
- Po każdej zmianie testuj stronę po wyczyszczeniu cache i na urządzeniu mobilnym.
Najważniejszy test jest prosty: w narzędziach deweloperskich odśwież stronę i sprawdź, skąd pobierane są pliki typu Font. Jeśli wszystkie pochodzą z Twojej domeny, lokalny hosting działa. Gdy po wdrożeniu pojawiają się błędy renderowania lub konflikt z cache, przywróć kopię zapasową i sprawdź konfigurację motywu, Elementora oraz wtyczek optymalizujących.
