13 kilo-octets : ce qu’un thème WordPress doit vraiment peser

Face aux promesses de temps de chargement, il vaut la peine de se demander ce qui a été mesuré exactement. « Moins d’une seconde » dépend du serveur et du lieu de mesure. Un score Lighthouse dépend du contenu de la page de test. Ce qui, en revanche, appartient durablement au thème et ne se discute pas, c’est la quantité de CSS et de JavaScript qu’il place sur chaque page. C’est précisément ce que nous avons mesuré.

Les chiffres

Mesuré le 6 septembre 2026 dans le paquet publié de Hafen 1.0.0, c’est-à-dire la version présente dans le répertoire officiel des thèmes du 4 au 22 septembre. Le navigateur a besoin d’exactement deux fichiers pour l’affichage, tous deux servis par votre propre serveur :

Sur le réseau passent donc 9 533 octets en deux requêtes. gzip est ici le chiffre prudent, parce que tout hébergeur le fournit ; la valeur Brotli à côté a été mesurée au niveau de compression maximal, et les serveurs qui compressent à la volée restent au quotidien un peu au-dessus. Pour que vous arriviez aux mêmes chiffres : mesuré sur le paquet hafen-1.0.0.zip avec node:zlib, gzip au niveau standard 6, Brotli au niveau 11. D’autres outils s’écartent de quelques octets ; pour le même fichier, nous avons mesuré de 9 522 à 9 555 octets selon le programme. Cela ne change rien au constat, mais bien à une comparaison de chiffres, c’est pourquoi l’outil est indiqué ici. Un troisième fichier n’apparaît volontairement pas dans le tableau : à partir de theme.json, WordPress génère les styles globaux et les écrit dans l’en-tête de la page. Ils comptent alors dans le poids transféré du document HTML et ne coûtent pas de requête propre.

Ce qui s’est ajouté depuis la 0.8.1

Jusqu’à la 1.0.0, un peu plus de deux kilo-octets de plus sur le réseau, avec la 1.1.0 encore presque trois et demi de plus : qui a l’ancien chiffre en tête peut légitimement demander pour quoi. La même mesure sur toute la série de versions, à chaque fois style.css et hafen.js ensemble, à partir des paquets publiés :

Jusqu’à la 1.0.0, le plus grand saut se situait entre la 0.8.0 et la 0.9.1, et il ne contient pas un nouveau lot de fonctionnalités, mais le retour d’expérience d’une vraie migration : une grille magazine pour la page du blog, un visuel de repli soigné pour les articles sans image, des zones faciles à toucher dans la pagination. Le passage de cinq à 37 looks n’a en revanche coûté que 1 218 octets de CSS, parce qu’un look est un fichier JSON et pas une ligne de feuille de style en plus.

Et un chiffre n’a longtemps pas bougé du tout : hafen.js est resté inchangé à 1 948 octets de la 0.8.0 à la 1.0.0, dans tous les looks et toutes les versions. Ce n’est pas un hasard, mais la limite que nous nous sommes fixée. Ce que le CSS sait faire ne reçoit pas de JavaScript. Avec la 1.1.0, le fichier a grossi pour la première fois, à 3 344 octets : l’en-tête suit désormais le défilement, et le script mesure sa hauteur pour qu’un saut vers un titre n’atterrisse pas sous lui. Cela, le CSS seul ne le peut pas.

La police est l’exception, pas la règle

Le look par défaut, c’est-à-dire le réglage prévu dans theme.json, embarque Inter sous la forme d’un seul fichier de police variable, 48 256 octets pour toutes les graisses de 100 à 900. Avec Hafen 1.1.0, la part totale du thème sur une page s’élève dans ce seul cas à 61 243 octets. C’est le montant complet, rien ne s’y ajoute de l’extérieur : ni Google Fonts, ni police d’icônes, ni CDN.

Dès que vous choisissez l’un des 38 looks dans l’éditeur de site sous Styles, le fichier de police disparaît. Chacune des 38 variations remplace la police Inter prévue par défaut par une pile de polices système, sans fontFace propre, et le thème le remarque tout seul : l’indication de préchargement dans l’en-tête de la page se désactive dans ce cas, au lieu de demander 48 kilo-octets pour une police utilisée nulle part. Il reste, avec Hafen 1.1.0, les 12 987 octets de CSS et de JavaScript. Quels sont ces 38 looks et comment ils se distinguent par la couleur, la typographie, la forme et la densité, c’est expliqué dans Hafen 1.0 : un thème, 38 looks, zéro fichier de police.

Si vous voulez garder les couleurs par défaut et seulement vous débarrasser de la police, prenez la variation Launch. Elle ne change rien d’autre que la typographie : Segoe UI sous Windows, San Francisco sur les appareils Apple, Roboto sous Android. Les 37 autres looks apportent en plus leur propre palette de couleurs et leurs propres rayons d’angle, mais ne chargent pas non plus de fichier de police.

D’où vient habituellement le poids

Pour comparer, il est utile de regarder ce qu’un thème courant embarque sans que personne n’ait rien fait de travers. Un thème de page builder charge son propre framework, plus un jeu d’icônes, souvent jQuery et une bibliothèque de carrousel, la plupart du temps sur chaque page, que la page contienne un carrousel ou non. Le plus coûteux n’est même pas la taille, mais le temps que le navigateur passe à exécuter tout cela.

Nous avons un chiffre mesuré à ce sujet, mais pas pour un page builder : pour Neve, un thème considéré à juste titre comme l’un des thèmes classiques les plus rapides. Lors de la migration vers Hafen d’un site en production développé au fil des années, même jour, même méthode, extensions inchangées, le JavaScript de la page d’accueil mobile est passé de 621 à 382 kilo-octets et le First Contentful Paint de 3,9 à 1,3 seconde. La différence de 239 kilo-octets provient de la seule couche du thème, les extensions n’ont pas été touchées. La série complète de mesures sur quatre types de pages figure dans notre étude de cas sur le changement de thème. Pour un thème de page builder, nous n’avons pas de série de mesures propre, c’est pourquoi aucun chiffre ne figure ici à ce sujet.

Hafen part d’une autre direction. La mise en page, les couleurs, les espacements et la typographie se trouvent entièrement dans theme.json, et WordPress en génère lui-même le CSS nécessaire. Il n’y a pas de framework, parce qu’il n’en existe aucun que l’éditeur de blocs n’apporte pas déjà. Et il n’y a pas de JavaScript pour ce que le CSS sait faire ; les 3 344 octets du paquet de Hafen 1.1.0 gèrent l’en-tête fixe, y compris la mesure de sa hauteur pour les ancres, et l’apparition en fondu au défilement, rien de plus. En outre, deux filtres du thème veillent à ce que WordPress ne charge que le CSS des blocs réellement présents sur la page, au lieu de toute la bibliothèque de blocs.

Tout ce qui ne relève pas de l’affichage se trouve volontairement hors du thème, dans l’extension compagnon Hafen Core : données structurées, llms.txt, blocs de réponse. Ce n’est pas une lubie, mais une règle du répertoire, car les fonctionnalités doivent survivre à un changement de thème. Tout sur le thème, ses looks et l’extension compagnon se trouve sur la page de Hafen.

Et maintenant, la partie honnête

Un thème léger ne rend pas rapide un site lent. Il ne supprime qu’une cause parmi plusieurs, et le plus souvent pas la plus importante.

En pratique, trois autres postes dominent. Les images, quand elles sont téléversées en pleine résolution d’appareil photo et réduites en CSS ; une seule image de ce genre pèse plus que tout le thème. Les extensions qui chargent leurs scripts sur chaque page au lieu de là seulement où elles servent. Et l’hébergement, car aucune optimisation côté navigateur n’aide contre une réponse du serveur qui se fait attendre une seconde.

Pour accélérer un site existant, on ne commence donc pas par le thème ; ces trois postes comptent quel que soit le thème installé. Cet article répond à l’autre question : ce qu’un thème apporte quand on démarre de zéro ou qu’on en change.

Questions fréquentes