Google Fonts lokalnie w WordPressie: RODO, wyrok LG München i bezwyciekowa architektura WOFF2

Dynamiczne ładowanie krojów pisma z serwerów fonts.googleapis.com i fonts.gstatic.com przez lata uchodziło za standard w motywach WordPressa. Wystarczyło dodać jeden tag <link> w sekcji <head>, aby przeglądarka pobrała nowoczesne fonty. Z perspektywy prawa o ochronie danych osobowych oraz optymalizacji Core Web Vitals to rozwiązanie generuje jednak poważne ryzyka prawne i techniczne.

W tym przewodniku analizujemy stan prawny po głośnym wyroku sądu w Monachium, wyjaśniamy dlaczego adres IP jest daną osobową i pokazujemy, jak wdrożyć bezwyciekową architekturę fontów WOFF2 w WordPressie i WooCommerce przy pomocy sprawdzonych narzędzi.

#1. Wyrok LG München I (sygn. akt 3 O 17493/20): fakty i konsekwencje

Dnia 20 stycznia 2022 r. Sąd Krajowy w Monachium (Landgericht München I, 3. Izba Cywilna, sygn. akt 3 O 17493/20) wydał wyrok, który zapoczątkował falę wezwań przedsądowych i kontroli witryn w całej Unii Europejskiej.

#Stan faktyczny

Pozwana spółka prowadziła stronę internetową, na której osadziła czcionki Google Fonts ładowane bezpośrednio z infrastruktury Google LLC w Stanach Zjednoczonych. Przy każdym wywołaniu strony przez użytkownika jego przeglądarka automatycznie wysyłała zapytanie HTTP do serwerów Google, przekazując m.in.:

1. Pełny publiczny adres IP użytkownika.
2. Nagłówek User-Agent (wersję systemu operacyjnego i przeglądarki).
3. Adres URL strony odsyłającej (Referer).

#Ocena prawna sądu

Sąd orzekł, że doszło do bezprawnego przetwarzania danych osobowych:

• Adres IP jako dane osobowe: Zgodnie z art. 4 pkt 1 rozporządzenia (UE) 2016/679 (RODO) oraz utrwalonym orzecznictwem Trybunału Sprawiedliwości Unii Europejskiej (wyrok w sprawie Patrick Breyer przeciwko RFN, C-582/14 z 19 października 2016 r.), dynamiczny adres IP stanowi dane osobowe, o ile administrator lub podmiot trzeci posiada prawne środki umożliwiające identyfikację użytkownika.
• Brak podstawy z art. 6 ust. 1 lit. a RODO: Użytkownik nie wyraził uprzedniej, świadomej i dobrowolnej zgody na przekazanie swojego adresu IP do Google LLC.
• Odrzucenie przesłanki prawnie uzasadnionego interesu (art. 6 ust. 1 lit. f RODO): Pozwany argumentował, że ładowanie fontów z serwerów zewnętrznych jest uzasadnione estetyką i optymalizacją działania strony. Sąd jednoznacznie odrzucił tę argumentację. Wskazał, że czcionki Google Fonts mogą być w prosty sposób pobrane i hostowane lokalnie przez administratora witryny bez przekazywania jakichkolwiek danych do podmiotów trzecich w państwach trzecich (zgodnie z ogólną zasadą transferu danych z art. 44 RODO).
• Zasądzone odszkodowanie: Na podstawie art. 82 ust. 1 RODO sąd przyznał powodowi zadośćuczynienie w wysokości 100 EUR za naruszenie jego prawa do samostanowienia informacyjnego oraz zagroził pozwanemu karą do 250 000 EUR za ponowne naruszenie.

#2. Dlaczego banery zgody (Cookie Banners) nie rozwiązują problemu?

Częstym błędem popełnianym przez agencje i właścicieli sklepów jest próba ukrycia żądań do Google Fonts za mechanizmem blokowania skryptów w platformie CMP (Consent Management Platform).

Takie podejście niesie ze sobą istotne wady:

1. Paskudny efekt FOIT / FOUT: Jeśli użytkownik nie kliknie “Akceptuję” lub wybierze tylko cookies niezbędne, witryna wyświetla się w systemowych krojach awaryjnych (np. Times New Roman lub Arial), powodując przesunięcia układu (Cumulative Layout Shift - CLS).
2. Opóźnienie renderowania: Fonty ładują się dopiero po przetworzeniu zgody przez JavaScript, co drastycznie pogarsza Largest Contentful Paint (LCP).
3. Niepotrzebna utrata konwersji: Użytkownik, który odmawia zgody na pliki śledzące, powinien otrzymać pełnowartościowy, czytelny i profesjonalny sklep.

Wniosek jest bezdyskusyjny: kroje pisma nie są narzędziem analitycznym ani marketingowym. Powinny stanowić integralny, lokalny zasób serwisu internetowego.

#3. Korzyści wydajnościowe lokalnego hostingu (Core Web Vitals)

Przekonanie, że zewnętrzny CDN Google jest szybszy od własnego hostingu, było prawdziwe w 2012 roku, kiedy przeglądarki współdzieliły pamięć podręczną (cache) między domenami. Od wielu lat mechanizm ten został wycofany ze względów bezpieczeństwa (ochrona przed atakami fingerprinting i cache probing). Każda domena posiada obecnie własną, izolowaną przestrzeń pamięci podręcznej.

Przejście na serwowanie lokalne daje wymierne zyski:

Dzięki wykorzystaniu protokołu HTTP/2 lub HTTP/3 przeglądarka pobiera pliki krojów w ramach jednego, już otwartego kanału transmisji. W połączeniu z dyrektywą font-display: swap; całkowicie eliminujemy zjawisko niewidocznego tekstu podczas ładowania.

#4. Przegląd rozwiązań technicznych w ekosystemie WordPressa

Na rynku WordPressa funkcjonują dwa podstawowe podejścia do rozwiązania problemu czcionek zewnętrznych.

#A. Wtyczki wyspecjalizowane: OMGF (Host Webfonts Locally)

Stworzona przez Daana van den Bergha wtyczka OMGF (dawniej Host Webfonts Locally) to uznane narzędzie dedykowane wyłącznie czcionkom Google.

• Jak działa: Analizuje wywołania nagłówkowe w poszukiwaniu stylów z fonts.googleapis.com, pobiera odpowiednie pliki WOFF2 do folderu wp-content/uploads/omgf/ i generuje lokalny arkusz stylów CSS.
• Zalety: Skupienie na jednym zadaniu, zaawansowane opcje podmiany krojów w wersji płatnej.
• Ograniczenia: Dodatkowa osobna wtyczka w panelu; w wersji darmowej wymaga ręcznego przeładowywania i konfiguracji cache krojów.

#B. Zintegrowany pakiet zgodności e-commerce: Shoplex

W polskim i europejskim handlu elektronicznym sklep WooCommerce musi spełniać szereg powiązanych wymogów: dyrektywę Omnibus (najniższa cena z 30 dni), przepisy B2B, prawo odstąpienia od umowy, system kaucyjny oraz Europejski Akt o Dostępności (EAA).

Wtyczka Shoplex integruje te wymogi w jednym, lekkim silniku i zawiera wbudowany moduł LocalFontsService:

• Automatyczna detekcja zero-leakage: Przechwytuje zarejestrowane arkusze stylów przez filtr style_loader_src oraz czyści tagi <link rel="preconnect" href="https://fonts.gstatic.com">.
• Obsługa nowoczesnych formatów: Pobiera wyłącznie zoptymalizowane pliki WOFF2 z podzbiorem znaków łacińskich i rozszerzonych (latin-ext), co gwarantuje pełne wsparcie dla polskich znaków diakrytycznych (ą, ę, ć, ź, itp.).
• Brak dodatkowego obciążenia serwera: Pobrane fonty są przechowywane w pamięci podręcznej i serwowane statycznie z nagłówkami Cache-Control: public, max-age=31536000, immutable.

#5. Jak działa bezwyciekowa architektura pod maską?

Jeżeli tworzysz własny motyw lub wtyczkę, możesz wdrożyć ten wzorzec bezpośrednio w kodzie PHP i CSS.

#Krok 1: Wyrejestrowanie zewnętrznych zasobów motywu

Wiele motywów (np. Astra, GeneratePress, OceanWP) domyślnie dodaje czcionki Google. Aby je zneutralizować, korzystamy z akcji wp_enqueue_scripts z wysokim priorytetem:

add_action( 'wp_enqueue_scripts', function(): void {
    // Odpinamy arkusze podpinane przez motyw
    wp_dequeue_style( 'theme-google-fonts' );
    wp_deregister_style( 'theme-google-fonts' );
}, 999 );

#Krok 2: Usunięcie dyrektyw preconnect do zewnętrznych serwerów

Warto upewnić się, że motyw nie wysyła nagłówków preconnect do serwerów Google, co samo w sobie mogłoby zdradzić adres IP użytkownika:

add_filter( 'wp_resource_hints', function( array $urls, string $relation_type ): array {
    if ( in_array( $relation_type, array( 'preconnect', 'dns-prefetch' ), true ) ) {
        $urls = array_filter( $urls, static function( string $url ): bool {
            return ! str_contains( $url, 'fonts.googleapis.com' )
                && ! str_contains( $url, 'fonts.gstatic.com' );
        } );
    }
    return $urls;
}, 10, 2 );

#Krok 3: Deklaracja lokalnych krojów w arkuszu stylów CSS

Pliki .woff2 umieszczamy w katalogu motywu potomnego (child theme) lub w katalogu uploadów, a w pliku CSS definiujemy regułę @font-face:

@font-face {
    font-family: 'Inter';
    font-style: normal;
    font-weight: 400;
    font-display: swap;
    src: url('/wp-content/themes/twoj-motyw/assets/fonts/inter-v13-latin_latin-ext-regular.woff2') format('woff2');
    unicode-range: U+0000-00FF, U+0100-02AF;
}

@font-face {
    font-family: 'Inter';
    font-style: normal;
    font-weight: 700;
    font-display: swap;
    src: url('/wp-content/themes/twoj-motyw/assets/fonts/inter-v13-latin_latin-ext-700.woff2') format('woff2');
    unicode-range: U+0000-00FF, U+0100-02AF;
}

Dzięki podaniu unicode-range przeglądarka pobierze plik fontu wyłącznie wtedy, gdy na stronie pojawi się tekst wykorzystujący zdefiniowane glify.

#6. Checklista weryfikacji w DevTools (zero wycieków)

Po wdrożeniu zmian należy zweryfikować poprawność konfiguracji w narzędziach deweloperskich przeglądarki:

1. Otwórz stronę w trybie prywatnym (Incognito).
2. Otwórz Narzędzia Deweloperskie (klawisz F12) i przejdź do zakładki Sieć (Network).
3. W polu filtra wpisz: fonts.
4. Odśwież stronę (Ctrl+F5 lub Cmd+Shift+R).
5. Kryterium sukcesu:
   • Brak jakichkolwiek żądań do domen fonts.googleapis.com oraz fonts.gstatic.com.
   • Wszystkie pliki .woff2 ładowane są bezpośrednio z domeny Twojego sklepu (lub Twojego zaufanego CDN).
   • Nagłówek odpowiedzi zawiera content-type: font/woff2 oraz odpowiedni nagłówek pamięci podręcznej.

#Podsumowanie

Wyrok Landgericht München I był czytelnym sygnałem dla całej europejskiej branży internetowej: wygoda programisty nie może stać ponad prywatnością użytkownika, zwłaszcza gdy bezpieczna alternatywa jest prosta w realizacji.

Lokalne serwowanie krojów pisma w WordPressie to rzadki przypadek optymalizacji, która łączy w sobie stuprocentową zgodność z prawem ochrony danych (art. 6 ust. 1 lit. a i f RODO) z realnym zyskiem na szybkości ładowania witryny (Core Web Vitals). Niezależnie od tego, czy wybierzesz dedykowaną wtyczkę taką jak OMGF, kompleksowy pakiet zgodności Shoplex, czy samodzielną konfigurację motywu, eliminacja zewnętrznych wywołań do Google Fonts powinna być standardem w każdym nowoczesnym wdrożeniu.