Mon site WordPress est lent : le diagnostic en 10 étapes (du plus probable au plus rare)

Si ton site WordPress est lent, dans la grande majorité des cas la cause est l’une de ces trois-là : des images trop lourdes, trop d’extensions ou un constructeur de pages qui charge tout sur toutes les pages, et l’absence de cache sur un hébergement sous-dimensionné. La bonne méthode n’est pas d’installer une extension miracle, mais de mesurer d’abord, de corriger dans l’ordre du plus probable au plus rare, puis de re-mesurer après chaque étape. Ce guide suit exactement cet ordre.

Je m’appelle Ayoub Fattami. Développeur web freelance à Marrakech, je reçois « mon site est lent » juste après « mon site est en panne » dans la liste des demandes les plus fréquentes. Elle est plus sournoise qu’une panne : le site fonctionne, personne n’appelle pour se plaindre, mais les visiteurs sur téléphone ferment l’onglet avant d’avoir vu ton numéro. Un site lent est un bug commercial, pas un problème de confort. Commence par la mesure, elle t’évitera de faire les dix étapes à l’aveugle.

Mesurer avant de toucher : PageSpeed, Core Web Vitals, mobile et Maroc

Avant de modifier quoi que ce soit, mesure ton site avec PageSpeed Insights, en mode mobile, sur la page d’accueil et sur une page intérieure. Note les trois Core Web Vitals et le temps de réponse du serveur. Sans cette photo de départ, tu ne sauras jamais quelle étape a réellement servi, et tu risques de passer une journée sur une correction qui ne change rien.

Les outils : PageSpeed Insights et Lighthouse

PageSpeed Insights est l’outil gratuit de Google. Il affiche deux blocs distincts qu’il ne faut pas confondre. En haut, « Découvrez ce que vivent vos utilisateurs » présente les données réelles collectées auprès de tes visiteurs sur les vingt-huit derniers jours ; elles n’apparaissent que si ton site a assez de trafic, et ce sont elles que Google utilise. En dessous, « Diagnostiquer les problèmes de performances » est un test de laboratoire réalisé par Lighthouse, l’outil intégré à Chrome (F12, onglet Lighthouse). Il donne un score et une liste de recommandations.

Lance le test deux ou trois fois : les résultats du laboratoire varient d’un passage à l’autre. Teste au minimum la page d’accueil, une page de service ou de produit, et un article. Et lis les métriques, pas seulement le score : un score global moyen peut cacher un seul problème grave.

Les trois Core Web Vitals expliqués simplement

Les Core Web Vitals (Signaux Web essentiels) sont les trois mesures que Google retient pour juger l’expérience de chargement d’une page. Google les documente sur web.dev, et les seuils ci-dessous sont les siens.

• LCP (Largest Contentful Paint) : le temps que met le plus grand élément visible de l’écran, en général l’image de couverture ou le titre principal, à s’afficher. Bon en dessous de 2,5 secondes. C’est la mesure qui souffre le plus des images lourdes et d’un serveur lent.
• INP (Interaction to Next Paint) : le délai entre un clic ou un tap et la réaction visible de la page. Bon en dessous de 200 millisecondes. Il remplace l’ancien FID depuis mars 2024, et il est dégradé par le JavaScript trop abondant : constructeurs de pages, scripts tiers, animations.
• CLS (Cumulative Layout Shift) : la stabilité visuelle, c’est-à-dire les éléments qui sautent pendant le chargement (une bannière qui pousse le texte, une police qui change). Bon en dessous de 0,1. Il vient des images sans dimensions déclarées, des polices web et des encarts injectés tardivement.

Dans la Search Console, le rapport « Signaux Web essentiels » te montre ces trois mesures pour l’ensemble de tes pages, avec les données de tes vrais visiteurs. C’est le tableau de bord à consulter tous les mois.

Lenteur serveur ou lenteur d’affichage ?

Le TTFB (Time To First Byte) est le temps qui s’écoule entre la demande du navigateur et la réception du premier octet de la page. Il mesure la vitesse du serveur, de PHP et de la base de données, avant que quoi que ce soit ne s’affiche. Google considère qu’un TTFB est bon sous 800 millisecondes.

Cette mesure divise ton diagnostic en deux familles. Un TTFB élevé désigne le serveur : cache absent, hébergement saturé, PHP obsolète, base de données encombrée, site piraté (étapes 3, 5, 7 et 10). Un TTFB correct avec un LCP ou un INP mauvais désigne l’affichage : images, extensions, constructeur de pages, scripts tiers, CSS et JavaScript (étapes 1, 2, 4, 6, 8 et 9). Pour le lire, ouvre F12, onglet Réseau, recharge la page, clique sur la première ligne (le document HTML) et regarde la durée « En attente » dans l’onglet Temps.

Tester depuis le Maroc et sur mobile

Le test de laboratoire de PageSpeed part des serveurs de Google, pas d’un téléphone à Casablanca. Pour voir ce que voient tes clients, ouvre ton site sur un vrai téléphone, en 4G, en navigation privée, hors wifi. Dans Chrome sur ordinateur, tu peux aussi simuler une connexion lente : F12, onglet Réseau, menu de limitation, « 4G lente ». Ton prestataire en fibre depuis un bureau ne voit pas ce que voit un client sur un téléphone à Agadir ou à Oujda.

Note maintenant tes valeurs de départ : LCP, INP, CLS, TTFB, poids total de la page (F12, onglet Réseau, ligne « transféré » en bas) et nombre de requêtes. C’est ton « avant ». Chaque étape ci-dessous se termine par un nouveau test.

Étape 1 : des images trop lourdes ou mal dimensionnées

Sur les sites WordPress que j’audite au Maroc, c’est de très loin la cause numéro un. Une photo prise avec un téléphone et uploadée telle quelle dans une page pèse plusieurs mégaoctets, là où quelques dizaines de kilooctets suffiraient à l’écran. Multiplie par une galerie de vingt photos, et tu as ta lenteur.

Symptôme : LCP élevé, page très lourde, images qui apparaissent par morceaux, mobile en 4G pénible, alors que le TTFB est normal.

Comment le confirmer : dans PageSpeed, cherche les recommandations « Dimensionner correctement les images », « Diffuser des images aux formats nouvelle génération » et « Différer le chargement des images hors écran ». Puis F12, onglet Réseau, filtre « Img », tri par taille : toute image de contenu qui dépasse quelques centaines de kilooctets est suspecte, et une image de plusieurs mégaoctets est une erreur.

La correction tient en quatre gestes, dans cet ordre.

1. Redimensionner. Une image affichée sur huit cents pixels de large n’a aucune raison d’être uploadée en cinq mille. Redimensionne avant l’upload, ou laisse une extension d’optimisation le faire à l’envoi.
2. Convertir en WebP. Le WebP est le format d’image de Google, nettement plus compact qu’un JPEG ou un PNG à qualité visuelle égale. WordPress l’accepte nativement depuis la version 5.8 ; LiteSpeed Cache et plusieurs extensions gratuites du répertoire officiel convertissent toute la médiathèque en une passe.
3. Compresser. Une qualité autour de 75 à 82 est invisible à l’œil et divise le poids. Applique-la à toutes les images existantes, pas seulement aux nouvelles.
4. Charger en différé ce qui est hors écran. WordPress ajoute lui-même l’attribut loading="lazy" depuis la version 5.5, et marque l’image principale en priorité haute depuis la version 6.3. Le piège classique : une extension qui applique le chargement différé à l’image de couverture, celle qui compte pour le LCP. Elle doit se charger immédiatement, toutes les autres peuvent attendre.

Vérifie aussi les images de fond de sections (Elementor, Divi) et les sliders : ils ne bénéficient pas du chargement différé natif et embarquent souvent les fichiers les plus lourds du site. Une maison d’hôtes que j’ai reprise affichait sur sa page d’accueil une galerie livrée par le photographe en résolution d’impression, jamais redimensionnée : la seule correction des images a transformé l’expérience mobile, avant même de toucher au reste.

Gain attendu : le plus important de tout le guide sur le LCP mobile, dans la plupart des cas.

Étape 2 : trop d’extensions, des doublons, et celles qui chargent partout

Chaque extension active exécute du code PHP à chaque chargement de page, et beaucoup ajoutent leur CSS et leur JavaScript sur toutes les pages, même quand elles ne servent que sur une seule. Le problème n’est pas le nombre en soi, c’est ce que chacune coûte, et le fait que personne ne fait jamais le tri.

Symptôme : TTFB qui monte, administration lente, longue liste de fichiers /wp-content/plugins/… dans l’onglet Réseau, INP dégradé.

Comment le confirmer : va dans Extensions et compte ce qui est actif, inactif, et ce que tu ne reconnais pas. Installe Query Monitor, gratuit : sa barre affiche le temps de génération de la page et le détail par extension, requête par requête. Enfin, F12, onglet Réseau, filtre plugins/ : chaque dossier distinct est une extension qui charge quelque chose sur cette page. Les doublons sont toujours les mêmes : deux extensions SEO, deux de sécurité, deux de cache, trois de formulaires, un slider en plus de celui du constructeur.

La correction : supprime (pas seulement « désactive ») tout ce qui est inactif, retire les doublons, remplace les extensions à fonction unique (polices Google, icônes, boutons de partage) par la fonction équivalente du thème ou quelques lignes de code, et pour les extensions lourdes utiles sur une seule page (formulaire complexe, carte, galerie), utilise une extension de gestion des ressources qui empêche leurs fichiers de charger ailleurs. Fais-le sur une copie de test si tu en as une, et vérifie le site après chaque suppression. Si une extension casse l’affichage en partant, la méthode d’isolation décrite dans mon guide des 15 pannes WordPress les plus courantes te permettra de retrouver la coupable.

Un cabinet que j’ai audité tournait avec une quarantaine d’extensions, dont une douzaine désactivées depuis des mois mais toujours installées, et trois extensions de sliders pour un seul slider utilisé. Personne n’avait décidé cet empilement ; il s’était construit au fil de trois prestataires successifs.

Gain attendu : net sur le TTFB et sur l’exécution du JavaScript, avec en prime moins de conflits et moins de failles de sécurité.

Étape 3 : pas de cache de pages, ou un cache mal réglé

Sans cache, WordPress reconstruit chaque page à chaque visite : PHP s’exécute, la base de données est interrogée des dizaines de fois, le thème assemble le HTML. Le cache de pages enregistre le résultat final sous forme de fichier HTML statique et le sert tel quel au visiteur suivant, sans rien recalculer. C’est la correction qui change le plus le temps de réponse du serveur.

Symptôme : TTFB élevé sur toutes les pages, y compris la page d’accueil qui ne change jamais ; site correct avec peu de visiteurs mais qui s’effondre pendant une campagne publicitaire ou un envoi d’emailing.

Comment le confirmer : F12, onglet Réseau, clique sur le document HTML, onglet En-têtes, section « En-têtes de réponse ». Cherche x-litespeed-cache: hit, x-cache: HIT ou un en-tête équivalent selon ton hébergeur. Si tu ne vois rien, ou toujours miss après plusieurs rechargements, aucun cache ne sert la page. Autre test : compare le TTFB au premier chargement et au rechargement immédiat ; sans cache, ils sont identiques.

La correction : sur un hébergement LiteSpeed, ce qui est le cas d’Hostinger et de plusieurs hébergeurs marocains, installe LiteSpeed Cache, gratuit sur le répertoire officiel : active le cache dans le premier onglet et laisse toutes les options d’optimisation désactivées pour l’instant. Sur un serveur Apache ou Nginx classique, WP Super Cache ou W3 Total Cache en version gratuite font le travail. Si ton hébergeur fournit son propre cache serveur, utilise-le en priorité et n’ajoute pas de seconde couche par-dessus.

Trois règles pour ne pas te compliquer la vie : une seule extension de cache ; exclusion des pages de panier, de commande et de compte sur une boutique (les extensions sérieuses le font seules) ; vidage du cache après chaque publication ou modification de menu. Et un point de vigilance : un cache trop long sur une page contenant un formulaire peut servir un jeton de sécurité expiré, ce qui provoque les envois qui échouent décrits dans mon guide sur le formulaire WordPress qui n’envoie pas les messages.

Le cache masque un site lent, il ne le répare pas : les visiteurs connectés, la première visite après un vidage, la recherche interne et le panier restent lents tant que les autres étapes ne sont pas faites. Continue donc le diagnostic après l’avoir activé.

Gain attendu : le plus important de tout le guide sur le TTFB.

Étape 4 : un constructeur de pages ou un thème trop lourd

Elementor, Divi, WPBakery et les thèmes « multi-usages » chargent leurs propres dizaines de fichiers CSS et JavaScript, produisent une structure de page profonde (sections dans des colonnes dans des conteneurs dans des widgets), et sont livrés avec des animations, des effets de parallaxe, des polices Google et des icônes activées par défaut. Le constructeur n’est pas le problème en soi ; c’est la manière dont on s’en sert.

Symptôme : PageSpeed signale « Éviter une taille excessive du DOM », « Réduire le JavaScript inutilisé » et « Réduire le CSS inutilisé » ; INP dégradé ; page lourde même après optimisation des images ; CLS provoqué par les animations d’entrée.

Comment le confirmer : F12, onglet Réseau, filtre themes/ puis elementor (ou le nom de ton constructeur), et compte les fichiers et leur poids. Dans PageSpeed, ouvre l’arborescence des ressources sous « Réduire le JavaScript inutilisé » : elle nomme les fichiers les plus lourds et la part réellement utilisée.

La correction, du moins coûteux au plus ambitieux :

1. Active les options de performance du constructeur. Dans Elementor, le menu Réglages contient les fonctionnalités de chargement amélioré du CSS et des ressources, la sortie DOM optimisée, et la possibilité de désactiver le chargement des polices Google et des icônes inutilisées. Ces options existent, elles sont rarement cochées.
2. Simplifie les pages. Supprime les animations d’entrée, les parallaxes, les vidéos de fond et les sliders de la page d’accueil. Une image de couverture fixe se charge plus vite et convertit aussi bien qu’un slider que personne ne fait défiler.
3. Désactive les modules du thème que tu n’utilises pas. Un thème multi-usages charge ses styles de portfolio, de méga-menu et de boutique même sur un site qui n’a rien de tout cela ; ses réglages permettent en général de les couper.
4. Pour une refonte, pars sur un thème léger (les thèmes minimalistes conçus pour les constructeurs ou pour l’éditeur de blocs) plutôt que sur un kit de démonstration importé en entier, avec ses cinquante pages et ses plugins imposés. C’est l’un des points que je détaille dans les erreurs à éviter quand on crée un site WordPress.

Une boutique que j’ai reprise avait une page d’accueil dont trois sections successives lisaient chacune une vidéo en arrière-plan. Sur mobile, les vidéos n’étaient même pas visibles, mais elles étaient téléchargées quand même. Les remplacer par des images fixes a fait plus pour la vitesse que tout le reste de l’intervention.

Gain attendu : sensible sur l’exécution du JavaScript, l’INP et l’expérience mobile.

Étape 5 : un hébergement sous-dimensionné, PHP obsolète, serveur trop loin

Si le TTFB reste élevé après l’activation du cache, ou si le site ralentit à certaines heures, c’est l’hébergement qui plafonne. Il y a quatre sous-causes : un mutualisé saturé par ses voisins, une version de PHP obsolète, un serveur sans cache intégré, et une localisation trop éloignée de tes visiteurs. Je place cette étape en cinquième position parce que les quatre précédentes sont gratuites et règlent souvent le problème sans changer d’hébergeur ; mais un site qui atteint régulièrement ses limites de ressources ne sera jamais rapide, quelles que soient ses images.

Symptôme : TTFB variable selon l’heure de la journée, administration lente, erreurs 503 ou messages du type « Resource Limit Is Reached », lenteur qui coïncide avec les pics de trafic.

Comment le confirmer : dans hPanel ou cPanel, ouvre le graphique d’utilisation des ressources (CPU, mémoire, processus) et regarde s’il touche le plafond. Dans WordPress, Outils → Santé du site affiche la version de PHP et signale si elle est dépassée ; les prérequis publiés par WordPress.org indiquent la version recommandée. Pour la distance, demande à ton hébergeur où se trouve physiquement le serveur, puis teste le TTFB d’un fichier statique (par exemple /wp-includes/js/jquery/jquery.min.js) : s’il est lent aussi, le réseau ou le serveur est en cause ; si seule la page est lente, c’est PHP et la base de données.

La correction : passe à une version récente de PHP 8 depuis le panneau de l’hébergeur, après sauvegarde et test des extensions (chaque version majeure de PHP apporte un gain net sur un site WordPress). Vérifie qu’OPcache est actif, c’est le cas presque partout. Si les ressources plafonnent, monte de gamme : un mutualisé LiteSpeed avec disques NVMe suffit à un site vitrine, une boutique demande un mutualisé premium ou un petit VPS. Pour la localisation, un serveur situé au Maroc, en France, en Espagne ou au Portugal répond rapidement à un visiteur de Casablanca ou de Marrakech ; un datacenter nord-américain ou asiatique impose un délai supplémentaire sur chacune des requêtes. Ma comparaison des hébergements web disponibles au Maroc passe en revue les offres, les datacenters et les prix de renouvellement pour t’aider à choisir.

Si tu es arrivé à cette étape, que le site est en production et que tu envisages une migration d’hébergeur ou un changement de version de PHP, ne te lance pas seul un vendredi soir. Une migration ratée transforme un site lent en site absent. Ma prestation de dépannage WordPress démarre toujours par un diagnostic offert, et l’accélération d’un site vitrine tient en général en une seule intervention, sauvegarde et tests compris.

Gain attendu : décisif quand le serveur est réellement la cause, nul sinon. D’où l’intérêt d’avoir mesuré le TTFB avant.

Étape 6 : les scripts tiers, du chat aux vidéos intégrées

Chaque script externe (widget de chat WhatsApp, pixel Facebook, Google Tag Manager, polices Google, vidéo YouTube intégrée, carte Google Maps, flux Instagram, widget d’avis) vient d’un autre serveur que tu ne contrôles pas, et il se charge souvent avant ton propre contenu. Pris un par un, ils sont anodins ; ensemble, ils peuvent peser plus lourd que tout le site.

Symptôme : PageSpeed signale « Réduire l’impact du code tiers » et « Éliminer les ressources qui bloquent le rendu » ; INP dégradé ; site lent malgré le cache ; onglet Réseau qui montre des dizaines de domaines différents.

Comment le confirmer : dans PageSpeed, la section « Code tiers » liste chaque domaine externe et le temps pendant lequel il bloque la page. Dans F12, onglet Réseau, le filtre « Tiers » (ou un tri par domaine) montre la même chose avec le poids de chaque fichier.

La correction commence par un inventaire honnête : ce qui sert vraiment reste, le reste part. Le widget de chat auquel personne ne répond, le second outil de statistiques, le pixel d’une campagne terminée depuis un an. Puis, pour ce qui reste :

• Chat et pixels : charge-les après le premier défilement ou la première interaction, via les déclencheurs de Tag Manager ou l’option de chargement différé de ton extension de cache.
• Polices Google : héberge-les sur ton serveur (option native d’Elementor et de la plupart des thèmes récents), limite-toi à deux familles, et n’embarque que les sous-ensembles latin et arabe si tu utilises les deux. Les polices système sont l’option la plus rapide.
• Vidéos YouTube : remplace le lecteur intégré par une façade, c’est-à-dire une image de couverture avec un bouton « lecture » qui ne charge le lecteur qu’au clic. LiteSpeed Cache et d’autres extensions le font automatiquement pour les iframes.
• Google Maps : une image de la carte avec un lien vers l’itinéraire dans Maps fait le même travail qu’une carte interactive, sans son poids.
• Flux Instagram et widgets d’avis : mets-les en cache côté serveur, ou remplace-les par des captures d’écran mises à jour à la main.

Gain attendu : important sur l’INP et sur le mobile, où chaque script se paie en temps de processeur et en données.

Étape 7 : une base de données encombrée

WordPress conserve chaque révision d’article, chaque brouillon automatique, chaque commentaire indésirable, des données temporaires que les extensions oublient de nettoyer, et les tables d’extensions que tu as supprimées depuis longtemps. Individuellement, rien de grave. Mais une table wp_options gonflée d’options chargées automatiquement ralentit chaque requête, y compris celles qui ne sont pas servies par le cache.

Deux définitions utiles. Les révisions sont les copies de chaque version enregistrée d’un article ou d’une page ; sans limite, une page modifiée cent fois occupe cent lignes. Les transients sont des données temporaires mises en cache par les extensions avec une date d’expiration, que WordPress ne purge pas systématiquement.

Symptôme : TTFB élevé sur les pages non mises en cache (administration, recherche, visiteurs connectés, panier) alors que les pages en cache sont rapides ; taille de la base disproportionnée par rapport au contenu du site.

Comment le confirmer : Query Monitor, onglet Requêtes, liste les requêtes lentes et l’extension qui les déclenche. Dans phpMyAdmin, trie les tables par taille : une table wp_options ou wp_postmeta qui pèse plus lourd que wp_posts est un signal. Depuis WordPress 6.6, Outils → Santé du site signale aussi les options en chargement automatique trop volumineuses.

La correction, toujours après une sauvegarde complète de la base : nettoie révisions, brouillons automatiques, commentaires indésirables et transients expirés avec l’onglet Base de données de LiteSpeed Cache ou une extension dédiée gratuite, puis optimise les tables. Limite les révisions futures avec define('WP_POST_REVISIONS', 5); dans wp-config.php. Supprime les tables des extensions désinstallées uniquement si tu les identifies avec certitude ; sinon, laisse-les. Sur une boutique, surveille en plus les tables de sessions et de journaux du planificateur d’actions de WooCommerce, qui grossissent vite.

Gain attendu : modeste sur les pages en cache, réel sur l’administration, les boutiques et tout ce qui est calculé à la volée.

Étape 8 : CSS et JavaScript non minifiés, non différés, polices lourdes

Une fois le superflu retiré, ce qui reste peut être servi plus intelligemment : fichiers minifiés, JavaScript différé après l’affichage, CSS critique injecté dans la page, polices préchargées avec un affichage de secours. Je place ce réglage en huitième position volontairement : minifier quarante fichiers qui ne devraient pas exister n’apporte rien, alors que minifier les dix qui restent après les étapes précédentes se voit.

Symptôme : PageSpeed signale « Éliminer les ressources qui bloquent le rendu », « Réduire le CSS inutilisé », « Réduire le JavaScript inutilisé » et « Afficher le texte pendant le chargement des polices web » ; premier affichage tardif alors que le TTFB est bon ; texte qui clignote ou change de police au chargement.

Comment le confirmer : dans F12, onglet Réseau, filtres CSS puis JS : regarde le poids de chaque fichier et s’il est chargé dans l’en-tête de la page, donc avant tout affichage. PageSpeed te dit lesquels bloquent le rendu.

La correction se fait dans l’onglet d’optimisation de ton extension de cache (LiteSpeed Cache, ou une extension gratuite dédiée sur un autre serveur), une option à la fois, avec un test complet entre chaque : minification du CSS, minification du JavaScript, report du JavaScript, génération du CSS critique, font-display: swap et préchargement des polices, préconnexion aux domaines externes conservés. Évite la combinaison des fichiers : sur un serveur HTTP/2, elle n’apporte plus rien et casse souvent des scripts. Si une option casse le menu, le slider, le formulaire ou le panier, exclus le fichier concerné plutôt que de désactiver toute l’option, et note l’exclusion quelque part.

C’est l’étape où les gens cassent leur site, parce qu’ils cochent tout d’un coup. Fais-le lentement.

Gain attendu : visible sur la vitesse perçue (premier affichage), le LCP et le CLS lié aux polices.

Étape 9 : redirections en chaîne, HTTPS et requêtes externes inutiles

Chaque redirection ajoute un aller-retour complet vers le serveur avant que la page ne commence à charger. Le cas typique : http vers https, puis vers la version avec www, puis vers la version avec barre oblique finale, soit trois redirections avant le premier octet. Ajoute des liens internes qui pointent encore vers d’anciennes adresses, un contenu mixte (fichiers appelés en http sur une page https) et des requêtes vers des domaines morts laissés par une extension supprimée.

Symptôme : PageSpeed signale « Éviter les redirections multiples vers la page » ; erreurs 404 ou ressources bloquées dans la console ; mention « Non sécurisé » dans le navigateur ; lenteur au tout début du chargement surtout sur mobile, où chaque aller-retour coûte.

Comment le confirmer : F12, onglet Réseau, coche « Conserver le journal », puis tape ton domaine sans https et sans www : compte les lignes en statut 301 ou 302 avant le document final. Vérifie ensuite que les deux adresses de Réglages → Général sont identiques et en https, et que les liens du menu ne pointent pas vers l’ancienne version.

La correction : une seule règle de redirection, au niveau du serveur (le réglage « Forcer HTTPS » de ton hébergeur, ou une règle unique dans .htaccess) vers la version canonique du site. Désactive les extensions de redirection devenues inutiles, et n’empile pas une règle Cloudflare par-dessus une règle serveur par-dessus une extension : c’est ainsi que naissent les boucles de redirection. Corrige les liens internes avec une recherche-remplacement en base, et supprime dans la console chaque requête vers un fichier ou un domaine qui n’existe plus.

Gain attendu : petit en valeur absolue, mais gratuit, et il se ressent sur mobile depuis le Maroc quand le serveur est en Europe.

Étape 10 : le cas rare, un site piraté qui mine ou envoie du spam

C’est la cause la moins probable, mais la plus urgente quand elle est réelle. Un site compromis consomme ses ressources à expédier du spam, à miner de la cryptomonnaie ou à lancer des attaques contre d’autres serveurs, et la lenteur en est le premier symptôme visible. Le signe distinctif est la brutalité : le site était normal hier, il est très lent aujourd’hui, et tu n’as rien changé.

Symptôme : lenteur soudaine et inexpliquée, alerte de surconsommation de la part de l’hébergeur, graphique CPU au plafond en permanence, fichiers modifiés à une date à laquelle tu n’as pas touché au site, tâches planifiées inconnues, pages étrangères qui apparaissent dans les résultats Google pour ton domaine.

Comment le confirmer : dans le panneau de l’hébergeur, regarde le graphique d’utilisation des ressources sur sept jours et repère la rupture. Trie les fichiers du site par date de modification. Lance un scan avec une extension de sécurité. Tape site:tondomaine.ma dans Google et regarde s’il y a des pages que tu n’as jamais créées.

La correction : n’optimise pas un site piraté, nettoie-le d’abord. Suis le plan heure par heure de mon guide sur le site WordPress piraté et ce qu’il faut faire, mets le site en sécurité, puis reviens aux étapes 1 à 9 une fois le nettoyage confirmé. Optimiser des images sur un site qui envoie du spam, c’est repeindre une maison dont la porte est ouverte.

Gain attendu : le site retrouve d’un coup sa vitesse antérieure, parce qu’il ne s’agissait pas de lenteur mais d’occupation.

Site WordPress lent : le tableau récapitulatif (symptôme, cause probable, outil, correction)

Ce tableau condense les dix étapes. Pars de ce que tu observes, il te donne la ligne à ouvrir.

Symptôme observé	Cause probable	Outil de vérification	Correction
LCP élevé, page lourde, TTFB normal	Images non optimisées (étape 1)	PageSpeed « Dimensionner les images », F12 Réseau filtre Img	Redimensionner, WebP, compresser, chargement différé sauf image principale
Administration lente, dizaines de fichiers plugins/	Trop d’extensions, doublons (étape 2)	Query Monitor, F12 Réseau filtre plugins/	Supprimer l’inactif et les doublons, limiter le chargement par page
TTFB élevé partout, effondrement en pic de trafic	Pas de cache de pages (étape 3)	En-têtes de réponse (x-litespeed-cache, x-cache)	LiteSpeed Cache ou équivalent, une seule extension
DOM excessif, JavaScript inutilisé, INP dégradé	Constructeur ou thème lourd (étape 4)	PageSpeed arborescence des ressources, F12 filtre themes/	Options de performance, pages simplifiées, modules désactivés
TTFB variable selon l’heure, erreurs 503	Hébergement saturé, PHP obsolète, serveur lointain (étape 5)	Graphique de ressources hPanel/cPanel, Santé du site	PHP récent, montée de gamme, serveur proche, CDN
Beaucoup de domaines externes, INP dégradé	Scripts tiers (étape 6)	PageSpeed section « Code tiers »	Inventaire, chargement différé, façades vidéo, polices locales
Pages non cachées lentes, base volumineuse	Base de données encombrée (étape 7)	Query Monitor onglet Requêtes, phpMyAdmin, Santé du site	Nettoyage révisions et transients, limite des révisions
Ressources bloquant le rendu, police qui change	CSS/JS non optimisés (étape 8)	PageSpeed, F12 filtres CSS et JS	Minification, report du JS, CSS critique, font-display
Plusieurs 301 avant la page, « Non sécurisé »	Redirections en chaîne, contenu mixte (étape 9)	F12 Réseau avec journal conservé	Une seule règle de redirection, liens internes corrigés
Lenteur brutale sans changement, CPU au plafond	Site piraté (étape 10)	Graphique de ressources, fichiers récents, site: dans Google	Nettoyage complet avant toute optimisation

Ce qu’il ne faut pas faire, et comment garder un site WordPress rapide

La plupart des sites lents que je reprends ont été ralentis par des tentatives d’accélération. La vitesse se gagne en retirant, presque jamais en ajoutant. Voici les erreurs qui reviennent, puis la routine qui évite de retomber dans la lenteur six mois plus tard.

Les quatre erreurs qui aggravent la lenteur

• Empiler plusieurs extensions d’optimisation. Deux caches, une extension de minification et une autre d’images qui travaillent sur les mêmes fichiers produisent des doubles traitements, des conflits et des pages cassées. Une extension de cache, une seule, qui fait aussi l’optimisation si elle le propose.
• Activer toutes les options d’un cache d’un coup. Le site casse, tu désactives tout, et tu conclus que « le cache ne marche pas sur mon site ». Une option à la fois, un test après chacune.
• Supprimer des fichiers à la main par FTP « pour alléger ». Un thème, une extension ou un dossier d’uploads effacé ne rend pas le site plus rapide, il le rend cassé. Tout passe par l’interface de WordPress, après sauvegarde.
• Acheter un « pack vitesse » ou une « garantie score 100 ». Un score de laboratoire se manipule ; un site qui affiche 100 sur ordinateur avec des données réelles rouges sur mobile n’a rien gagné commercialement. Ce que tu veux, ce sont des visiteurs qui restent, pas un chiffre vert.

Après optimisation : maintenir la vitesse

• Fixe un budget de poids par page et tiens-t’y : un plafond pour la page d’accueil, un plafond par image, et toute nouvelle image passe par le redimensionnement avant l’upload. Forme la personne qui publie, c’est elle qui décide de la vitesse au quotidien.
• Teste après chaque nouvelle extension. PageSpeed avant, PageSpeed après. Si elle coûte plus qu’elle ne rapporte, elle part.
• Fais une revue trimestrielle : liste des extensions, nettoyage de la base, version de PHP, rapport Signaux Web essentiels dans la Search Console, test mobile en 4G.
• Mets à jour sur une copie de test avant la production, surtout le constructeur de pages et l’extension de cache, dont les mises à jour majeures changent parfois le comportement des options.

Cas particuliers : WooCommerce et les visiteurs hors du Maroc

Les dix étapes s’appliquent à tous les sites WordPress, mais deux situations ajoutent leurs propres règles.

WooCommerce et boutiques en ligne

Une boutique a une contrainte que n’a pas un site vitrine : les pages de panier, de commande et de compte client ne peuvent pas être mises en cache, parce qu’elles dépendent de la session de chaque visiteur. Pour ces pages, le cache de l’étape 3 ne sert à rien, et c’est la vitesse brute du serveur (étapes 5 et 7) qui compte : PHP récent, base de données propre, et un cache objet (Redis ou équivalent, proposé par plusieurs hébergeurs) qui garde en mémoire les résultats des requêtes répétées.

Trois points spécifiques ensuite. WooCommerce déclenche sur chaque page une requête de rafraîchissement du mini-panier, même sur les pages sans produit ; la désactiver hors boutique allège tout le site. Les tables de sessions et de journaux du planificateur d’actions grossissent sans limite si personne ne les nettoie. Enfin, les images de catalogue doivent être régénérées aux bonnes dimensions après tout changement de thème, sinon les vignettes affichent des images de fiche produit en pleine taille. Si tu es au stade du choix d’outil, mon guide pour lancer une boutique en ligne au Maroc traite la question de l’hébergement dès la conception.

Et depuis la France, la Belgique, la Suisse ou le Canada ?

Un site hébergé au Maroc et visité depuis Paris, Bruxelles, Genève ou Montréal subit une latence à chaque requête ; un site hébergé en Europe et visité depuis le Maroc, le cas le plus fréquent, subit la même chose en sens inverse. Dans les deux cas, la solution est un CDN (Content Delivery Network : un réseau de serveurs répartis dans le monde, qui conserve une copie de tes fichiers au plus près de chaque visiteur) : les images, le CSS et le JavaScript sont servis depuis un point proche du visiteur, et certains CDN mettent aussi en cache le HTML complet des pages, ce qui supprime l’aller-retour vers ton serveur d’origine.

La règle est simple : héberge près de la majorité de ton audience, et couvre le reste avec un CDN. Le Canada est loin de tout serveur marocain ou européen ; si cette audience compte pour toi, le CDN n’est plus optionnel. Ne multiplie pas les hébergements par pays, cela ne se fait pas et ne sert à rien. Pour tester depuis ces pays, demande à un contact sur place de faire le test PageSpeed sur son téléphone, ou utilise un VPN pour simuler sa position. Le volet référencement de cette question, c’est-à-dire comment Google situe ton site, est traité dans mon guide sur la manière de référencer un site marocain sur Google.

Ce que tu dois faire maintenant

Mesure ton site sur mobile avec PageSpeed Insights et note tes valeurs de départ, en particulier le TTFB : il te dit si tu dois commencer par le serveur ou par l’affichage. Fais ensuite les étapes 1 à 3 dans l’ordre, elles sont gratuites et règlent l’essentiel dans la plupart des cas. Re-mesure, puis attaque les étapes 4 à 9 une par une, avec un test après chaque changement, et garde l’étape 10 pour la lenteur brutale et inexpliquée.

Si tu veux déléguer, ou si ton site fait fuir des visiteurs en ce moment même, envoie-moi l’adresse du site et ce que tu observes depuis la page pour contacter un développeur WordPress freelance à Marrakech. Le diagnostic est offert, et je te dis avant toute intervention quelles étapes s’appliquent à ton cas.