Site internet lent : diagnostic, causes et correctifs

Un site internet lent souffre presque toujours d’une ou deux causes dominantes : images trop lourdes, serveur qui répond tard, thème chargé d’extensions, scripts tiers ou cache absent. Mesurez d’abord avec PageSpeed Insights et la Search Console, repérez la métrique en défaut, puis corrigez la cause qui pèse le plus avant de toucher au reste.

Mesurer la lenteur avant de la corriger

La sensation de lenteur trompe souvent : votre navigateur garde en mémoire les fichiers déjà téléchargés, et la page qui s’affiche vite sur votre poste traîne chez le visiteur qui la découvre sur un smartphone. Seule une mesure extérieure tranche.

Deux outils gratuits de Google se complètent : le premier teste une adresse à la demande, le second suit le temps de chargement de tout le site au fil des semaines.

PageSpeed Insights : terrain et laboratoire

Pour une page donnée, PageSpeed Insights affiche deux blocs à lire différemment, plus un score :

• Les données de terrain proviennent du rapport d’expérience utilisateur de Chrome (CrUX) et résument ce qu’ont vécu de vrais visiteurs sur les 28 jours précédents.
• Les données de laboratoire proviennent de Lighthouse : une simulation contrôlée sur un mobile de milieu de gamme, utile pour déboguer et tester une correction.
• Le score de performance sur 100 résume cette simulation : vert de 90 à 100, orange de 50 à 89, rouge en dessous de 50.

Une page peu visitée manque souvent de données de terrain : PageSpeed Insights affiche alors les valeurs du site entier, ou rien si le trafic global reste trop faible, cas fréquent sur un site vitrine de PME. Le laboratoire devient votre seul repère : répétez le test plusieurs fois, deux passages donnent rarement le même score.

Le rapport Core Web Vitals de la Search Console

Une fois votre propriété validée dans la Search Console, le rapport Core Web Vitals classe vos URL en trois statuts, Bon, Amélioration nécessaire et Médiocre, séparément sur mobile et sur ordinateur. Il regroupe les pages semblables, fiches de prestation ou articles : un groupe entier en orange désigne presque toujours un gabarit, pas une page isolée.

Seules les URL qui ont réuni assez de données réelles y figurent. Après une correction, le bouton de validation ouvre une période de surveillance de 28 jours : prévoyez un mois avant de crier victoire.

LCP, INP, CLS : les seuils des Signaux Web essentiels

Les Core Web Vitals, traduits Signaux Web essentiels dans la documentation française de Google, réduisent l’expérience d’une page à trois mesures. Google Search Central publie le seuil de chacune, et le site web.dev de Google détaille les paliers :

• LCP (Largest Contentful Paint) : le délai d’affichage du plus grand élément visible, souvent l’image principale ou le titre. Bon jusqu’à 2,5 secondes, médiocre au-delà de 4 secondes.
• INP (Interaction to Next Paint) : la réactivité de la page quand le visiteur clique, touche l’écran ou tape au clavier. Bon jusqu’à 200 millisecondes, médiocre au-delà de 500.
• CLS (Cumulative Layout Shift) : la stabilité visuelle, autrement dit les décalages de contenu pendant le chargement. Bon jusqu’à 0,1, médiocre au-delà de 0,25.

Ces valeurs ne se jugent pas sur une visite isolée. Selon web.dev, une page atteint le seuil quand 75 % de ses chargements, comptés séparément sur mobile et sur ordinateur, restent sous la barre. Une page rapide pour la plupart des visites mais lente pour plus d’un chargement sur quatre reste donc en défaut. L’INP a remplacé l’ancien indicateur FID en 2024 : un audit qui cite encore le FID est antérieur à ce changement.

Google les présente comme un signal parmi d’autres : le contenu le plus pertinent passe en premier, et une bonne expérience aide à départager des pages de valeur comparable. La vitesse prolonge donc le travail décrit dans le guide du référencement naturel pour débutants, sans le remplacer.

Quelle métrique en défaut, quelle piste suivre

Partez de la métrique en rouge plutôt que d’une liste d’astuces générales : chaque indicateur oriente vers une famille de causes.

Un LCP trop long

Le site web.dev découpe le LCP en quatre temps : la réponse du serveur (le TTFB, délai avant le premier octet), le délai avant que la ressource principale commence à charger, la durée de ce chargement, puis le délai d’affichage. Un serveur lent plombe tout le reste : aucune optimisation de la page ne rattrape une réponse tardive. Pour le TTFB, web.dev retient 0,8 seconde comme repère approximatif, sans en faire un Signal Web essentiel.

Un INP élevé

Une mauvaise réactivité vient le plus souvent du JavaScript. Des scripts lourds occupent le processeur du téléphone, et la page tarde à répondre au toucher. Les suspects habituels : carrousels animés, outils de suivi, modules de prise de rendez-vous, constructeurs de pages qui injectent leur code sur chaque écran. Autre point : l’INP exige de vraies interactions. Le laboratoire ne le calcule pas, seules les données de terrain font foi.

Un CLS dégradé

Le contenu qui saute pendant le chargement provient presque toujours de trois sources : des images ou des vidéos sans dimensions déclarées, un bandeau inséré au-dessus du texte une fois la page affichée, une police web qui remplace la police de secours avec un gabarit différent. Réservez l’espace de chaque élément dès le départ, et la plupart des décalages disparaissent.

Site internet lent : six causes et leurs remèdes

D’un audit à l’autre, la vitesse d’un site se joue presque toujours sur ces six terrains.

Des images trop lourdes

Première cause sur les sites vitrines : la photo sortie de l’appareil, en pleine résolution, affichée dans un cadre de quelques centimètres. Le visiteur télécharge des pixels qu’il ne verra jamais. Les remèdes, par ordre de rendement :

• Redimensionnez chaque visuel à sa taille d’affichage réelle et proposez plusieurs tailles avec l’attribut srcset, détaillé dans l’article sur le design responsive.
• Convertissez en WebP ou AVIF, les formats modernes que recommande web.dev.
• Chargez en différé les images placées plus bas dans la page, jamais l’image principale.
• Signalez cette image principale au navigateur avec l’attribut fetchpriority="high".

Un hébergement sous-dimensionné

Une offre mutualisée d’entrée de gamme partage processeur et mémoire entre de nombreux sites. Rien ne se voit tant que le trafic reste modeste ; quand un voisin consomme trop ou que votre catalogue grossit, le temps de réponse s’allonge. Le symptôme se lit dans PageSpeed Insights : un délai de réponse du serveur élevé, même sur une page légère. Avant de déménager, vérifiez la version de PHP et la localisation des serveurs, puis comparez les formules décrites dans l’article sur le choix du nom de domaine et de l’hébergement.

Un thème et des extensions trop gourmands

Sur WordPress, chaque extension activée peut charger ses feuilles de style et ses scripts sur toutes les pages, y compris celles où elle ne sert à rien. Un thème polyvalent bourré de modules alourdit chaque écran de la même manière. Faites l’inventaire sur une copie du site : désactivez les extensions une à une et mesurez après chaque retrait. Celles qui ne servent plus partent, celles qui font double emploi sont fusionnées. Les critères de choix d’un thème léger figurent dans le parcours pour apprendre WordPress.

Des scripts tiers en cascade

Mesure d’audience, pixels publicitaires, vidéos intégrées, cartes interactives, bandeau de consentement : chaque service externe ajoute des requêtes vers des serveurs que vous ne maîtrisez pas. Ouvrez l’onglet Réseau des outils de développement de Chrome pour les lister. Supprimez ceux qui ne servent plus, différez le chargement des autres, et remplacez une vidéo ou une carte intégrée par une simple image cliquable qui appelle le lecteur à la demande.

Aucun cache en place

Sans cache, le serveur recalcule chaque page à chaque visite et le navigateur retélécharge des fichiers qui n’ont pas changé. Deux niveaux se complètent :

• Le cache de page côté serveur, qui stocke la version HTML déjà calculée, par une extension sur WordPress ou un réglage proposé par l’hébergeur.
• Le cache navigateur, piloté par l’en-tête Cache-Control. La documentation Lighthouse de Chrome recommande une durée d’un an pour les fichiers statiques qui ne changent jamais, avec une empreinte dans leur nom pour forcer la mise à jour.

Un réseau de diffusion de contenu (CDN) ajoute un troisième étage en servant les fichiers depuis un point proche du visiteur.

Une base de données encombrée

Un site dynamique interroge sa base de données à chaque affichage. Avec les années, elle accumule des révisions d’articles, des commentaires indésirables, des données temporaires et des tables laissées par des extensions supprimées. Un nettoyage, précédé d’une sauvegarde complète, allège les requêtes.

Accélérer un site web : l’ordre des corrections

Tout corriger en une soirée paraît tentant, mais vous ne sauriez plus ce qui a fonctionné. Pour accélérer un site sans rien casser, avancez par étapes et mesurez après chacune :

1. Relevez l’état initial : PageSpeed Insights sur l’accueil et deux ou trois pages clés, mobile en priorité, plus une capture du rapport de la Search Console.
2. Traitez les images, chantier rapide et souvent le plus rentable.
3. Activez ou réglez le cache, puis contrôlez le délai de réponse du serveur.
4. Faites le tri dans les extensions et les scripts tiers.
5. Nettoyez la base de données.
6. Seulement ensuite, envisagez un changement d’hébergement ou de thème.

Testez chaque modification sur une copie quand c’est possible : une extension d’optimisation trop agressive casse parfois un menu ou un formulaire. Tenez aussi un journal daté des changements : il reliera ensuite chaque progrès visible dans la Search Console à l’action qui l’a produit.

Quand la refonte devient plus raisonnable que l’optimisation

Parfois, la lenteur tient à l’architecture elle-même. Quelques signaux ne trompent pas :

• Le thème n’est plus mis à jour par son éditeur et bloque la montée de version du CMS.
• Un constructeur de pages génère un code si lourd que chaque gain disparaît à la mise à jour suivante.
• Le site repose sur une technologie que plus aucun prestataire ne veut maintenir.
• Les corrections successives coûtent, cumulées, plus cher qu’une reconstruction propre.

Dans ces cas, un site lent appelle une refonte technique centrée sur la performance, avec un gabarit léger. Les signaux d’alerte et la méthode sont développés dans l’article refonte de site web : quand et comment. Retenez une règle : inscrivez des objectifs de LCP, d’INP et de CLS dans le cahier des charges, à vérifier sur la préproduction avant la mise en ligne.

Garder un site rapide dans la durée

La lenteur revient en silence : une nouvelle extension, une galerie ajoutée sans compression, un outil marketing installé pour une campagne puis oublié. Trois réflexes tiennent la vitesse du site sous contrôle :

• Consultez le rapport Core Web Vitals de la Search Console une fois par mois.
• Relancez PageSpeed Insights après chaque ajout de fonctionnalité.
• Compressez chaque image avant de la téléverser.

Un site internet lent se soigne rarement en une fois, mais il se diagnostique en quelques minutes. Prochaine étape : passez dès aujourd’hui votre page d’accueil dans PageSpeed Insights en version mobile, notez les trois mesures et le délai de réponse du serveur, puis attaquez la cause liée à la métrique la plus éloignée de son seuil.