La performance, ce n'est pas un score Lighthouse qu'on affiche fièrement une fois. C'est une discipline. Voici trois leviers qu'on applique systématiquement — ce qu'ils apportent, pourquoi, où ils vont, et comment on s'en sert.
1. AVIF : diviser le poids des images
Ce que ça apporte. AVIF dérive du codec vidéo AV1. À qualité égale, il produit des fichiers 30 à 50 % plus légers que le WebP, et bien plus encore face au JPEG. Sur une page, c'est souvent le poste d'économie n° 1.
Pourquoi ça compte. Les images représentent la majeure partie du poids d'une page. Diviser ce poids, c'est mécaniquement une page plus rapide, un meilleur LCP et une facture allégée. En 2026, AVIF est supporté par ~93–95 % des navigateurs (Chrome, Firefox, Edge, Opera, Safari 16+, iOS 16+).
<picture>
<source type="image/avif" srcset="photo.avif">
<source type="image/webp" srcset="photo.webp">
<img src="photo.jpg" loading="lazy" decoding="async" alt="…">
</picture>Le piège. L'encodage AVIF est lent : on l'effectue à l'upload ou au build (jamais à la volée), on génère plusieurs tailles, et on met le résultat en cache. C'est exactement ce que fait notre ImageProcessor.
Le futur des images : JPEG XL
JPEG XL (norme ISO depuis 2022) a connu un parcours chaotique : ajouté dans Chrome derrière un flag en 2021, retiré en 2023, puis réintroduit dans Chrome 145 début 2026 (toujours derrière un flag, décodeur en Rust). Safari le supporte par défaut depuis la 17 ; au total, ~16 % de support natif.
Son atout massue : la recompression JPEG sans perte — réduire un JPEG d'environ 20 % de façon réversible. Mais en 2026 on ne sert pas du JXL seul : la stratégie reste AVIF en principal, WebP/JPEG en repli, et on prépare JXL pour plus tard.
| Format | Support 2026 | Compression | Quand l'utiliser |
|---|---|---|---|
| WebP | ~97 % | −25–35 % vs JPG | Fallback sûr |
| AVIF | ~93–95 % | −30–50 % vs WebP | Format principal aujourd'hui |
| JPEG XL | ~16 % (Safari, Chrome derrière un flag) | ≈ AVIF + recompression JPEG sans perte | À préparer pour demain |
2. Redis : le cache qui change tout
Ce que ça apporte. Redis est un magasin clé-valeur en mémoire. Tout ce qui est coûteux mais stable — configurations, menus, fragments, agrégats — y est stocké et ressort en millisecondes. Il sert aussi aux sessions et aux files d'attente.
Pourquoi ça compte. Sans cache, chaque visite refrappe la base. Avec Redis, la base respire et les pages répondent instantanément. La seule vraie difficulté : l'invalidation — vider la bonne clé au bon moment.
// CodeIgniter 4 — mémoriser un agrégat lourd 5 min
$key = "stats:dashboard:{$userId}";
$data = cache($key);
if ($data === null) {
$data = $this->statsModel->heavyAggregate($userId);
cache()->save($key, $data, 300);
}
return $data;Le futur de Redis : Valkey
En mars 2024, Redis a quitté sa licence open source BSD pour un modèle source-available (RSALv2/SSPL). En réaction, la Linux Foundation (AWS, Google, Oracle, Ericsson…) a créé Valkey, un fork open source de Redis 7.2.4 sous licence BSD. Redis 8 est depuis repassé en AGPL, mais Valkey continue de grandir.
En pratique, Valkey est compatible au protocole : remplacement direct, sans changement de code. Comme Redis 7.2 est en fin de vie (février 2026), pour de l'auto-hébergement (OVH/Plesk) Valkey est le pari open source le plus tranquille.
3. Lazy-load : ne charger que le visible
Ce que ça apporte. Le lazy-load diffère le chargement des images et iframes hors écran : moins d'octets au premier rendu, un time-to-interactive plus court. C'est aujourd'hui natif avec loading="lazy", supporté partout.
La nuance. On ne lazy-load pas l'image la plus importante du haut de page (le LCP) : on lui donne au contraire la priorité avec fetchpriority="high". Pour le réglage fin, on complète avec vanilla-lazyload.
<!-- Image plein écran (LCP) : priorisée, pas lazy -->
<img src="hero.avif" fetchpriority="high" decoding="async" alt="…">
<!-- Le reste : différé -->
<img src="carte.avif" loading="lazy" decoding="async" alt="…">Le fil rouge : mesurer, pas deviner
Ces trois leviers ne valent que si on les vérifie. On profile (Lighthouse, WebPageTest), on surveille les Core Web Vitals (LCP, INP, CLS), on traque les requêtes N+1 et les assets bloquants. La performance se gagne sur des faits, pas sur des intuitions.
Le web sobre n'est pas une posture écolo de façade : une page légère, c'est une page rapide, moins chère à servir, et accessible même sur une connexion bretonne capricieuse.