13 Kilobytes: What a WordPress Theme Really Has to Weigh

With load time promises, it pays to ask what exactly was measured. “Under one second” depends on the server and on where you measure from. A Lighthouse score depends on the content of the test page. What belongs firmly to the theme and cannot be argued away, on the other hand, is the amount of CSS and JavaScript it puts on every page. That is exactly what we measured.

The figures

Measured on September 6, 2026 in the shipped package of Hafen 1.0.0, the version that sat in the official theme directory from September 4 to September 22. The browser needs exactly two files for rendering, both from your own server:

So 9,533 bytes in two requests go over the wire. gzip is the cautious figure here, because every host delivers it; the Brotli value next to it was measured at the highest compression level, and servers that compress on the fly stay a little above it in everyday use. So that you arrive at the same figures: measured on the package hafen-1.0.0.zip with node:zlib, gzip at the default level 6, Brotli at level 11. Other tools deviate by a few bytes; for the same file we measured 9,522 to 9,555 bytes depending on the program. That does not change the conclusion, but it does change a comparison of figures, which is why the tool is named here. A third file deliberately does not appear in the table: from theme.json, WordPress generates the global styles and writes them into the page head. They then count towards the transfer size of the HTML document and cost no request of their own.

What has been added since 0.8.1

Up to 1.0.0 a good two kilobytes more over the wire, with 1.1.0 almost three and a half more: anyone who remembers the old figure may ask what for. The same measurement across the version series, style.css and hafen.js together each time, from the shipped packages:

Up to 1.0.0, the biggest jump lay between 0.8.0 and 0.9.1, and it holds no new feature package but what flowed back from a real migration: a magazine grid for the blog overview, a designed fallback for posts without an image, touch-friendly targets in the pagination. The jump from five to 37 looks, on the other hand, cost only 1,218 bytes of CSS, because a look is a JSON file and not an extra line of stylesheet.

And one figure did not move at all for a long time: hafen.js stayed at 1,948 bytes from 0.8.0 to 1.0.0, across all looks and all releases. That is no coincidence but the limit we set ourselves. Whatever CSS can do gets no JavaScript. With 1.1.0 the file grew for the first time, to 3,344 bytes: the header now stays in view while scrolling, and the script measures its height so that a jump to a heading does not land underneath it. CSS alone cannot do that.

The font is the exception, not the rule

The default look, that is the preset from theme.json, brings Inter as one single variable font file, 48,256 bytes for all weights from 100 to 900. With Hafen 1.1.0, the theme’s entire share of a page comes to 61,243 bytes in this one case. That is the full amount, nothing is added from outside: no Google Fonts, no icon font, no CDN.

As soon as you pick one of the 38 looks in the Site Editor under Styles, the font file drops out. Each of the 38 variations replaces the Inter preset with a system font stack, without a fontFace of its own, and the theme notices this by itself: the preload hint in the page head switches off in that case instead of requesting 48 kilobytes for a font that is used nowhere. What remains with Hafen 1.1.0 are the 12,987 bytes for CSS and JavaScript. Which 38 looks these are and how they differ in colour, typography, shape and density is described in Hafen 1.0: One Theme, 38 Looks, Zero Font Files.

If you want to keep the colours of the default and only get rid of the font, take the Launch variation. It changes nothing but the typography: Segoe UI on Windows, San Francisco on Apple devices, Roboto on Android. The other 37 looks additionally bring their own colour palette and their own corner radii, but they do not load a font file either.

Where the weight usually comes from

For comparison, it is worth looking at what a typical theme brings along without anyone having done anything wrong. A page builder theme loads its own framework, plus an icon set, often jQuery and a slider library, usually on every page, whether or not the page contains a slider. The expensive part is not even the size, but the time the browser spends executing all of it.

We do have one measured figure on this, though not from a page builder but from Neve, a theme that is rightly considered one of the faster classic ones. When a grown production site moved to Hafen, same day, same method, unchanged plugin set, the JavaScript of the mobile home page fell from 621 to 382 kilobytes and the First Contentful Paint from 3.9 to 1.3 seconds. The difference of 239 kilobytes comes from the theme layer alone; the plugins were not touched. The complete series of measurements across four page types is in our case study on the theme switch. We have no series of measurements of our own for a page builder theme, which is why there is no figure for one here either.

Hafen comes from a different direction. Layout, colours, spacing and typography live entirely in theme.json, and WordPress generates the necessary CSS from it by itself. There is no framework, because there is none the block editor does not already bring along. And there is no JavaScript for things CSS can do; the 3,344 bytes in the Hafen 1.1.0 package handle the sticky header, including measuring its height for anchor links, and the gentle fade-in while scrolling, nothing more. On top of that, two filters in the theme make sure that WordPress only loads the block CSS that actually occurs on the page instead of the complete block library.

Everything that is not presentation deliberately lives outside the theme, in the companion plugin Hafen Core: structured data, llms.txt, answer blocks. That is no quirk but a rule of the directory, because functionality has to survive a theme switch. Everything about the theme, its looks and the companion plugin is on the Hafen page.

And now the honest part

A light theme does not make a slow website fast. It only removes one of several causes, and usually not the biggest one.

In practice, three other items dominate. Images, when they are uploaded at full camera resolution and scaled down with CSS; a single image like that weighs more than the entire theme. Plugins that load their scripts on every page instead of only where they are needed. And hosting, because no front-end optimisation helps against a server response that keeps you waiting for a second.

So if you want to make an existing site faster, you do not start with the theme. The way there is described in our article WordPress Slow? 10 Steps That Make Your Site Fast Again, and it applies regardless of which theme is running. This article answers the other question: what a theme contributes when you start fresh or switch.

Frequently asked questions