Un site Joomla qui met six secondes à s'afficher, ça ne se voit pas dans le back-office. Tout est vert, tout est à jour, aucune alerte. Et pourtant vous perdez des visiteurs — sur mobile, en 4G moyenne, sur un réseau saturé, c'est la réalité de la majorité de votre audience.
J'ai repris le site d'une association culturelle sous Joomla 4 l'an dernier. Un template acheté 59 euros, huit extensions tierces, un hébergement mutualisé à 3 euros par mois. Score PageSpeed mobile : 24 sur 100. LCP mesuré à la main avec Lighthouse : 5,8 secondes. Trois semaines plus tard, sans changer de serveur, on est descendus à 71 sur mobile et 2,1 s de LCP. Ce n'est pas spectaculaire, ce n'est pas magique, et rien de ce qu'on a fait n'est propre à Joomla. C'est juste de la méthode — et surtout un ordre d'exécution.
La plupart des articles sur le sujet vous vendent du cache et de la compression. C'est bien. C'est aussi ce que tout le monde fait déjà, et ça ne suffit pas quand le vrai problème est ailleurs, dans trois fichiers CSS qui bloquent le rendu.
Points clés à retenir
- Mesurez d'abord, optimisez ensuite : sans baseline chiffrée (LCP, TTFB, CLS), vous naviguez à l'aveugle.
- L'ordre d'intervention compte : hébergement et PHP avant les extensions, les extensions avant le template, le template avant le cache.
- Le cache Joomla masque les problèmes, il ne les résout pas — un site lent sans cache reste lent avec cache pour les visiteurs non connectés.
- Les scripts CSS/JS bloquants dans le
<head>coûtent souvent plus cher que le poids des images. - Chaque extension désactivée est un gain mesurable ; chaque extension activée doit justifier sa présence.
- Un CDN ne répare pas un serveur lent, mais il répare très bien un temps de réponse géographique médiocre.
Optimiser la vitesse de chargement d'un site Joomla commence par un diagnostic, pas par des réglages
La tentation, quand un site rame, c'est d'ouvrir la configuration et de cocher tout ce qui contient le mot "cache". Je l'ai fait. Sur un site de restaurant sous Joomla 3, j'ai activé le plugin Page Cache, le cache conservateur, Gzip, et j'ai attendu. Résultat : aucun changement perceptible sur le TTFB, parce que le problème était un serveur mutualisé qui mettait 900 ms à répondre avant même d'exécuter une seule ligne de PHP.
Avec quels outils mesure-t-on vraiment ?
Trois outils suffisent, et ils ne mesurent pas la même chose :
- PageSpeed Insights — utile pour le score mobile et les recommandations, mais son score fluctue d'un test à l'autre. Prenez-le comme un indicateur de tendance, pas comme une vérité absolue.
- GTmetrix ou WebPageTest — pour le waterfall. C'est là que vous voyez quel fichier bloque, dans quel ordre, et pendant combien de temps. C'est l'outil qui m'a fait comprendre que deux fichiers CSS de 340 Ko à eux deux représentaient 1,4 s de rendu bloqué.
- Lighthouse en local (onglet Performance de Chrome) — pour les métriques labo reproductibles, les mêmes conditions à chaque test. Indispensable pour comparer avant/après.
Les métriques à cibler concrètement
Le vocabulaire a changé depuis quelques années. Les Core Web Vitals tournent autour de trois chiffres :
| Métrique | Ce qu'elle mesure | Cible raisonnable | Seuil d'alerte |
|---|---|---|---|
| LCP | Affichage du plus grand élément visible | < 2,5 s | > 4 s |
| TTFB | Réponse serveur, avant tout rendu | < 600 ms | > 1,2 s |
| CLS | Stabilité visuelle (éléments qui sautent) | < 0,1 | > 0,25 |
| Poids total page | Somme des ressources | < 2 Mo | > 4 Mo |
Votre TTFB est le premier chiffre à regarder. S'il dépasse la seconde sur une page mise en cache, aucun réglage Joomla ne vous sauvera.
Dans quel ordre optimiser un site Joomla ?
Voici l'erreur que je vois le plus souvent : quelqu'un commence par compresser les images, puis s'étonne que rien ne bouge. Il optimise le dixième étage d'un immeuble dont les fondations sont pourries.
L'ordre qui marche, dans mon expérience, va du plus structurel au plus cosmétique :
Étape 1 : le serveur et PHP
Avant de toucher à Joomla, vérifiez trois choses côté hébergement :
- La version de PHP. Si vous êtes encore sur du 7.4, vous perdez l'essentiel des gains de performance des versions récentes. Une migration vers une version supportée est la première action à valeur ajoutée.
- OPcache activé. C'est un cache de bytecode PHP qui évite de recompiler les scripts à chaque requête. Sur un hébergement mutualisé mal configuré, il est parfois désactivé — et c'est invisible depuis Joomla.
- HTTP/2 ou HTTP/3. Le multiplexage change la donne quand vous chargez trente ressources. Sur HTTP/1.1, chaque fichier coûte une connexion.
Si vous êtes sur du mutualisé à bas prix, il est possible que tout soit déjà saturé. J'ai vu des serveurs partagés où le TTFB passait de 400 ms à 2,3 s selon l'heure, sans changement de code. Dans ce cas, aucune optimisation Joomla ne compensera la contention.
Étape 2 : le tri dans les extensions
Chaque extension chargée ajoute du code PHP exécuté à chaque requête, et souvent ses propres fichiers CSS/JS. La méthode est brutale mais efficace : désactivez tout, mesurez, réactivez une par une.
Sur le site associatif dont je parlais, une extension de galerie photo ajoutait secrètement 180 Ko de JavaScript sur toutes les pages, y compris celles sans galerie. Elle a été remplacée par trois lignes de CSS et un lazy loading natif. Gain : 600 ms sur mobile.
Un détail : Joomla moderne propose une console de performance dans l'administration. Elle liste les extensions qui consomment du temps d'exécution. C'est le point de départ le plus rapide, et personne ne l'ouvre jamais.
Étape 3 : le template et les builders
C'est souvent là que ça fait mal. Un template premium chargé de fonctionnalités — sliders, animations, widgets — embarque des bibliothèques entières. Un page builder ajoute par-dessus sa propre couche CSS, parfois ses propres appels réseau.
La question à se poser : de quelles fonctionnalités du template avez-vous réellement besoin ? J'ai vu des sites charger Font Awesome en entier pour trois icônes. Remplacer le pack complet par trois SVG inline, c'est 70 Ko économisés pour un rendu identique.
Étape 4 : les fichiers CSS et JS bloquants
Le navigateur doit télécharger et analyser tous les CSS du <head> avant de peindre quoi que ce soit. C'est la partie la plus technique, celle qui demande un peu de courage :
- Repérer les scripts non essentiels et ajouter
deferouasync. - Combiner et minifier les feuilles de style, ou au minimum identifier celles qui ne servent que sur certaines pages.
- Placer en bas de page les scripts qui n'ont pas besoin de bloquer le rendu.
Attention : sur Joomla, ces modifications passent souvent par une surcharge du template ou par un plugin dédié. Modifier directement le fichier du template, c'est perdre le travail à la première mise à jour. J'ai appris ça à mes dépens.
Étape 5 : cache, Gzip et CDN
Vient seulement maintenant le cache — celui dont tous les articles vous parlent en premier.
Joomla propose plusieurs niveaux : le cache des pages (plugin System - Page Cache), le cache du navigateur, et les modes conservateur/progressif. Le mode conservateur est plus sûr ; le progressif est plus agressif mais peut casser certains modules dynamiques comme les paniers e-commerce ou les formulaires personnalisés par utilisateur.
Un piège classique : activer le cache des pages et découvrir que votre module de connexion ou votre tunnel de commande se comporte bizarrement. Testez toujours avec un compte utilisateur réel, pas en visiteur anonyme.
Gzip se configure côté serveur, généralement via .htaccess sur Apache. Et un CDN a du sens si votre audience est dispersée géographiquement — pas avant d'avoir réglé le TTFB, sinon il ne fait que distribuer une réponse lente depuis davantage d'endroits.
Comment mesurer les gains sans se raconter d'histoires ?
Un chiffre isolé ne veut rien dire. Ce qui compte, c'est l'écart entre deux mesures dans des conditions identiques.
- Notez la baseline : Lighthouse mobile, trois lancements, prenez la médiane (pas le meilleur score).
- Modifiez une seule chose à la fois.
- Re-mesurez, toujours trois lancements, médiane.
- Consignez l'écart, même s'il est nul ou négatif.
Sur l'association, le journal a fini par ressembler à ça : désactivation d'une extension → LCP −0,8 s. Passage à PHP récent → TTFB −400 ms. Nettoyage des CSS du template → LCP −1,1 s. Images en format moderne et dimensionnées correctement → poids de page divisé par deux. Total : 5,8 s → 2,1 s.
Aucune des actions n'est impressionnante isolément. C'est leur accumulation dans le bon ordre qui produit le résultat.
Ce qui ne sert à rien, et ce qui dessert activement
J'ai gaspillé des heures sur des choses qui ne changent rien au ressenti utilisateur :
- Minifier un fichier CSS de 4 Ko. Le gain est mesurable en laboratoire et invisible en conditions réelles.
- Convertir des images déjà légères. À partir d'un certain poids, le coût de décodage dépasse le gain de transfert.
- Installer un plugin de "boost" offert dans un pack. J'en ai testé un qui minifiait tout en ligne et cassait silencieusement les scripts admin d'une extension tierce. Retiré le jour même.
Et il y a les optimisations qui nuisent : le lazy loading appliqué à l'image LCP. Si vous différez le chargement de votre plus grand élément visible, vous retardez mécaniquement le LCP. C'est contre-intuitif et c'est une erreur que j'ai commise pendant plusieurs semaines sans comprendre pourquoi mon score stagnait.
Autre classique : empiler trois plugins de cache. Ils se marchent dessus, produisent des contenus périmés, et l'un d'eux finit par générer des erreurs 500 intermittentes impossibles à reproduire. Un seul système, bien configuré.
Le cache, d'ailleurs, mérite une nuance qu'on lit rarement : il masque les lenteurs pour les visiteurs anonymes. Si le site est lent à cause d'un template mal conçu, le cache le rend rapide pour tout le monde sauf pour vous, quand vous êtes connecté. Vous ne voyez donc jamais le problème que voit votre audience non connectée. Mesurez déconnecté, ou en navigation privée.
La question à se poser avant chaque optimisation
Est-ce que ça change quelque chose pour un visiteur qui attend sur son téléphone ? Si la réponse honnête est non, ne le faites pas.
Un site Joomla rapide n'est pas un site truffé de plugins de performance. C'est un site léger, sur un serveur correct, avec un template sobre et des extensions qui se justifient. Le reste, c'est du réglage.
Et si vous ne devez retenir qu'une chose : mesurez votre TTFB en premier. Si le serveur met une seconde à répondre, tout ce que vous ferez au-dessus ne sera jamais qu'une manière élégante de ne rien régler.
