Jour 11 - Optimiser les performances du blog sans casser le thème

Un blog lent perd des lecteurs, même avec un excellent contenu. L’objectif n’est pas le score parfait, mais une navigation fluide.

On applique des optimisations simples et solides qui tiennent dans le temps.

Objectif d’apprentissage

Améliorer le temps de chargement réel du blog, sans refonte front, avec des optimisations pragmatiques.

Ce que tu vas pratiquer aujourd’hui

• Configurer le cache HTTP pour les pages publiques.
• Optimiser le chargement des images.
• Limiter le JavaScript non essentiel.
• Mesurer avant/après avec une base claire.

1. Activer des headers de cache adaptés

Les pages blog publiques changent peu à la minute. Un cache HTTP raisonnable améliore immédiatement la vitesse perçue.

Pense à invalider proprement lors des publications.

$response = $this->render('blog/index.html.twig', [...]);
$response->setPublic();
$response->setMaxAge(300);
$response->setSharedMaxAge(600);

return $response;

2. Optimiser les images côté template

Ajoute loading="lazy", decoding="async" et des dimensions explicites quand possible.

Ce trio réduit le layout shift et accélère le rendu initial.

<img
    src="{{ imageUrl }}"
    alt="{{ imageAlt }}"
    loading="lazy"
    decoding="async"
    width="960"
    height="540"
>

3. Nettoyer le JS non critique

Supprime les scripts non utilisés sur les pages blog. Chaque script inutile coûte du CPU et du réseau.

Commence par auditer les dépendances chargées globalement.

php bin/console debug:container --env=prod | grep -i stimulus
npm run build

Checklist de fin de session

• Cache HTTP activé sur les pages publiques.
• Images non critiques en lazy loading.
• Largeur/hauteur définies sur les médias.
• JS inutile retiré ou différé.

Erreurs fréquentes à éviter

• Sauter la vérification finale parce que “ça marche chez moi”.
• Mélanger trop de logique dans le controller au lieu de garder un flux clair.
• Oublier la cohérence entre la donnée, le template Twig et le comportement en production.

Pourquoi cette étape compte en conditions réelles

Dans un vrai projet client, chaque étape technique doit rester compréhensible par l’équipe, duplicable sur un autre environnement et fiable dans le temps. Ici, l’objectif est de transformer la théorie en un flux de travail concret, avec des décisions simples que tu peux défendre en revue de code.

Si tu appliques sérieusement les points du jour (configurer le cache http pour les pages publiques.), tu réduis la dette technique dès le départ et tu facilites la suite: SEO, publication, maintenance et déploiement. C’est exactement la différence entre un blog “démo” et un blog exploitable en production.

Mini plan de révision

• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Configurer le cache HTTP pour les pages publiques.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Optimiser le chargement des images.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Limiter le JavaScript non essentiel.

Exercice rapide

Mesure la différence avant/après avec PageSpeed et note 3 améliorations concrètes observées.

Et demain ?

Demain, on termine la série par un plan de déploiement production propre, logs et supervision.