Il y a des projets qui naissent d’un besoin client. Il y en a d’autres qui naissent d’un défi lancé un vendredi soir à l’after du WordCamp Bretagne 2026. JuZ Mirage, c’est le deuxième cas. Un clin d’œil à Dareth, Maxime et Valentin, qui savent ce qu’ils ont fait.
Le problème
À chaque image envoyée dans WordPress, le moteur génère entre six et dix sous-tailles. Thumbnail, medium, large, medium_large, plus toutes celles déclarées par le thème et les plugins. La plupart ne sont jamais affichées. Elles s’accumulent sur le disque, alourdissent les sauvegardes, et ralentissent chaque envoi de média.
Sur un site avec une médiathèque conséquente, l’addition devient visible. Sur le projet Colibris, par exemple, les sous-tailles représentaient 4 Go sur 6 Go de médiathèque totale. Deux tiers du stockage pour des fichiers qui ne servent pas.
L’idée de JuZ Mirage : ne plus générer ces sous-tailles à l’envoi, les produire à la demande, les mettre en cache, et les servir ensuite en statique – sans PHP, sans calcul répété.
Comment ça fonctionne
Pour les utilisateurs : rien ne change dans l’éditeur. Le sélecteur de taille, le srcset, l’insertion d’images dans les blocs – tout fonctionne comme avant. La différence est dans ce qui se passe derrière.
Les sous-tailles ne sont plus écrites sur le disque à l’envoi. Elles restent déclarées dans la base de données, donc WordPress les connaît et peut les référencer. Quand un visiteur charge une page pour la première fois, l’image est générée à ce moment-là, mise en cache sur le disque, puis servie directement par le serveur web pour tous les visiteurs suivants. PHP n’intervient plus après ce premier passage.
Pendant le chargement, une version floue de l’image est affichée en pur CSS – quelques centaines d’octets par image, sans JavaScript. C’est désactivable et surchargeable si vous avez déjà votre propre système de placeholder.
Pour les développeurs
Quelques points techniques qui méritent d’être explicités :
- URLs signées et paramètres bornés : personne ne peut faire calculer une taille arbitraire au serveur. Chaque URL est signée, les dimensions sont plafonnées, et le nombre de rendus simultanés est limité.
- WebP automatique pour les JPEG et PNG, avec une seule URL par image. Pas de négociation de contenu, pas de complexité côté cache. AVIF est prévu dans une version Pro.
- Données EXIF retirées des images servies, y compris la géolocalisation.
- Purge automatique des caches de page quand les URLs changent, testée avec WP Rocket, WP Super Cache, W3 Total Cache, WP Fastest Cache, WP-Optimize, Cache Enabler, Breeze et LiteSpeed Cache.
- Compatible multisite.
- Réversible : à la désactivation, le plugin propose de recréer les sous-tailles classiques via WP-CLI ou depuis l’interface.
- Commandes WP-CLI :
wp juzmirage doctor,warmup,stats,cache purge,placeholders. - Sous Apache et LiteSpeed, rien à configurer. Sous nginx, les règles de réécriture nécessaires sont fournies par le plugin dans un onglet dédié.
Les mesures sur des sites réels
Trois sites de profils différents, mesures avant et après activation :
| Site | Fichiers image | Disque | Temps d’envoi des images | Poids images accueil |
|---|---|---|---|---|
| Lepave – agrégateur, 123 images | 699 → 124 (−82 %) | 74 → 43 Mo (−42 %) | 106 → 44 s (−58 %) | 359 → 210 Ko (−42 %) |
| YCI – multisite, 29 images | 159 → 30 (−81 %) | 13 → 5 Mo (−62 %) | 17 → 3,8 s (−77 %) | 761 → 457 Ko (−40 %) |
| Colibris – médiathèque volumineuse | – | −4 Go sur 6 Go (−66 %) | – | 45,8 → 4,4 Mo |
Sur les performances d’affichage : une fois en cache, le temps de réponse est équivalent à une image statique classique, autour de 60 ms. Seul le tout premier visiteur d’une image attend sa génération – entre 0,3 et 0,7 seconde selon la taille et la charge du serveur. La commande wp juzmirage warmup permet de pré-générer les images les plus importantes avant la mise en ligne, pour éviter ce délai en production.
JuZ Mirage n’améliore pas mécaniquement le LCP ou le CLS – il est neutre sur ces métriques. Le gain est ailleurs : moins de fichiers, moins d’octets transférés, moins de calcul serveur. Ce qui est bon pour le disque, les sauvegardes et l’empreinte du site.
Ce que c’est, et ce que ce n’est pas
JuZ Mirage est open source, sous licence GPL, sans service externe, sans compte à créer, sans télémétrie. Il fonctionne avec les thèmes blocs (FSE). Les thèmes classiques ne sont pas pris en charge pour l’instant.
C’est un outil d’éco-conception autant que de performance : moins de fichiers produits, moins de calcul déclenché, moins d’octets stockés et transférés. Sur des sites à forte médiathèque ou à ingestion régulière d’images, l’impact est immédiat.
Cherche testeurs
Avant la publication sur WordPress.org, je cherche des retours sur des environnements variés. Les prérequis :
- WordPress 6.7+ et PHP 8.1+
- Thème blocs (FSE)
- GD ou Imagick disponible
- Sous nginx, ajouter les règles fournies par le plugin (onglet « Règles serveur ») ; sous Apache et LiteSpeed, rien à faire.
Je conseille de tester sur une préproduction plutôt que directement en production, et de lancer wp juzmirage doctor juste après l’installation – la commande vérifie la configuration du serveur et signale les points d’attention.
Les retours qui m’intéressent : hébergeur et serveur web (Apache, nginx, LiteSpeed), thème utilisé, plugins d’images ou de cache en place, et la sortie complète de wp juzmirage doctor.
Pour recevoir le lien de téléchargement, contactez-moi – ici ou en message privé sur LinkedIn. Et merci d’avance aux courageux qui joueront le jeu.
Stack : WordPress FSE · PHP · GD / Imagick · WP-CLI · Apache · nginx · LiteSpeed · GPL