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 juste les reproches à la place d’un mauvais hébergement, 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. Joomla, lui, fait ce qu’on lui demande. Le souci, c’est surtout ce qu’on lui fait porter sur le dos. Les outils et la documentation Joomla prévoient pourtant des leviers natifs comme le cache, le plugin de cache de page et la compression Gzip. Google, de son côté, continue de mesurer l’expérience perçue avec les Core Web Vitals.

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. Découvrez notre guide Joomla ou nos offres de site web.

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 saboté
• des scripts tiers traînent dans tous les coins
• certaines extensions font de la musculation sur chaque requête
• le site essaie d’être intelligent partout, tout le temps, pour tout le monde

Les métriques à surveiller restent les Core Web Vitals. LCP mesure la vitesse d’affichage du contenu principal. INP mesure la réactivité. CLS mesure la stabilité visuelle. Les seuils de référence restent 2,5 secondes ou moins pour le LCP, 200 millisecondes ou moins pour l’INP et 0,1 ou moins pour le CLS. INP a officiellement remplacé FID comme indicateur de réactivité en 2024.

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
• le desktop
• le temps de réponse serveur
• le poids total
• 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. Un score seul ne raconte pas l’histoire. Il faut croiser les mesures de laboratoire et les données réelles, ce que Google recommande aussi via ses ressources sur les Web Vitals et ce que Search Console affiche dans son rapport Core Web Vitals.

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, si la base répond comme un lundi pluvieux, vous pouvez compresser vos images toute la nuit, vous n’allez pas faire de miracle. LCP dépend aussi fortement du temps de réponse initial, et les docs web.dev rappellent clairement que les retards côté serveur pèsent sur l’affichage du contenu principal.

2. Un template trop ambitieux pour son propre bien

Certains templates veulent tout faire. Animation, effets, sliders, icônes, bibliothèques, variantes, dépendances, surcouches, 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 images héro chargées trop tard, des dimensions non réservées, du lazy loading mal appliqué, et vous obtenez un joli cocktail pour dégrader LCP et CLS. Google recommande le lazy loading, mais pas n’importe comment. Son documentation Search Central précise qu’il faut s’assurer que le contenu chargé en différé reste accessible au crawl, et qu’il ne faut pas masquer le contenu principal derrière une interaction. Les ressources Google sur les images rappellent aussi que l’image principale ne doit pas être traitée comme un élément secondaire.

Et oui, une image de 3800 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 aussi parce qu’il réfléchit trop longtemps avant de répondre.

C’est là qu’INP devient très utile. Cette métrique regarde la latence des interactions sur l’ensemble de la visite. Quand vous avez du JavaScript partout, des scripts marketing, des widgets, des balises mal rangées et quelques bonus exotiques, le navigateur passe 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 d’un système de cache natif et de plusieurs niveaux de mise en cache, avec notamment le plugin System Page Cache et des réglages dans la configuration globale. La documentation officielle explique aussi que la compression Gzip peut réduire la taille des pages HTML envoyées au navigateur, tout en rappelant que cela peut être inutile ou conflictuel si le serveur gère déjà la compression.

Mais activer un cache à l’aveugle n’est pas une stratégie non plus. Sur des pages très dynamiques, des formulaires, des parcours connectés ou certains modules, un cache mal pensé peut vous donner un site plus rapide, certes, mais aussi plus faux. Et un site rapide qui raconte n’importe quoi reste un problème.

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

Là encore, je préfère être clair. 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é

On commence par les gros leviers :

• serveur
• cache
• images
• scripts tiers
• poids front
• extensions les plus coûteuses

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

Quand optimiser et quand refaire

Il y a deux cas de figure.

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
• pages les plus stratégiques

Et 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. Il travaille dans le web depuis 2004 et dans l’IT depuis 2005. 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. Son obsession n’est pas de livrer un site qui marche aujourd’hui. C’est de livrer un site qui marche encore demain, après les mises à jour, après les évolutions, et quand on commence à tirer dessus un peu sérieusement.