13 kilobajtów: ile naprawdę musi ważyć motyw do WordPressa

Przy obietnicach dotyczących czasu ładowania warto zapytać, co dokładnie zmierzono. „Poniżej sekundy” zależy od serwera i od miejsca pomiaru. Wynik Lighthouse zależy od zawartości strony testowej. Tym, co na stałe należy do motywu i czego nie da się podważyć, jest ilość CSS i JavaScriptu, którą motyw dokłada do każdej strony. Właśnie ją zmierzyliśmy.

Liczby

Pomiar z 6 września 2026, wykonany na opublikowanej paczce Hafen 1.0.0, czyli na wersji, która od 4 do 22 września była dostępna w oficjalnym katalogu motywów. Do wyświetlenia strony przeglądarka potrzebuje dokładnie dwóch plików i oba pochodzą z własnego serwera:

Przez sieć przesyłane są więc 9 533 bajty w dwóch żądaniach. Wartość dla gzip jest przy tym zachowawcza, bo gzip obsługuje każda firma hostingowa; wartość Brotli obok zmierzyliśmy przy najwyższym poziomie kompresji, a serwery kompresujące w locie w praktyce wypadają nieco powyżej niej. Jeśli chcesz dojść do tych samych liczb: mierzyliśmy paczkę hafen-1.0.0.zip za pomocą node:zlib, gzip na domyślnym poziomie 6, Brotli na poziomie 11. Wyniki innych narzędzi różnią się o kilka bajtów: dla tego samego pliku, zależnie od programu, zmierzyliśmy od 9 522 do 9 555 bajtów. Na sam wniosek nie ma to wpływu, na porównanie liczb już tak, dlatego podajemy tu narzędzie. Trzeciego pliku celowo nie ma w tabeli: z pliku theme.json WordPress generuje style globalne i zapisuje je w sekcji head strony. Wliczają się one wtedy do rozmiaru transferu dokumentu HTML i nie kosztują osobnego żądania.

Co przybyło od wersji 0.8.1

Do wersji 1.0.0 przybyły dobre dwa kilobajty transferu, wraz z wersją 1.1.0 jeszcze niecałe trzy i pół: kto pamięta starą liczbę, ma prawo zapytać, na co poszły. Ten sam pomiar dla kolejnych wersji, za każdym razem style.css i hafen.js razem, z opublikowanych paczek:

Do wersji 1.0.0 największy skok nastąpił między 0.8.0 a 0.9.1 i nie stoi za nim nowy pakiet funkcji, tylko wnioski z prawdziwej migracji: siatka w stylu magazynu na stronie z listą wpisów, zaprojektowany widok zastępczy dla wpisów bez obrazka, wygodne obszary dotyku w paginacji. Skok z pięciu do 37 wariantów stylu kosztował natomiast tylko 1 218 bajtów CSS, bo wariant to plik JSON, a nie dodatkowa linijka arkusza stylów.

Jedna liczba przez długi czas w ogóle się nie zmieniała: hafen.js od wersji 0.8.0 do 1.0.0 miał niezmiennie 1 948 bajtów, we wszystkich wariantach i wszystkich wydaniach. To nie przypadek, tylko granica, którą sobie wyznaczyliśmy. Tego, co potrafi CSS, nie robimy w JavaScripcie. W wersji 1.1.0 plik po raz pierwszy urósł, do 3 344 bajtów: nagłówek strony pozostaje teraz widoczny podczas przewijania, a skrypt mierzy jego wysokość, żeby śródtytuł po skoku nie chował się pod nagłówkiem. Tego sam CSS nie potrafi.

Czcionka to wyjątek, nie reguła

Styl domyślny, czyli ustawienia z pliku theme.json, zawiera czcionkę Inter jako jeden plik czcionki zmiennej (variable font): 48 256 bajtów dla wszystkich grubości od 100 do 900. W motywie Hafen 1.1.0 cały udział motywu w wadze strony wynosi w tym jednym przypadku 61 243 bajty. To pełna suma, nic nie dochodzi z zewnątrz: ani Google Fonts, ani font z ikonami, ani CDN.

Gdy tylko w edytorze witryny w sekcji Style wybierzesz jeden z 38 wariantów stylu, plik czcionki znika. Każdy z 38 wariantów zastępuje domyślną czcionkę Inter stosem czcionek systemowych, bez własnego fontFace, a motyw sam to wykrywa: wskazówka wstępnego ładowania (preload) w sekcji head wyłącza się w takim przypadku, zamiast pobierać 48 kilobajtów czcionki, której nigdzie się nie używa. W motywie Hafen 1.1.0 zostaje 12 987 bajtów na CSS i JavaScript. Jakie to warianty i czym różnią się pod względem kolorów, typografii, kształtu i gęstości, opisujemy w artykule Hafen 1.0: jeden motyw, 38 wariantów stylu, zero plików czcionek (po angielsku).

Jeśli chcesz zachować kolory stylu domyślnego i pozbyć się tylko czcionki, wybierz wariant Stapellauf. Zmienia on wyłącznie typografię: Segoe UI w systemie Windows, San Francisco na urządzeniach Apple, Roboto na Androidzie. Każdy z pozostałych 37 wariantów ma dodatkowo własną paletę kolorów i własne promienie zaokrągleń, ale również nie ładuje żadnego pliku czcionki.

Skąd jeszcze bierze się waga

Dla porównania warto spojrzeć, co wnosi typowy motyw, nawet jeśli nikt nie zrobił niczego źle. Motyw oparty na page builderze ładuje własny framework, do tego zestaw ikon, często jQuery i bibliotekę slidera, zwykle na każdej stronie, niezależnie od tego, czy strona w ogóle zawiera slider. Najdroższy nie jest przy tym nawet rozmiar, tylko czas, który przeglądarka spędza na wykonywaniu tego kodu.

Mamy na to jedną zmierzoną liczbę, choć nie dla page buildera, tylko dla motywu Neve, który słusznie uchodzi za jeden z szybszych motywów klasycznych. Przy migracji rozbudowanej przez lata strony produkcyjnej na motyw Hafen, tego samego dnia, tą samą metodą i przy niezmienionym zestawie wtyczek, ilość JavaScriptu na mobilnej stronie głównej spadła z 621 do 382 kilobajtów, a First Contentful Paint z 3,9 do 1,3 sekundy. Różnica 239 kilobajtów pochodzi wyłącznie z warstwy motywu, wtyczek nikt nie ruszał. Pełna seria pomiarów dla czterech typów stron jest w naszym studium przypadku zmiany motywu (po angielsku). Dla motywu opartego na page builderze nie mamy własnej serii pomiarów, dlatego nie podajemy tu dla niego żadnej liczby.

Hafen podchodzi do tego od innej strony. Układ, kolory, odstępy i typografia są w całości zapisane w pliku theme.json, a WordPress sam generuje z nich potrzebny CSS. Nie ma frameworka, bo nie ma takiego, który wnosiłby coś, czego system bloków nie zapewnia już sam. Nie ma też JavaScriptu do rzeczy, które potrafi CSS; 3 344 bajty w paczce motywu Hafen 1.1.0 obsługują przyklejony nagłówek (sticky header) wraz z pomiarem jego wysokości na potrzeby kotwic oraz płynne pojawianie się elementów przy przewijaniu, nic więcej. Dwa filtry w motywie dbają dodatkowo o to, żeby WordPress ładował tylko CSS tych bloków, które faktycznie występują na stronie, zamiast całej biblioteki bloków.

Wszystko, co nie dotyczy wyglądu, celowo nie siedzi w motywie, tylko we wtyczce towarzyszącej Hafen Core: dane strukturalne, llms.txt, bloki odpowiedzi. To nie kaprys, tylko zasada katalogu, bo funkcje muszą przetrwać zmianę motywu. Co ten podział oznaczał w procesie weryfikacji, opisujemy w artykule o drodze do oficjalnego katalogu WordPressa (po niemiecku).

A teraz uczciwa część

Lekki motyw nie sprawi, że wolna strona stanie się szybka. Usuwa tylko jedną z kilku przyczyn, i to zwykle nie największą.

W praktyce dominują trzy inne czynniki. Obrazy, jeśli są wgrywane w pełnej rozdzielczości aparatu i zmniejszane dopiero przez CSS; jeden taki obraz waży więcej niż cały motyw. Wtyczki, które ładują swoje skrypty na każdej stronie, a nie tylko tam, gdzie są potrzebne. I hosting, bo żadna optymalizacja we frontendzie nie pomoże, jeśli na odpowiedź serwera trzeba czekać sekundę.

Kto chce przyspieszyć istniejącą stronę, nie zaczyna więc od motywu. Drogę do tego opisuje nasz artykuł Wolny WordPress? 10 kroków, by znów był szybki (po angielsku), a jest ona niezależna od tego, jaki motyw działa na stronie. Ten artykuł odpowiada na inne pytanie: co wnosi motyw, gdy zaczynasz od zera albo zmieniasz motyw.

Najczęściej zadawane pytania