13 kilobyte: wat een WordPress-thema echt moet wegen

Bij beloftes over laadtijd loont het om te vragen wat er precies gemeten is. “Onder een seconde” hangt af van de server en van de plek waar je meet. Een Lighthouse-score hangt af van de inhoud van de testpagina. Wat daarentegen vast bij het thema hoort en niet weg te praten is, is de hoeveelheid CSS en JavaScript die het op elke pagina zet. Precies die hebben we gemeten.

De cijfers

Gemeten op 6 september 2026 in het uitgeleverde pakket van Hafen 1.0.0, dus in de versie die van 4 tot 22 september in de officiële themadirectory stond. De browser heeft precies twee bestanden nodig voor de weergave, allebei van je eigen server:

Over de lijn gaan dus 9.533 bytes in twee requests. gzip is hier het voorzichtige getal, omdat elke hoster het levert; de Brotli-waarde ernaast is gemeten met het hoogste compressieniveau, en servers die dynamisch comprimeren blijven er in de praktijk iets boven. Zodat je op dezelfde cijfers uitkomt: gemeten aan het pakket hafen-1.0.0.zip met node:zlib, gzip op het standaardniveau 6, Brotli op niveau 11. Andere tools wijken een paar bytes af; bij hetzelfde bestand hebben we afhankelijk van het programma 9.522 tot 9.555 bytes gemeten. Op de conclusie heeft dat geen invloed, op een vergelijking van cijfers wel, daarom staat de tool hier vermeld. Een derde bestand staat bewust niet in de tabel: uit de theme.json genereert WordPress de globale stijlen en schrijft ze in de paginakop. Die tellen dan mee in de overdrachtsgrootte van het HTML-document en kosten geen eigen request.

Wat er sinds 0.8.1 bij is gekomen

Tot 1.0.0 ruim twee kilobyte meer over de lijn, met 1.1.0 nog eens bijna drieënhalf: wie het oude getal nog weet, mag vragen waarvoor. Dezelfde meting over de versiereeks, telkens style.css en hafen.js samen, uit de uitgeleverde pakketten:

Tot 1.0.0 lag de grootste sprong tussen 0.8.0 en 0.9.1, en daar zit geen nieuw featurepakket in, maar wat een echte migratie heeft opgeleverd: een magazineraster voor het blogoverzicht, een vormgegeven terugvaloptie voor berichten zonder afbeelding, tikvriendelijke doelen in de paginering. De sprong van vijf naar 37 looks kostte daarentegen maar 1.218 bytes CSS, omdat een look een JSON-bestand is en geen extra regel stylesheet.

En één getal heeft lange tijd helemaal niet bewogen: hafen.js bleef van 0.8.0 tot 1.0.0 onveranderd op 1.948 bytes, in alle looks en alle releases. Dat is geen toeval, maar de grens die we onszelf hebben gesteld. Wat CSS kan, krijgt geen JavaScript. Met 1.1.0 is het bestand voor het eerst gegroeid, naar 3.344 bytes: de paginakop loopt nu mee bij het scrollen, en het script meet zijn hoogte, zodat een sprong naar een kop niet onder hem terechtkomt. Dat kan CSS alleen niet.

Het lettertype is de uitzondering, niet de regel

De standaardlook, dus de voorinstelling uit de theme.json, brengt Inter mee als één enkel variabel lettertypebestand, 48.256 bytes voor alle gewichten van 100 tot 900. Met Hafen 1.1.0 komt het totale aandeel van het thema in een pagina in dit ene geval uit op 61.243 bytes. Dat is het hele bedrag, er komt niets van buitenaf bij: geen Google Fonts, geen icoonlettertype, geen CDN.

Zodra je in de site-editor onder Stijlen een van de 38 looks kiest, valt het lettertypebestand weg. Elk van de 38 variaties vervangt de standaard-Inter door een stack van systeemlettertypen, zonder eigen fontFace, en het thema merkt dat zelf: de preload-hint in de paginakop schakelt zich in dat geval uit, in plaats van 48 kilobyte op te vragen voor een lettertype dat nergens gebruikt wordt. Bij Hafen 1.1.0 blijven de 12.987 bytes voor CSS en JavaScript over. Welke 38 looks dat zijn en hoe ze verschillen in kleur, typografie, vorm en dichtheid, lees je in Hafen 1.0: één thema, 38 looks, nul lettertypebestanden.

Wie de kleuren van de standaard wil houden en alleen van het lettertype af wil, kiest de variatie Launch. Die verandert niets behalve de typografie: Segoe UI onder Windows, San Francisco op Apple-apparaten, Roboto onder Android. De andere 37 looks brengen daarnaast een eigen kleurenpalet en eigen hoekradii mee, maar laden evenmin een lettertypebestand.

Waar het gewicht anders vandaan komt

Ter vergelijking loont het om te kijken wat een gangbaar thema meebrengt zonder dat iemand iets verkeerd heeft gedaan. Een thema met page builder laadt zijn eigen framework, daarbij een iconenset, vaak jQuery en een sliderbibliotheek, meestal op elke pagina, ongeacht of de pagina een slider bevat. Het dure deel is daarbij niet eens de grootte, maar de tijd die de browser besteedt aan het uitvoeren.

Eén gemeten getal hebben we daarover wel, alleen niet van een page builder, maar van Neve, een thema dat terecht als een van de snellere klassieke thema’s geldt. Bij de verhuizing van een gegroeide productiesite naar Hafen, zelfde dag, zelfde methode, ongewijzigde plugins, daalde het JavaScript van de mobiele homepage van 621 naar 382 kilobyte en de First Contentful Paint van 3,9 naar 1,3 seconde. Het verschil van 239 kilobyte komt alleen uit de themalaag, aan de plugins is niets veranderd. De volledige meetreeks over vier paginatypen staat in onze praktijkcase over de themawissel. Voor een thema met page builder hebben we geen eigen meetreeks, daarom staat hier ook geen getal voor.

Hafen komt uit een andere richting. Lay-out, kleuren, afstanden en typografie staan volledig in de theme.json, en WordPress genereert daar zelf de benodigde CSS uit. Er is geen framework, omdat er geen bestaat dat de blokeditor niet al meebrengt. En er is geen JavaScript voor dingen die CSS kan; de 3.344 bytes in het pakket van Hafen 1.1.0 regelen de sticky header, inclusief het meten van zijn hoogte voor ankerlinks, en het zachte infaden bij het scrollen, meer niet. Daarnaast zorgen twee filters in het thema ervoor dat WordPress alleen de blok-CSS laadt die echt op de pagina voorkomt, in plaats van de complete blokbibliotheek.

Alles wat geen weergave is, zit bewust niet in het thema, maar in de begeleidende plugin Hafen Core: gestructureerde data, llms.txt, antwoordblokken. Dat is geen gril, maar een regel van de directory, want functies moeten een themawissel overleven. Alles over het thema, de looks en de begeleidende plugin staat op de Hafen-pagina.

En nu het eerlijke deel

Een licht thema maakt een trage website niet snel. Het haalt alleen een van meerdere oorzaken weg, en meestal niet de grootste.

In de praktijk domineren drie andere posten. Afbeeldingen, als ze in volle cameraresolutie worden geüpload en met CSS worden verkleind; één zo’n afbeelding weegt meer dan het hele thema. Plugins die hun scripts op elke pagina laden in plaats van alleen waar ze nodig zijn. En de hosting, want geen enkele optimalisatie in de frontend helpt tegen een serverrespons die een seconde op zich laat wachten.

Wie een bestaande site sneller wil maken, begint dus niet bij het thema; deze drie posten tellen, welk thema er ook draait. Dit artikel beantwoordt de andere vraag: wat een thema bijdraagt als je opnieuw begint of overstapt.

Veelgestelde vragen