Mon site Joomla est lent : comment trouver le vrai problème avant de tout refaire

Un site Joomla lent, c’est un peu comme une voiture qui avance mal. Tout le monde accuse le moteur, alors que parfois le vrai problème, c’est le coffre rempli de parpaings, les pneus à plat et le frein à main encore levé.

Dans beaucoup de cas, Joomla n’est pas le coupable principal. Il prend les reproches à la place d’un hébergement mal dimensionné, d’un template trop chargé, d’extensions empilées sans logique, d’images envoyées à la truelle ou de scripts tiers qui se servent généreusement au passage.

Et c’est exactement pour ça que je n’aime pas les diagnostics du dimanche matin du type : « le site est lent, donc il faut tout refaire ». Non. L’espoir n’est pas une stratégie. Le coup de pelleteuse non plus.

Article publié initialement le 15 mars 2026 – mis à jour le 12 août 2026.

Mon site Joomla est lent : la synthèse

Quand un client me dit que son site Joomla est lent, je ne pars jamais bille en tête sur le CMS. Je commence par regarder ce qui se passe réellement.

Parce qu’un site lent, ce n’est pas un diagnostic. C’est un symptôme.

Et un symptôme, ça peut venir de plusieurs endroits :

• le serveur répond mal ;
• la page envoie trop de poids ;
• le template charge trop de CSS et de JavaScript ;
• les images sont mal gérées ;
• le cache est absent, mal réglé ou contredit par le fonctionnement du site ;
• des scripts tiers traînent dans tous les coins ;
• certaines extensions travaillent beaucoup trop sur chaque requête ;
• le site essaie d’être intelligent partout, tout le temps, pour tout le monde.

Les trois Core Web Vitals restent LCP, INP et CLS. Les seuils de référence de Google restent : LCP à 2,5 s ou moins, INP à 200 ms ou moins et CLS à 0,1 ou moins. Pour les données terrain, Google évalue ces métriques au 75e percentile des chargements.

Le TTFB n’est pas un Core Web Vital, mais je le regarde très tôt parce qu’un serveur qui met trop de temps à commencer à répondre handicape tout ce qui arrive derrière. Dans PageSpeed Insights, Google classe actuellement un TTFB jusqu’à 800 ms comme « bon ».

Autrement dit, si vous ne mesurez pas le bon problème, vous pouvez passer trois semaines à optimiser ce qui n’était même pas le frein principal. Et ça, c’est typiquement le genre de chantier premium qu’on se fabrique tout seul.

Ce que je regarde en premier

Ma première règle est simple : je veux savoir si le site est lent partout, ou seulement à certains endroits.

Je regarde d’abord :

• la page d’accueil ;
• une page de contenu standard ;
• une page plus lourde ;
• le mobile et le desktop ;
• le temps de réponse serveur ;
• le poids total transféré ;
• le nombre de requêtes ;
• les scripts tiers ;
• les images les plus lourdes ;
• le comportement avec et sans cache.

Je ne me contente pas d’un score PageSpeed qu’on regarde avec gravité comme si on lisait un électrocardiogramme. PageSpeed Insights peut présenter à la fois des mesures de laboratoire et des données réelles issues de CrUX lorsqu’il y en a suffisamment. Et quand une URL manque de données terrain, l’outil peut basculer sur les données de l’origine entière — ou ne rien afficher du tout côté terrain.

C’est important : deux personnes peuvent tester la même page et parler de deux choses différentes sans s’en rendre compte.

Note de Laurent

Je vais être un peu taquin, mais pas méchant : coller une URL dans un outil, voir rouge, puis conclure que Joomla est lent, ce n’est pas un audit. C’est une montée d’adrénaline.

Les vraies causes d’un Joomla lent

1. Un hébergement trop léger ou mal configuré

C’est le grand classique. On incrimine Joomla alors que le serveur a déjà du mal à se lever le matin.

Si le TTFB est mauvais, si le CPU sature, si la mémoire manque ou si la base de données traîne, vous pouvez compresser vos images toute la nuit : vous n’allez pas transformer le site en fusée.

Je regarde donc la version de PHP, la mémoire disponible, la base, le serveur web, le cache serveur éventuel et les limites réelles du forfait d’hébergement.

2. Un template trop ambitieux pour son propre bien

Certains templates veulent tout faire. Animations, sliders, icônes, bibliothèques, variantes, dépendances, effets et parfois un peu de poésie au passage.

Le problème, c’est qu’un template qui veut être brillant partout devient souvent lourd partout. Et quand on ajoute un page builder par-dessus avec trois extensions qui font la même chose, on obtient un site qui a l’air moderne mais qui monte les escaliers en soufflant.

3. Des images gérées sans amour ni discipline

Là, on touche à un sujet que je vois revenir sans arrêt.

Des visuels envoyés en taille XXL pour être affichés en miniature, des dimensions non réservées, du lazy loading appliqué sans réfléchir et vous obtenez un joli cocktail pour dégrader LCP et CLS.

Le lazy loading est utile pour les images hors écran. En revanche, l’image principale qui devient le LCP n’a généralement aucun intérêt à attendre gentiment qu’on veuille bien la charger. Je préfère l’identifier, la dimensionner correctement et la rendre disponible le plus tôt possible.

Et oui, une image de 3 800 pixels pour illustrer un bloc de 600, c’est du zèle. Pas de l’optimisation.

4. Trop de JavaScript et trop de tiers qui bavardent

Le site n’est pas lent uniquement parce qu’il télécharge des fichiers. Il peut être lent parce qu’il réfléchit trop longtemps avant de répondre.

C’est là qu’INP devient particulièrement intéressant. Quand vous avez du JavaScript partout, des scripts marketing, des widgets, des balises mal rangées et quelques bonus exotiques, le navigateur passe parfois plus de temps à exécuter qu’à servir l’utilisateur.

5. Des extensions installées comme si c’était gratuit en maintenance

Une extension seule n’est pas forcément un problème. Dix extensions qui se chevauchent, si.

Chaque brique ajoute potentiellement du code, des appels, des styles, des scripts, des traitements, des risques de conflit et parfois une belle surprise après mise à jour.

C’est pour ça que je préfère toujours un site avec moins de couches, mais des couches choisies proprement. La qualité entraîne la rentabilité. Là, ce n’est pas un slogan. C’est juste de l’exploitation.

6. Un cache absent, mal réglé ou contredit par la réalité

Joomla dispose de plusieurs mécanismes de cache. Le plugin System – Page Cache peut stocker le HTML complet d’une page et le resservir sans régénérer tout le contenu à chaque requête.

Mais il faut connaître son comportement. La documentation Joomla précise notamment qu’une modification d’article ne vide pas automatiquement le page cache : la version en cache peut continuer à être servie jusqu’à expiration ou nettoyage manuel. Le plugin permet aussi d’exclure certaines URLs et certains éléments de menu.

Donc oui, le cache peut faire beaucoup de bien. Mais activer tout ce qui contient le mot « cache » dans l’administration n’est pas une stratégie.

Versions Joomla, PHP et hébergement : le socle compte

En août 2026, Joomla 6.1.2 est la version stable actuelle de Joomla 6 et Joomla 5.4.7 reste maintenu. Les deux branches sont supportées, mais elles n’ont pas exactement la même trajectoire.

Pour un projet neuf, je regarderais naturellement Joomla 6, après contrôle de la compatibilité du template et des extensions. Pour un site Joomla 5 qui fonctionne correctement, je ne transforme pas une montée de version majeure en concours de vitesse : on prépare, on teste et on migre quand l’écosystème du site est prêt.

Joomla 6 recommande PHP 8.4 et supporte PHP 8.3 au minimum. Joomla 5 recommande PHP 8.3 et supporte encore PHP 8.1 au minimum. Côté hébergement, une version PHP moderne et supportée ne garantit pas à elle seule de bonnes performances, mais rester sur un environnement ancien sans raison n’aide personne.

Ce qu’il ne faut pas faire

Changer de CMS comme réflexe nerveux

Passer de Joomla à autre chose ne supprime pas par magie un mauvais hébergement, des médias trop lourds, un front mal maîtrisé ou une équipe qui installe tout ce qui bouge.

On ne règle pas un problème de discipline technique en changeant juste l’étiquette sur la boîte.

Installer trois plugins d’optimisation en espérant une forme de miracle

Empiler les rustines sur un site déjà confus, c’est souvent une manière élégante de rendre la panne plus difficile à lire.

Corriger au hasard sans ordre de priorité

Je commence par les gros leviers :

• serveur et TTFB ;
• cache ;
• images ;
• JavaScript et scripts tiers ;
• poids du front ;
• extensions les plus coûteuses ;
• requêtes ou traitements anormalement lourds.

Pas par la troisième police d’icône chargée sur une page secondaire que personne ne visite.

Quand optimiser et quand refaire

Cas numéro un : le site est récupérable

C’est le cas le plus fréquent.

Le socle est correct. Le contenu est exploitable. L’arborescence tient debout. Le site souffre, mais il n’est pas condamné.

Là, on optimise : hébergement, cache, compression, médias, front, scripts, modules et pages les plus stratégiques. Puis on mesure à nouveau.

Cas numéro deux : le site est structurellement mal né

Là, on parle d’un site où tout est enchevêtré : template ingérable, builder trop intrusif, dépendances partout, extensions obsolètes, logique de page incohérente, dette technique installée comme une tradition familiale.

Dans ce cas, oui, une refonte peut être plus rentable qu’une suite infinie de rustines. Mais la refonte doit être une décision d’architecture. Pas une réaction vexée à un score Lighthouse.

Ce plan n’a rien d’exotique. Et c’est plutôt rassurant. On trace, on avance pas à pas, on teste, on déploie, on vérifie. C’est moins sexy qu’une promesse miracle. Mais c’est comme ça qu’on évite de fabriquer un petit animal sauvage qu’il faudra apprivoiser tous les mois.

À propos de l’auteur

Laurent Lacoste est architecte web et fondateur de TooNetCreation. Son terrain, ce sont l’architecture, la sécurité, les déploiements, la supervision et la performance. Il aime les systèmes carrés, propres et capables de tenir dans le temps.