Lokalne hostowanie fontów oznacza udostępnianie plików czcionek używanych na Twojej stronie nie z zewnętrznych serwisów, lecz bezpośrednio z własnego konta hostingowego, serwera lub autorskiego CDN. Przy prawidłowej implementacji redukuje to opóźnienia związane z zapytaniami DNS, negocjacją TLS i pobieraniem zasobów z zewnętrznych źródeł, co skutkuje krótszym czasem ładowania strony. Ma to szczególne znaczenie w kontekście Core Web Vitals, komfortu użytkownika i wyników SEO. Dla najlepszych efektów warto ograniczyć się do niezbędnych wag fontów, preferować format WOFF2, stosować preload dla kluczowych fontów oraz definiować w CSS font-display: swap.
Wielu właścicieli stron instynktownie korzysta z Google Fonts, Adobe Fonts lub fontów dołączonych przez motyw, nie zdając sobie sprawy, że takie podejście dodaje każdej wizycie dodatkowe kroki: rozwiązywanie DNS, nawiązywanie połączenia i pobieranie plików z obcych domen. Choć opóźnienia rzędu 100–300 ms mogą się wydawać niewielkie, to przy kilku rodzinach fontów i wielu wagach sumują się do zauważalnego spowolnienia całego ładowania. Dlatego lokalne hostowanie fontów to nie tylko techniczny detal, lecz strategia na szybszą, bardziej przewidywalną i stabilną wydajność strony.
W tym przewodniku wyjaśnimy, czym jest lokalne hostowanie fontów, kiedy przynosi korzyści, jak wdrożyć je na stronach WordPress i w projektach dedykowanych oraz jak unikać błędów zgodnych ze standardami SEO na 2026 rok. Znajdziesz też praktyczne wskazówki, jak optymalizować fonty korzystając z szybkiej i bezpiecznej infrastruktury Hostragons. Wybór hostingu to fundament wydajności, a optymalizacja fontów to precyzyjne dopracowanie tego fundamentu. Jeśli chcesz poznać dostępne opcje, sprawdź Hostragons pakiety hostingu WWW.
Czym jest lokalne hostowanie fontów?
Lokalne hostowanie fontów polega na przechowywaniu plików czcionek bezpośrednio w strukturze plików Twojej strony i udostępnianiu ich użytkownikom z własnej domeny. Zamiast odwoływać się do Google Fonts, Inter, Roboto czy Montserrat pobierasz pliki WOFF2 i umieszczasz je np. w folderze /fonts lub /assets/fonts. Następnie w CSS definiujesz je za pomocą reguły @font-face, wskazując odpowiednią ścieżkę. Przeglądarka podczas ładowania strony nie sięga po fonty do zewnętrznych serwisów, tylko pobiera je bezpośrednio z Twojej domeny.
Takie podejście daje pełną kontrolę nad formatami plików, czasem cache’owania, wagami i stronami, na których fonty są wykorzystywane. Jeśli używasz tylko wag 400 i 700, nie musisz hostować plików 300, 500, 600 czy 800 – zmniejsza to całkowity rozmiar pobieranych danych i upraszcza CSS.
W praktyce lokalne hostowanie fontów opiera się na trzech filarach: zoptymalizowane pliki fontów, poprawne definicje CSS oraz skuteczna konfiguracja cache na serwerze. Zaniedbanie któregokolwiek z nich może ograniczyć korzyści wydajnościowe. Na przykład użycie przestarzałego formatu TTF zamiast WOFF2 zwiększa rozmiar plików, a brak odpowiednich nagłówków cache powoduje wielokrotne pobieranie tych samych fontów przez użytkownika. Niewłaściwe preload może z kolei spowodować niepotrzebne obciążenie łącza.
Dlaczego optymalizacja fontów jest ważna dla SEO?
Google ocenia doświadczenia użytkowników na stronie, analizując zarówno bezpośrednie, jak i pośrednie sygnały. Waga mają szybkość ładowania, responsywność na urządzeniach mobilnych, opóźnienia interakcji i stabilność wizualna. Fonty mogą znacząco wpływać na metryki takie jak Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) czy postrzegany czas ładowania. Jeśli np. nagłówek lub tekst powyżej linii złożeń renderowany jest specjalną czcionką, jej opóźnione załadowanie może przesunąć wynik LCP na gorszy poziom.
W SEO 2026 liczy się nie tylko jakość treści, ale i techniczna dostępność. Googlebot musi mieć swobodny dostęp do zasobów, a użytkownicy – szybki i stabilny widok strony. Opóźnienia wynikające z korzystania z zewnętrznych serwisów fontów, problemy z dostępem regionalnym czy tymczasowe awarie DNS to czynniki poza Twoją kontrolą. Lokalny hosting fontów eliminuje te zmienne i pozwala na przewidywalność.
Przykład praktyczny: strona korporacyjna o wadze 1,8 MB, korzystająca z czterech rodzin Google Fonts, ośmiu wag i dwóch wariantów, może generować zapytania o fonty o łącznym rozmiarze 450–700 KB. Nawet jeśli część z nich nie jest widoczna od razu, przeglądarka może je pobrać ze względu na CSS. Po ograniczeniu do dwóch rodzin fontów, trzech wag i wykorzystaniu subsetów WOFF2, rozmiar spada do 90–180 KB. Na łączach 4G i słabszych urządzeniach różnica jest wyraźnie odczuwalna.
Porównanie: fonty zewnętrzne vs. lokalne
Nie ma uniwersalnej odpowiedzi, co jest lepsze – wszystko zależy od projektu. Czasem fonty zewnętrzne są wystarczające, innym razem lokalne hostowanie daje wyraźną przewagę. Poniższa tabela pokazuje główne różnice:
| Kryterium | Fonty zewnętrzne | Lokalne hostowanie fontów |
|---|---|---|
| Koszt pierwszego połączenia | Dodatkowe zapytania DNS, TCP/TLS oraz żądania do zewnętrznych serwerów. | Fonty ładowane z tej samej domeny lub własnego CDN. |
| Kontrola | Ograniczona możliwość zarządzania wersjami, nagłówkami i zachowaniem serwisu. | Pełna kontrola nad formatem, cache, preload i liczbą plików. |
| Prywatność | Przeglądarka odwiedzającego wysyła żądania do zewnętrznych domen fontów. | Żądania pozostają w obrębie własnej infrastruktury. |
| Łatwość wdrożenia | Szybkie wdrożenie metodą kopiuj-wklej. | Wymaga pobrania plików, definicji CSS i testów. |
| Potencjał wydajności | Dopuszczalne w małych projektach. | Przy poprawnej konfiguracji bardziej przewidywalne i szybsze. |
Podsumowując: jeśli zależy Ci na kontroli i wydajności, lokalne hostowanie jest lepszym wyborem. Nie jest to jednak tylko „wrzucenie fontów na serwer” – błędny format, nadmiar wag czy błędne definicje CSS mogą pogorszyć efekty.
Wpływ lokalnego hostowania fontów na szybkość strony
Pliki fontów często wydają się małe, ale mogą być newralgiczne w łańcuchu ładowania. Przeglądarka najpierw pobiera HTML, potem CSS, a następnie fonty zdefiniowane w CSS. Jeśli nagłówki, menu czy tekst są zależne od specjalnych fontów, przeglądarka może wstrzymać wyświetlanie tekstu do czasu załadowania plików, co objawia się białymi przestrzeniami lub „flashami” zmieniających się fontów.
Kluczowe metryki do oceny to: LCP (kiedy użytkownik widzi największy element treści), CLS (przesunięcia układu spowodowane zmianą fontu) i INP (interakcyjna responsywność). Fonty nie są główną przyczyną wysokiego INP, ale ciężki CSS i niepotrzebne zasoby zajmują główny wątek, co może wpływać pośrednio.
Dobrze zoptymalizowana strategia fontów zakłada: rozmiar fontów na pierwszym ekranie poniżej 100 KB, unikanie zbędnych wariantów, długie cache’owanie i preload kluczowych fontów. Na przykład na stronie sklepu internetowego, jeśli do nagłówków, cen i przycisków CTA używasz tylko wag 400 i 700 tej samej rodziny fontów, nie ma sensu ładować 9 różnych wariantów. Więcej o szybkich rozwiązaniach hostingowych dla e-commerce znajdziesz na Rozwiązania hostingu o wysokiej wydajności.
Najlepsze formaty fontów do lokalnego hostowania
Dlaczego WOFF2 to najlepszy wybór?
WOFF2 to obecnie najbardziej efektywny format fontów dla stron www. Charakteryzuje się dużym stopniem kompresji i jest wspierany przez większość nowoczesnych przeglądarek. Pliki TTF lub OTF, choć świetne do projektów graficznych i desktopowych, są często zbyt duże do zastosowań webowych. Starsze formaty, jak EOT, są obecnie potrzebne jedynie w przypadku bardzo starych przeglądarek.
Dla przykładu plik TTF może ważyć 300 KB, podczas gdy WOFF2 tej samej czcionki to zaledwie 80–120 KB. Różnica jest tym większa, im więcej wag i stylów używasz. Dlatego przy lokalnym hostowaniu zawsze stosuj zoptymalizowane pliki WOFF2.
Czy warto stosować fonty variable?
Variable font to pojedynczy plik zawierający wiele wag i stylów. Jeśli Twój projekt wymaga wielu wariantów od 300 do 800, może to być wygodne i oszczędne. Jednak gdy używasz tylko dwóch wag, np. 400 i 700, często dwie statyczne wersje WOFF2 mają mniejszą łączną wagę. Wybór warto poprzedzić testami pod kątem rozmiaru plików, liczby wariantów i kompatybilności z przeglądarkami.
Doświadczeni specjaliści radzą: najpierw spisz realnie używane wagi, potem porównaj rozmiary statycznych i variable fontów. Wybierz rozwiązanie prostsze, mniejsze i bardziej stabilne. Estetyka i pomiary muszą iść w parze.
Jak wdrożyć lokalne hostowanie fontów?
Następujące kroki sprawdzą się na stronach WordPress, w aplikacjach PHP, Laravel, Node.js czy stronach statycznych. Zasada jest jedna: usuń zbędne fonty, zoptymalizuj pliki, serwuj je z własnej domeny i testuj wyniki.
1. Przeanalizuj aktualne wykorzystanie fontów
Sprawdź, które fonty i z jakich źródeł są ładowane. W Chrome DevTools w zakładce Network użyj filtra „font”, by zobaczyć wszystkie żądania. Możesz też skorzystać z raportów PageSpeed Insights, WebPageTest lub Lighthouse, które wskażą render-blocking i zewnętrzne zasoby. Odpowiedz na pytania: Ile rodzin fontów jest w użyciu? Jakie wagi są ładowane? Skąd pochodzą fonty? Ile z nich jest faktycznie potrzebnych na pierwszym ekranie?
W wielu przypadkach motyw, builder i wtyczki ładują fonty osobno, np. motyw Roboto, edytor Montserrat, formularze Open Sans. Choć wizualnie może się to nie rzucać w oczy, to spowalnia stronę. Najlepiej wybrać jeden spójny system typografii, co przyniesie największe korzyści.
2. Pobierz i uprość potrzebne fonty
Zwróć uwagę na licencję wybranej czcionki. Fonty open source zwykle pozwalają na lokalne hostowanie, ale fonty komercyjne mogą mieć ograniczenia dotyczące hostowania, domen lub liczby odsłon. Po potwierdzeniu licencji pobierz tylko niezbędne wagi i style. Upewnij się, że font ma wsparcie dla rozszerzonych znaków łacińskich, istotnych np. dla polskich liter (ą, ć, ę, ł, ń, ó, ś, ź, ż).
Dla dalszej optymalizacji możesz wygenerować subset, czyli wyciąć nieużywane zestawy znaków. Strony dwujęzyczne (np. polsko-angielskie) zwykle wystarczy zaopatrzyć w zestaw Latin i Latin Extended. Jeśli nie używasz cyrylicy, arabskiego czy greckiego, usuń te zestawy, by zmniejszyć rozmiar plików. Pamiętaj jednak, że nieprawidłowy subset może powodować błędy wyświetlania tekstu. Przy projektach wielojęzycznych warto planować domeny i wersje językowe zgodnie z Poradnik wyboru domeny i strony wielojęzycznej.
3. Umieść fonty w odpowiednim folderze
Przechowuj pliki fontów w uporządkowanym katalogu, np. /assets/fonts/inter/inter-400.woff2 oraz /assets/fonts/inter/inter-700.woff2. Nazwy plików z wersją (np. inter-400-v2.woff2) ułatwiają zarządzanie cache. Dzięki temu przy aktualizacji fontów unikasz problemów ze starymi wersjami w pamięci przeglądarki.
Wgraj je za pomocą menedżera plików w panelu hostingu, FTP lub systemu kontroli wersji (Git). Ustaw prawa dostępu plików na 644, folderów na 755, by były czytelne dla przeglądarek. Sprawdź też, czy serwer poprawnie rozpoznaje typ MIME - dla WOFF2 powinien to być font/woff2. Brak tej konfiguracji może skutkować błędem 403 i fallbackiem do systemowej czcionki.
4. Dodaj definicje @font-face w CSS
Serce lokalnego hostowania to reguła @font-face. Przykład prostego wpisu:
@font-face {
font-family: 'Inter';
src: url('/assets/fonts/inter/inter-400.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
}
Dla odmiany font-weight: 700 tworzysz osobną regułę. Kluczowy jest parametr font-display: swap, który pozwala na wyświetlenie tekstu najpierw systemowym fontem, a po załadowaniu fontu własnego – zamianę. Dzięki temu unikasz niewidocznego tekstu, choć może pojawić się delikatne przesunięcie. Aby zminimalizować efekt, wybierz font zapasowy (fallback) podobny do docelowego, np. Arial lub system-ui dla Inter.
5. Preload kluczowych fontów
Preload to wskazówka dla przeglądarki, by jak najszybciej pobrała dany zasób. Warto zastosować preload dla fontów używanych na pierwszym ekranie, np. podstawowej wagi tekstu i nagłówków. Nie przesadzaj z preload – ładowanie wszystkich fontów naraz może blokować inne ważne zasoby, jak obrazy czy krytyczny CSS.
Zasada jest taka: preloaduj maksymalnie 1–2 fonty faktycznie widoczne na starcie. Jeśli np. na blogu font nagłówka ma wagę 700, a treść 400, to te dwa pliki warto preloadować. Fonty kursywne lub rzadko używane pomijaj. Po wdrożeniu sprawdź w zakładce Network w DevTools, czy fonty faktycznie ładują się wcześniej i nie są pobierane podwójnie.
6. Skonfiguruj cache i kompresję
Fonty to statyczne zasoby, które rzadko się zmieniają, dlatego powinny być serwowane z długim cache’em. Najczęściej stosowany nagłówek to Cache-Control: public, max-age=31536000, immutable. Dzięki temu przeglądarki długo przechowują fonty, a zmiany wprowadzamy przez zmianę nazwy pliku z wersją.
WOFF2 jest już formatem skompresowanym, więc dodatkowa kompresja Brotli czy Gzip nie przynosi dużych oszczędności. Ważniejsza jest szybka i stabilna obsługa statycznych plików przez serwer. Jeśli korzystasz z Hostragons z LiteSpeed, dyskami NVMe i odpowiednim cache, fonty odpowiedzą błyskawicznie. Pamiętaj także o poprawnej konfiguracji SSL, która umożliwia HTTP/2 i HTTP/3, co znacząco poprawia wydajność. Szczegóły znajdziesz w Poradnik instalacji certyfikatu SSL i HTTPS.
Lokalne hostowanie fontów w WordPress
W WordPress optymalizacja fontów zależy od motywu, wtyczek i page buildera. Sprawdź, czy motyw pozwala wyłączyć ładowanie Google Fonts – wiele nowoczesnych motywów ma taką opcję w ustawieniach typografii. Popularne wtyczki, jak Elementor, Gutenberg czy slider’y mogą mieć własne fonty. Przyjrzyj się im, by uniknąć wielokrotnego ładowania tego samego fontu z różnych źródeł.
Najczystsze technicznie rozwiązanie to trzymanie plików fontów w child theme i dodanie definicji @font-face do pliku stylów motywu. Możesz też skorzystać z dedykowanych wtyczek do lokalnego hostowania fontów, ale nie przesadzaj z ich liczbą, by nie obciążać strony. Jeśli zdecydujesz się na wtyczkę, zwróć uwagę na jej aktualizacje, kompatybilność z obecną wersją PHP i współpracę z wtyczkami cache.
Przed zmianami wykonaj pełną kopię zapasową strony. Usuwając fonty zewnętrzne, uważaj, by nie zepsuć ikon fontów lub stylów panelu administracyjnego. Na stronach WooCommerce dokładnie przetestuj koszyk, płatności i konto użytkownika. Jeśli szukasz wydajnego hostingu dla WordPress, sprawdź Pakiety hostingu WordPress.
Lista kontrolna SEO i Core Web Vitals po optymalizacji fontów

Po wdrożeniu lokalnego hostowania nie wystarczy tylko sprawdzić, czy strona się ładuje. Mierz i porównuj wyniki przed i po zmianach, korzystając z narzędzi bliskich realnym warunkom użytkownika. Oto podstawowa lista kontrolna:
- Upewnij się, że w zakładce Network nie ma zapytań do Google Fonts, fonts.gstatic lub innych zewnętrznych domen.
- Ogranicz liczbę plików fontów do 2–4, jeśli to możliwe.
- Potwierdź, że wszystkie pliki mają format WOFF2 i rozsądny rozmiar.
- Testuj wartość font-display: swap lub opcjonalnie optional.
- Preloaduj tylko te fonty, które faktycznie są używane na pierwszym ekranie.
- Sprawdź czy nagłówki Cache-Control umożliwiają długotrwałe przechowywanie.
- Zweryfikuj poprawność wyświetlania polskich znaków na różnych przeglądarkach.
- Porównaj wyniki mobilnego PageSpeed Insights, Lighthouse i WebPageTest przed i po optymalizacji.
Nie polegaj na jednym teście – warunki sieci, obciążenie serwera i lokalizacja testów mają wpływ. Wykonaj minimum trzy testy i oceń średnią. Jeżeli LCP spadnie z 2,8 do 2,3 sekund, to duży postęp. Jeśli po optymalizacji wzrośnie CLS, sprawdź ponownie wybór fontu zapasowego i metryki fontów.
Typowe błędy przy lokalnym hostowaniu fontów
Zbyt wiele rodzin fontów
Najczęstszy błąd to przesadna różnorodność. Jeden font dla nagłówków, inny dla paragrafów, jeszcze inny dla przycisków czy cytatów to niepotrzebne obciążenie. Większość profesjonalnych stron buduje spójny wizerunek na bazie 1–2 rodzin fontów. Spójność typograficzna jest równie ważna jak szybkość i wpływa na postrzeganie marki.
Zły wybór fontu zapasowego (fallback)
Jeśli systemowy font wyświetlany przed załadowaniem fontu własnego różni się znacząco wymiarami (wysokość x-height, szerokość liter, wysokość linii), powstają przesunięcia tekstu i wzrasta CLS. Wybieraj fallbacki jak system-ui, Arial, Helvetica czy Georgia i testuj ich wygląd względem fontów własnych.
Preload wszystkich fontów
Preload to potężne narzędzie, ale nadużywane szkodzi. Ładowanie wszystkich wag fontów na starcie może zablokować pobieranie innych krytycznych zasobów i pogorszyć LCP, zwłaszcza na stronach z dużymi grafikami. Decyzje o preload podejmuj na podstawie faktycznego wykorzystania i testów.
Ignorowanie licencji
Nie wszystkie fonty są darmowe lub bez ograniczeń. Fonty komercyjne mogą wymagać specjalnych licencji na lokalne hostowanie, ograniczać liczbę domen czy odsłon. Publikowanie fontu bezprawnie może skutkować konsekwencjami prawnymi. Zachowuj licencje i dokumentację projektu.
Bezpieczeństwo, prywatność i aspekty infrastruktury
Lokalne hostowanie fontów to nie tylko szybkość, ale także bezpieczeństwo i prywatność. Korzystając z zewnętrznych serwisów, przeglądarka użytkownika wysyła zapytania do domen firm trzecich, co w niektórych branżach i jurysdykcjach (np. RODO) wymaga szczególnego traktowania. Udostępniając fonty z własnej domeny, ograniczasz przepływ danych i zwiększasz kontrolę.
HTTPS jest tu niezbędny – fonty ładowane przez HTTP mogą powodować błędy mixed content i blokady ze strony przeglądarek. Dlatego poprawna konfiguracja DNS, certyfikat SSL i wydajny hosting to podstawa. Przy nowych projektach warto rozważyć wybór domeny według Sprawdzanie domen i rejestracja, zabezpieczenie transmisji z Certyfikaty SSL, a także wydajną infrastrukturę Hostragons rozwiązania hostingowe.
Jeśli korzystasz z CDN, zwróć uwagę na nagłówki CORS. Fonty dostarczane z innej subdomeny niż strona muszą mieć ustawiony Access-Control-Allow-Origin, inaczej przeglądarka zablokuje ich użycie. Najprościej jest serwować fonty z tej samej domeny.
Jak mierzyć efekty optymalizacji fontów?
Dowodem skuteczności jest pomiar. Zacznij od zanotowania liczby żądań fontów, rozmiaru ich danych, wartości LCP, CLS oraz całkowitego czasu ładowania. Następnie wdroż lokalne hostowanie i zmierz te same parametry na tych samych podstronach – głównej, wpisach blogowych, kategoriach czy stronach produktów.
Dla przykładu: blog z 6 fontami i 420 KB danych może po optymalizacji spaść do 2 fontów i 96 KB. Mobilny wynik Lighthouse może poprawić się z 72 do 86 punktów, a LCP skrócić z 3,1 do 2,4 sekundy. Pamiętaj, że to przykładowe wyniki – na ostateczny efekt wpływają też obrazy, JavaScript i czas odpowiedzi serwera. Optymalizacja fontów to jednak szybka do wdrożenia i mierzalna poprawa.
Dane rzeczywistych użytkowników (RUM), np. z Chrome User Experience Report lub raportów Core Web Vitals w Search Console, dają najbardziej wiarygodny obraz. Laboratorium testowe pomaga znaleźć problemy, ale dane z użytkowania pokazują rzeczywiste korzyści. Przy dużym ruchu zmiany najlepiej wprowadzać najpierw na środowisku testowym, a produkcję aktualizować w godzinach o niskim natężeniu ruchu.
Mini plan optymalizacji fontów w 60 minut
Jeśli masz ograniczony czas, skorzystaj z tego planu: pierwsze 10 minut poświęć na analizę fontów w DevTools i zrób screeny. Kolejne 10 minut zidentyfikuj faktycznie używane rodziny i wagi. W 15 minut pobierz WOFF2, sprawdź polskie znaki i wgraj fonty do /assets/fonts.
Następne 15 minut dodaj definicje @font-face w CSS, ustaw font-display: swap i usuń linki do zewnętrznych fontów. Ostatnie 10 minut testuj na urządzeniach mobilnych, sprawdź w Network brak zewnętrznych fontów i zweryfikuj wyświetlanie na różnych przeglądarkach. Zaawansowane techniki, jak preload, subset czy cache, możesz wdrożyć później.
Taki plan sprawdzi się w małych firmach, blogach czy stronach korporacyjnych. Duże sklepy lub SaaS-y powinny optymalizację fontów integrować z systemem projektowym, bibliotekami komponentów i procesem wdrożeniowym.
Podsumowanie
Lokalne hostowanie fontów to skuteczny sposób na przyspieszenie strony, poprawę doświadczeń użytkownika i podniesienie jakości technicznej SEO. Kluczowe elementy to stosowanie formatu WOFF2, eliminacja niepotrzebnych wag, dodanie font-display, preloadowanie kluczowych fontów oraz właściwa konfiguracja cache. Nie jest to panaceum na wszystkie problemy wydajności, ale szybki i mierzalny krok w stronę lepszego serwisu.
Im lepszy hosting, tym większe korzyści z optymalizacji. Jeśli chcesz podnieść szybkość i bezpieczeństwo strony, sprawdź ofertę Hostragons na hosting, domeny i SSL, a optymalizację fontów potraktuj jako element kompleksowej strategii. Zamiast działać pod presją, mierz rezultaty, wdrażaj zmiany i potwierdzaj je realnym doświadczeniem użytkowników.
Najczęściej zadawane pytania
Czy lokalne hostowanie fontów zawsze jest szybsze niż Google Fonts?
Nie zawsze. Przy dobrym cache, formacie WOFF2, niewielkiej liczbie plików i szybkim serwerze lokalne fonty zwykle są bardziej przewidywalne i szybsze. Jednak źle skonfigurowane lokalne fonty mogą działać wolniej niż zoptymalizowane fonty zewnętrzne.
Jaki format fontów wybrać do lokalnego hostowania?
Najlepszym wyborem na dziś jest WOFF2 – mały rozmiar i szerokie wsparcie przeglądarek. TTF i OTF są większe i mniej wydajne na potrzeby stron internetowych.
Ile wag fontów powinno się używać?
Dla większości stron wystarczą dwie wagi: 400 i 700. W niektórych projektach można dodać 500 lub 600, ale każda dodatkowa waga to większy rozmiar i dłuższy czas ładowania. Usuń nieużywane wagi.
Czy font-display: swap jest obowiązkowy?
Nie jest obowiązkowy, ale zalecany w większości przypadków. Pozwala wyświetlić tekst systemowym fontem zanim załaduje się font własny, redukując problem niewidocznego tekstu. Dla minimalizacji przesunięć trzeba dobrać odpowiedni fallback.
Czy do lokalnego hostowania fontów w WordPress potrzebna jest wtyczka?
Nie jest konieczna. Najczystszym rozwiązaniem jest dodanie plików do child theme i deklaracje w CSS. Jeśli nie masz wiedzy technicznej, możesz skorzystać z zaufanej i aktualnej wtyczki.