Un bloc entièrement statique, sans la moindre ligne de JavaScript côté front, peut malgré tout charger une police web de trois cent kilo-octets, une image non compressée et deux feuilles de style entières pour n’utiliser que quelques règles. À l’inverse, un bloc interactif bien écrit, chargé seulement quand nécessaire et communiquant avec le serveur de façon économe, peut peser moins lourd au chargement qu’un bloc « sans JavaScript » mal optimisé. L’équation de la sobriété numérique appliquée à un bloc ne se résume donc pas à l’absence de script.
Ce qui pèse réellement dans le chargement d’un bloc
Trois facteurs dominent très largement l’empreinte réelle d’un bloc, bien avant la présence ou non de JavaScript : le poids total transféré (images, polices, feuilles de style spécifiques au bloc), le nombre de requêtes réseau déclenchées à son affichage, et le coût de calcul serveur nécessaire à son rendu quand il s’agit d’un bloc dynamique. Un bloc « Galerie » qui charge systématiquement une bibliothèque de diaporama complète, même pour afficher trois images fixes sans aucune interaction, coûte objectivement plus cher qu’un bloc interactif ciblé, chargé uniquement sur les pages qui en ont besoin via viewScript.
Mesurer avant de conclure
L’audit d’un bloc pour en réduire l’empreinte commence par une mesure, pas par une intuition. Les outils de développement du navigateur, onglet réseau, permettent de comparer le poids total transféré pour une page contenant le bloc contre la même page sans lui, ainsi que le nombre de requêtes déclenchées. Pour un bloc dynamique, l’onglet performance permet en complément d’observer le temps de calcul PHP consacré à son rendu, particulièrement révélateur lorsque le bloc effectue une requête WP_Query mal ciblée.
// Avant : deux appels REST séparés pour un même bloc
apiFetch( { path: '/wp/v2/posts?per_page=3' } );
apiFetch( { path: '/wp/v2/categories?per_page=10' } );
// Après : une seule requête, champs réduits au strict nécessaire
apiFetch( {
path: '/wp/v2/posts?per_page=3&_fields=id,title,link&_embed=false',
} );
Le poids caché des dépendances embarquées
Un bloc qui embarque une bibliothèque JavaScript entière pour n’en utiliser qu’une fraction (un composant de sélection de date complet pour afficher un simple calendrier statique, par exemple) alourdit chaque page qui le contient, y compris celles où l’interactivité n’est jamais sollicitée par le visiteur. Ce constat pousse à préférer des solutions plus ciblées : un composant natif de @wordpress/components déjà chargé par l’éditeur, ou une implémentation minimale écrite spécifiquement pour le besoin, plutôt qu’une dépendance généraliste importée pour un usage restreint.
Le cas du rendu dynamique mis en cache
Pour un bloc dynamique interrogeant la base de données à chaque affichage, mettre en cache le résultat via l’API transient (set_transient / get_transient) réduit un coût de calcul serveur réel, sans changer la moindre ligne du rendu perçu par le visiteur. Ce gain, invisible dans l’onglet réseau du navigateur, se mesure côté serveur : nombre de requêtes SQL exécutées, temps de génération de la page, charge cumulée sur un site à fort trafic.
- Mesurer le poids transféré réel du bloc, pas seulement la présence ou l’absence de JavaScript.
- Compter les requêtes réseau déclenchées, y compris celles issues de dépendances tierces embarquées.
- Chiffrer le coût de calcul serveur d’un bloc dynamique, et envisager un cache transitoire dès qu’il devient significatif.
La bonne question à poser sur un bloc n’est jamais « contient-il du JavaScript ? » mais « que transfère-t-il réellement, et combien de fois ce transfert se répète-t-il par page ? ». Cette reformulation change presque toujours la priorité des optimisations à mener.
Où porter l’effort en priorité
Sur la plupart des audits, l’essentiel du gain vient de trois actions simples : réduire les images et polices chargées par le bloc à leur strict format utile, fusionner les appels réseau redondants, et mettre en cache le calcul serveur des blocs dynamiques les plus consultés. La suppression pure et simple d’une interactivité utile, au nom d’une sobriété mal comprise, dégrade l’expérience sans gain mesurable si le script retiré était déjà léger et correctement chargé de façon conditionnelle.
En résumé
Un bloc réellement sobre se juge à son poids transféré, au nombre de requêtes qu’il déclenche et au coût de calcul qu’il impose au serveur, jamais à la seule présence ou absence de JavaScript. Mesurer ces trois facteurs avant toute décision évite de sacrifier une interactivité utile au nom d’une sobriété numérique mal ciblée, tout en révélant souvent des gains bien plus significatifs ailleurs dans le bloc.
