Performance web
Un travail de vitesse sur 4korners.org, le site WordPress public de l'organisme à but non lucratif où je travaille. J'ai mesuré où partaient le temps et les octets, puis j'ai fait passer la page d'accueil de 14 Mo à 3 Mo et ramené la réponse du serveur en cache entre 0,1 et 0,2 s sur chaque page, contre 1,3 à 2,8 s auparavant.
Architecture
Le site roule sur WordPress avec Elementor Pro, sur un VPS. Avant ce travail, il n'avait aucun cache de pages, donc le serveur construisait chaque page à chaque requête, et les images représentaient environ 90 % des 14 Mo de la page d'accueil. J'ai activé WP Super Cache avec un préchargement quotidien, désactivé un calendrier d'événements inutilisé qui chargeait encore ses fichiers sur chaque page, et remplacé un logo de partenaire qui pesait environ 5 Mo par une copie de 24 Ko. Les images passent maintenant par le CDN d'images gratuit de Jetpack, qui redimensionne chacune à la taille où elle est affichée et la sert en WebP.
Décisions clés
Garder Elementor et régler la vitesse à part
Avant de toucher à quoi que ce soit, j'ai fait un audit pour savoir s'il fallait quitter Elementor. Un export statique ajoutait un deuxième abonnement et une étape de publication de plus, et une reconstruction, en thème de blocs ou en site headless, ne se serait jamais rentabilisée. Les pages lentes avaient des causes moins coûteuses à régler, sans lien avec le constructeur de pages, donc Elementor est resté.
Mesurer, puis régler d'abord le plus gros coût
Le premier plan visait le CSS et le JavaScript. Désactiver le calendrier d'événements inutilisé a réduit de 55 % le CSS et le JavaScript de la page d'accueil, mais la réponse du serveur n'a pas bougé, et la première mesure dans le navigateur montrait que les images faisaient environ 90 % de la page. J'ai donc mis l'effort sur le cache de pages et les images, sur le serveur actuel, sans attendre le déménagement prévu vers un nouvel hébergeur.
Un CDN d'images plutôt qu'une extension d'optimisation
L'hébergeur bloque exec() de PHP, donc l'extension d'optimisation que j'avais installée ne pouvait tourner qu'en mode infonuagique limité, et une vérification plus tard a montré qu'elle ne faisait rien du tout. J'ai plutôt activé le CDN d'images gratuit de Jetpack, et le poids des images de la page d'accueil est passé de 7,6 Mo à 1,6 Mo. Il ignore les images d'arrière-plan CSS, donc la photo principale de 853 Ko reste le plus gros fichier de la page, et j'ai choisi de la laisser ainsi.
Le point difficile
Le site en ligne chargeait ses polices depuis le site de test
Les polices et le texte en gras s'affichaient bien dans l'éditeur Elementor et mal sur le site en ligne. Les 13 feuilles de style de polices qu'Elementor garde sur le serveur chargeaient leurs polices depuis le site de test, qui n'envoie aucun en-tête CORS, donc les navigateurs les bloquaient et les visiteurs voyaient une police de remplacement, probablement depuis mars 2025. L'outil de régénération d'Elementor ne touche pas à ces fichiers, alors j'y ai remplacé les URL par le domaine en ligne, en gardant des copies de sauvegarde pour revenir en arrière, et j'ai confirmé zéro erreur de police dans le navigateur. La règle depuis : les copies vont de la production vers le test, jamais dans l'autre sens.
Sécurité et performance
- Désactiver une extension ne la retire pas : ses fichiers restent accessibles depuis le web. Je supprime les extensions que le site n'utilise plus, comme je l'ai fait pour un module payant inutilisé.
- Chaque changement sur le serveur en ligne commence par une sauvegarde. La correction des polices a gardé une copie de chaque fichier modifié, donc chaque étape pouvait être annulée.