Zapytaj właściciela firmy, skąd pochodzi czcionka na jego stronie, a w 9 na 10 przypadków usłyszysz: „Z Google Fonts. Jest darmowa, szybka i ładna.” Trudno się z tym spierać — Google Fonts oferuje ponad 1500 rodzin fontów, zero opłat licencyjnych i prosty znacznik w kodzie strony. Ale ta wygoda ma dwa ukryte koszty: jeden prawny, drugi techniczny.
Polskie MŚP stają przed coraz bardziej uważnymi organami ochrony danych i coraz wyższymi wymaganiami Core Web Vitals. W obu tych kontekstach standardowe wdrożenie Google Fonts — przez zewnętrzny CDN — tworzy problemy, których można uniknąć jedną prostą zmianą: self-hostingiem fontów, czyli serwowaniem ich bezpośrednio z własnego serwera.
W tym artykule wyjaśniamy, dlaczego standardowe osadzanie Google Fonts z CDN to subtelne ryzyko RODO, jak konkretnie spowalnia ładowanie strony i jak przejść na własny hosting fontów — bez programisty, bez kosztów.
Jak Google Fonts CDN działa od środka
Kiedy dodajesz do strony standardowy tag Google Fonts, np.:
<link href="https://fonts.googleapis.com/css2?family=Lato:wght@400;700&display=swap" rel="stylesheet">w tle dzieją się trzy rzeczy, których właściciel strony zwykle nie widzi.
Pierwsze zapytanie trafia na fonts.googleapis.com, gdzie Google udostępnia plik CSS z deklaracjami @font-face. Ten plik jest render-blocking — przeglądarka musi go pobrać, zanim zacznie renderować stronę.
Drugie zapytanie trafia na fonts.gstatic.com po właściwy plik fontu (zwykle .woff2). Obie domeny należą do Google i obsługują żądania na serwerach Google, rozmieszczonych globalnie — w tym w Stanach Zjednoczonych.
Każde z tych zapytań przenosi informacje, które przeglądarka standardowo wysyła razem z każdym połączeniem HTTP: adres IP użytkownika, nagłówek User-Agent, stronę odsyłającą (referer) i znacznik czasu. Google otwarcie przyznaje to w swojej polityce prywatności:
„Zbieramy też informacje o interakcjach Twoich aplikacji, przeglądarek i urządzeń z naszymi usługami, w tym adres IP, raporty o awariach, dane o aktywności systemu oraz datę, godzinę i adres URL strony odsyłającej żądania.” — Polityka prywatności Google, policies.google.com/privacy
Innymi słowy: każdy odwiedzający Twoją stronę przesyła swój adres IP bezpośrednio do Google — tylko dlatego, że na stronie jest znacznik fontu z Google CDN.
Problem RODO: adres IP to dane osobowe
Właściciel małej firmy może pomyśleć: „No i co z tego? Jaki to może być problem?” Odpowiedź tkwi w definicji danych osobowych.
Zgodnie z art. 4 pkt 1 RODO, dane osobowe to wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Trybunał Sprawiedliwości UE i Europejska Rada Ochrony Danych wielokrotnie potwierdziły, że adres IP jest danymi osobowymi — dynamiczny IP może zostać powiązany z konkretną osobą przez dostawcę internetu, a więc spełnia kryterium możliwości identyfikacji.
Przesyłanie danych osobowych do podmiotów poza Europejskim Obszarem Gospodarczym, czyli np. do Google w USA, podlega art. 44–49 RODO, który wymaga odpowiedniej podstawy prawnej.
Warto też zauważyć, że zbieranie danych przez Google przy każdym żądaniu o font nie jest incydentalne — to standardowy mechanizm serwerów HTTP. Każde zapytanie do fonts.googleapis.com zawiera: adres IP odwiedzającego, identyfikator przeglądarki i systemu operacyjnego (User-Agent), adres strony wywołującej żądanie (referer) oraz datę i godzinę. Dla operatora strony oznacza to, że de facto jest współodpowiedzialny za inicjowanie tego transferu danych — bo to właściciel strony umieścił element, który go wywołuje. Organy ochrony danych coraz częściej uznają taką konfigurację za brak właściwej podstawy prawnej do przetwarzania.
Precedens sądowy z Niemiec
W 2022 roku Sąd Okręgowy w Monachium (LG München I, wyrok z 20 stycznia 2022 r., sygn. 3 O 17493/20) wydał orzeczenie bezpośrednio dotyczące Google Fonts. Użytkownik zarzucił właścicielowi strony, że ta bez jego zgody przesyłała adres IP do Google. Sąd przyznał mu rację: operator strony naruszył art. 6 ust. 1 RODO, bo nie miał podstawy prawnej do przekazywania danych do USA.
To niższy sąd w Niemczech, nie TSUE — ale wyrok pokazuje, że organy ochrony danych zaczęły badać nie tylko cookies czy Google Analytics, ale każdy element strony, który transferuje dane poza EOG.
Stan prawny po 2023 roku — DPF jako częściowe rozwiązanie
W lipcu 2023 roku Komisja Europejska przyjęła decyzję o adekwatności dla Ramowych Zasad Ochrony Danych UE–USA (EU-US Data Privacy Framework, DPF). Google jest certyfikowany w ramach DPF, co formalnie tworzy nową podstawę prawną dla transferów danych do USA.
Jednak z perspektywy małej firmy DPF nie rozwiązuje wszystkiego:
- DPF może zostać zaskarżony przed TSUE (podobnie jak Privacy Shield, który upadł w 2020 r.)
- Weryfikacja certyfikacji kontrahenta i utrzymanie dokumentacji wymagają nakładu pracy
- Samo-hosting eliminuje transfer w ogóle — i tym samym eliminuje problem prawny, niezależnie od aktualnego statusu DPF
Jeśli dane nie trafiają do Google, nie trzeba analizować, czy Google jest certyfikowany. To jest właśnie przewaga self-hostingu: zero ekspozycji, niezależnie od zmian prawa.
W kontekście RODO warto też spojrzeć szerzej: Google Fonts to jeden element układanki, ale podobny problem dotyczy każdego zewnętrznego zasobu ładowanego z obcego serwera — skryptów analitycznych, pixeli śledzących, widgetów map. Kwestię polityki cookies i zgód na śledzenie omawiamy szczegółowo w artykule o wymaganiach UODO dotyczących banerów cookie w 2026.
Jak Google Fonts spowalnia ładowanie strony
Poza kwestią prywatności, osadzanie fontów z CDN ma wymierny wpływ na szybkość strony. I nie jest to kwestia milisekund bez znaczenia — w Google PageSpeed Insights to realne punkty rankingowe.
Trzy etapy opóźnienia przy zewnętrznym foncie
Każde zapytanie do zewnętrznej domeny wymaga sekwencji kroków, których nie da się skrócić poniżej pewnego minimum.
DNS lookup — przeglądarka musi „zapytać” serwer DNS, gdzie znajduje się fonts.googleapis.com. Trwa 20–150 ms na zimnym starcie.
Handshake TCP + TLS — nawiązanie bezpiecznego połączenia z obcym serwerem (HTTPS). Kolejne 50–200 ms, zależnie od lokalizacji użytkownika i serwerów Google.
Transfer pliku CSS — mały plik, ale musi dotrzeć, zanim przeglądarka wie, jakie fonty pobierać dalej.
Następnie cały cykl powtarza się dla fonts.gstatic.com, by pobrać właściwy plik .woff2. W sumie oznacza to dwa zestawy DNS+TCP+TLS dla zasobów spoza Twojej domeny. Google web.dev wskazuje na to wprost:
„Particular care should be given to fonts loaded from third-party sites as downloading these font files requires separate connection setups.” — Font best practices, web.dev/articles/font-best-practices
Render-blocking, FOIT i CLS w praktyce
Standardowy tag <link> z CSS Google Fonts jest render-blocking: przeglądarka wstrzymuje renderowanie strony, czekając na pobranie pliku CSS z fonts.googleapis.com. Dopiero po jego analizie wie, z jakiego URL pobrać plik fontu.
Efekty tego opóźnienia są widoczne dla użytkownika w dwóch formach:
- FOIT (Flash of Invisible Text) — tekst jest niewidoczny, póki font się nie załaduje. Użytkownik widzi „pustą” stronę przez ułamek sekundy.
- FOUT (Flash of Unstyled Text) — tekst pojawia się w foncie zastępczym (np. Arial), a potem przeskakuje na docelowy. Ten przeskok to Cumulative Layout Shift (CLS) — jeden z Core Web Vitals mierzonych przez Google.
Koniec mitu o współdzielonym cache
Historycznie Google Fonts miały jedną zaletę wydajnościową: jeśli użytkownik odwiedził inną stronę używającą tego samego fontu z Google CDN, plik był już w cache przeglądarki. Od Chrome 86 (2020) ta „wspólna pamięć podręczna” nie istnieje — każda strona musi pobierać fonty osobno, bo przeglądarka izoluje cache per origin (tzw. cache partitioning). Technicznie: klucz cache to nie sam URL pliku, ale trójka (schemat, host, top-level site), więc fonts.gstatic.com/lato.woff2 załadowane z firmaA.pl i z firmaB.pl to dwa osobne wpisy w cache — żaden nie korzysta z drugiego.
Oznacza to, że argument „Google Fonts jest szybki, bo font jest już u użytkownika w cache” jest od 2020 roku nieaktualny. Self-hosting jest na równorzędnych lub lepszych warunkach wydajnościowych — przy własnym serwerze masz dodatkowo pełną kontrolę nad nagłówkami cache (np. długi max-age) i nie zależysz od dostępności serwera Google.
Fonty a Core Web Vitals i ranking w Google
PageSpeed Insights i Lighthouse flagują zewnętrzne fonty w sekcjach „Eliminate render-blocking resources” i „Preconnect to required origins”. To nie są uwagi estetyczne — to punkty odejmowane ze wskaźnika wydajności, który wpływa na pozycję strony w Google. Więcej o tym, jak mierzyć realne wyniki strony firmowej i jakie narzędzia analityczne są przyjazne prywatności, pisaliśmy w artykule o analityce dla stron firmowych MŚP.
Diagnoza i rozwiązanie: self-hosting fontów krok po kroku
Dobra wiadomość jest taka, że tej zmiany nie trzeba zlecać deweloperowi. Jeśli masz dostęp do plików swojej strony lub panelu WordPress, możesz wykonać ten krok samodzielnie w ciągu kilkunastu do trzydziestu minut. W przypadku stron budowanych przez agencję lub freelancera zmiana jest wystarczająco prosta, żeby można ją było opisać w jednym tickecie — bez długich konsultacji. Zacznij od potwierdzenia, czy problem w ogóle Twojej strony dotyczy.
Jak sprawdzić, czy Twoja strona używa Google Fonts CDN
Zanim przejdziesz do zmian, warto potwierdzić, że problem faktycznie dotyczy Twojej strony.
Metoda najszybsza — PageSpeed Insights: wejdź na pagespeed.web.dev, wpisz adres strony. W sekcji „Opportunities” lub „Diagnostics” poszukaj pozycji „Eliminate render-blocking resources”. Jeśli widzisz tam fonts.googleapis.com — używasz Google Fonts CDN.
Chrome DevTools: otwórz stronę w Chrome, naciśnij F12 → zakładka Network, przeładuj stronę. W polu filtrowania wpisz googleapis. Jeśli pojawiają się wpisy — masz zewnętrzne żądanie po fonty.
Kod źródłowy: w kodzie strony (Ctrl+U w Chrome) szukaj:
<link href="https://fonts.googleapis.com/...">lub w plikach CSS frazy:
@import url('https://fonts.googleapis.com/...');Oba to sygnały, że Twoja strona ładuje fonty z zewnętrznego serwera Google.
Krok 1: Pobierz pliki fontów
Narzędzie Google Webfonts Helper (google-webfonts-helper.herokuapp.com) to najprostsze rozwiązanie:
- wybierasz font i potrzebne warianty (Regular 400, Bold 700 — typowo tyle wystarczy)
- pobierasz gotowe pliki
.woff2i.woff - narzędzie generuje gotowy kod CSS
@font-facedo skopiowania
Format WOFF2 zapewnia ok. 30% mniejszy rozmiar pliku niż starszy WOFF, przy pełnej obsłudze przez wszystkie nowoczesne przeglądarki.
Wskazówka: wybieraj tylko warianty fontów, które faktycznie używasz na stronie. Zbędne wagi i style to zbędne KB do pobrania przy każdej wizycie.
Dla użytkowników WordPressa: istnieje prostsze rozwiązanie bez edycji kodu — wtyczka OMGF (Optimize My Google Fonts), dostępna bezpłatnie w repozytorium WordPress.org. Po instalacji OMGF automatycznie wykrywa, jakie Google Fonts są używane na stronie (włącznie z tymi osadzonymi przez motywy i inne wtyczki), pobiera pliki fontów na serwer i podmienia zewnętrzne tagi <link> na lokalne odwołania. Warto po instalacji zweryfikować w Chrome DevTools (zakładka Network → filtr googleapis), czy żadne zapytania do zewnętrznych serwerów Google już nie wychodzą — niektóre motywy ładują fonty przez kilka różnych ścieżek i plugin może nie wyłapać ich wszystkich.
Krok 2: Wgraj pliki na serwer
Stwórz katalog /fonts/ w swoim projekcie i wgraj pliki .woff2:
- Astro:
site/public/fonts/(pliki trafiają do głównego katalogu po buildzie) - WordPress: przez FTP lub panel hostingowy do katalogu motywu, podkatalog
fonts/ - Dowolny serwer statyczny: katalog publicznie dostępny przez HTTP
Krok 3: Zaktualizuj CSS i zweryfikuj
Usuń zewnętrzny tag <link href="https://fonts.googleapis.com/..."> i zastąp go własnym CSS z @font-face. Kod wygenerowany przez Google Webfonts Helper wygląda tak:
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 400;
font-display: swap;
src: local('Lato Regular'),
url('/fonts/lato-regular.woff2') format('woff2');
}
@font-face {
font-family: 'Lato';
font-style: normal;
font-weight: 700;
font-display: swap;
src: local('Lato Bold'),
url('/fonts/lato-700.woff2') format('woff2');
}Kluczowy parametr to font-display. Zgodnie z dokumentacją MDN Web Docs, wartość swap sprawia, że przeglądarka wyświetla tekst od razu w foncie zastępczym, a gdy załaduje się właściwy font — podmienia go. Dla typowych stron firmowych to dobry kompromis: tekst zawsze widoczny, font docelowy ładuje się bez blokowania renderowania.
Po wdrożeniu uruchom ponownie PageSpeed Insights. Wpisy fonts.googleapis.com i fonts.gstatic.com powinny zniknąć z listy zasobów zewnętrznych. Wskaźniki LCP i CLS mogą się poprawić, szczególnie na połączeniach mobilnych.
Dodatkowa optymalizacja: preload najważniejszego fontu. Jeśli chcesz jeszcze bardziej przyspieszyć ładowanie, możesz dodać dyrektywę preload w nagłówku strony dla kluczowego pliku fontu:
<link rel="preload" href="/fonts/lato-regular.woff2" as="font" type="font/woff2" crossorigin>Ten znacznik informuje przeglądarkę, żeby pobrała plik fontu jak najwcześniej — jeszcze zanim napotka deklarację @font-face w CSS. W połączeniu z font-display: swap skutecznie eliminuje FOIT i może poprawić LCP (Largest Contentful Paint), jeśli tekst jest elementem liczonym do tego wskaźnika. Uwaga: atrybut crossorigin jest wymagany nawet dla fontów z własnego serwera — bez niego przeglądarka pobierze plik dwa razy, co niweluje korzyść z preloadu.
Alternatywa: kiedy wybrać fonty systemowe
Istnieje jeszcze prostsze rozwiązanie: system fonts stack — używanie domyślnych fontów zainstalowanych w urządzeniu użytkownika. Żadnych zewnętrznych żądań, żadnych opóźnień, żadnych problemów z RODO:
body {
font-family: -apple-system, BlinkMacSystemFont,
'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
}Strona wyświetli font systemowy (San Francisco na macOS/iOS, Segoe UI na Windows, Roboto na Androidzie). Różnice są subtelne dla zwykłego użytkownika i całkowicie niewidoczne dla wyszukiwarek.
To dobre wyjście dla stron, gdzie typografia jest funkcjonalna, nie kluczowy element identyfikacji wizualnej marki. Natomiast jeśli Twoja marka ma ściśle określony krój pisma — self-hosting niestandardowego fontu zachowuje spójność wizualną bez zewnętrznych zależności.
Podsumowanie
Standardowe osadzanie Google Fonts przez zewnętrzny CDN to małe, ale realne ryzyko RODO i mierzalne spowolnienie strony. W 2026 roku — gdy organy ochrony danych intensywniej badają przepływy danych, a Google PageSpeed coraz precyzyjniej ocenia wydajność — warto wyeliminować ten problem raz, zamiast tłumaczyć go klientom lub regulatorom.
Zmiana jest prosta i jednorazowa: pobierz pliki fontów, wgraj na własny serwer, zaktualizuj CSS. Trwa kilkanaście minut, nie wymaga programisty i jest możliwa na każdej popularnej platformie — WordPress, Astro, dowolny serwer statyczny.
Wskazówka na dziś: otwórz swoją stronę w Chrome, naciśnij F12 → Network i wpisz googleapis w filtrze. Jeśli widzisz wyniki — masz konkretne zadanie na ten tydzień. Jeśli chcesz przy okazji przejrzeć inne aspekty techniczne strony firmowej — chętnie to zrobimy razem.