Comment mesure-t-on la sobriété d’une page web ? La réponse la plus répandue consiste à parler d’octets transférés : plus une page est légère, moins elle consomme d’énergie pour être transmise et affichée. Un audit d’écoconception mené sur le site d’une fédération sportive régionale a pourtant commencé ailleurs, avec une question moins visible : combien de travail le serveur fournit-il pour produire cette page, indépendamment de son poids final ?
La page la plus consultée du site, un annuaire des clubs affiliés classés par département, pesait 1,8 mégaoctet, essentiellement à cause d’une vingtaine de logos non compressés. La réaction naturelle aurait été de commencer par cette compression. L’audit a pourtant révélé, en ouvrant Query Monitor, que cette même page déclenchait 61 requêtes SQL à chaque chargement, dont la majorité provenait d’une seule boucle mal écrite.
Le calcul avant le poids : ce que révèle le temps de génération
Le temps de génération PHP de la page, hors temps réseau, atteignait 640 millisecondes. Une bonne partie de ce temps servait à exécuter, pour chacun des soixante clubs affichés, une requête get_post_meta() distincte afin de récupérer le département, une autre pour la ville, une troisième pour le nombre de licenciés. Le code, écrit plusieurs années auparavant, ressemblait à ceci :
foreach ( $clubs as $club ) {
$departement = get_post_meta( $club->ID, 'departement', true );
$ville = get_post_meta( $club->ID, 'ville', true );
$licencies = get_post_meta( $club->ID, 'nb_licencies', true );
// affichage...
}Chaque appel à get_post_meta() déclenche en réalité une lecture dans le cache d’objets si les métadonnées ont déjà été préchargées, mais ce préchargement n’avait jamais été mis en place : la boucle interrogeait donc la base de données trois fois par club, soit 180 requêtes potentielles, réduites à 61 grâce à un cache partiel déjà en place sur certaines métadonnées.
Le correctif : précharger avant de boucler
La fonction update_meta_cache(), ou plus simplement le passage par une requête WP_Query avec l’argument update_post_meta_cache activé par défaut, permet de charger en une seule fois les métadonnées de tous les articles d’un lot. Le code corrigé :
$ids = wp_list_pluck( $clubs, 'ID' );
update_meta_cache( 'post', $ids );
foreach ( $clubs as $club ) {
$departement = get_post_meta( $club->ID, 'departement', true );
$ville = get_post_meta( $club->ID, 'ville', true );
$licencies = get_post_meta( $club->ID, 'nb_licencies', true );
}Résultat : les 61 requêtes sont tombées à 4, la boucle continuant d’appeler get_post_meta() normalement mais en lisant désormais le cache d’objets déjà rempli en une seule opération groupée. Le temps de génération est passé de 640 à 95 millisecondes.
Ce que la compression d’images a réellement apporté ensuite
Une fois ce correctif appliqué, la compression des logos a été menée en complément, ramenant le poids de la page de 1,8 mégaoctet à 640 kilo-octets. Un gain réel, mais d’une nature différente : il réduit la quantité de données transmises sur le réseau, sans influer sur la charge de calcul supportée par le serveur à chaque visite. Sur un site à fort trafic, cette charge de calcul se traduit directement par une consommation électrique du serveur, cumulée sur des milliers de requêtes quotidiennes.
Deux formes de sobriété qui ne se mesurent pas pareil
- Le poids d’une page se mesure en octets transférés, et concerne surtout le réseau et l’appareil du visiteur.
- Le temps de génération se mesure en millisecondes de calcul, et concerne le serveur qui héberge le site, potentiellement mutualisé avec des centaines d’autres sites.
- Une boucle de requêtes non préchargée pèse sur ce second aspect, invisible dans un audit qui ne regarderait que la taille des fichiers transmis.
Un audit de sobriété qui ne regarde que le poids des images ignore la moitié de la facture : celle que paie le serveur à chaque requête, silencieusement, page après page.
En résumé
La compression des images reste une étape utile, mais elle n’était pas, sur ce site, le premier poste d’économie. Le vrai gain de sobriété est venu d’une boucle de requêtes SQL corrigée, invisible dans le poids final de la page mais bien réelle dans la charge supportée par le serveur à chaque chargement. Un audit d’écoconception gagne à commencer par ouvrir Query Monitor avant d’ouvrir un compresseur d’images.
