Pourquoi mon site web est-il lent ? Trouver la cause et la corriger

« Mon site est lent » peut décrire plusieurs problèmes bien distincts. Le serveur met peut-être longtemps à envoyer le premier octet. La page arrive peut-être vite mais met une éternité à afficher son image principale. Elle a peut-être l'air prête tout en ignorant les taps pendant une seconde. Ou bien elle se charge, puis saute à mesure que les publicités et les images repoussent le texte vers le bas. Chacun de ces cas a ses propres causes : la première tâche consiste donc à déterminer lequel est le vôtre.

Mesurez avant de modifier quoi que ce soit

Il existe deux types de données de vitesse, qui ne répondent pas aux mêmes questions :

• Les données de terrain proviennent de vrais visiteurs, sur leurs propres appareils et connexions. Le Chrome UX Report de Google les collecte pour les sites au trafic suffisant, et vous les retrouvez dans PageSpeed Insights et dans le rapport Core Web Vitals de Google Search Console. Elles vous disent ce que les internautes vivent réellement.
• Les données de laboratoire proviennent d'un chargement unique de la page en conditions contrôlées, comme le fait Lighthouse. Elles sont moins représentatives, mais reproductibles, et elles expliquent pourquoi une page est lente.

Selon les Core Web Vitals de Google, une bonne expérience correspond à un Largest Contentful Paint (LCP) de 2,5 secondes ou moins, à un Interaction to Next Paint (INP) de 200 millisecondes ou moins et à un Cumulative Layout Shift (CLS) de 0,1 ou moins, mesurés au 75e centile des visites réelles.

Pour le diagnostic, lancez un test de laboratoire. L'outil gratuit de test de vitesse de Rudra charge votre page avec Lighthouse et indique le First Contentful Paint, le LCP, le Total Blocking Time, le CLS, le Speed Index et le Time to Interactive, ainsi que les audits Lighthouse en échec, du plus grave au moins grave. Gardez ses limites à l'esprit : il s'agit d'un chargement unique depuis notre serveur, dans les conditions simulées de Lighthouse ; les chiffres ne coïncideront donc pas exactement avec vos données de terrain, et l'outil ne peut pas mesurer l'INP, qui suppose de vraies interactions. Le Total Blocking Time est le signal de laboratoire le plus étroitement lié à la réactivité.

Testez quelques types de pages représentatifs (page d'accueil, page produit ou service, article), lancez chaque test plusieurs fois, et regardez les résultats mobiles, pas seulement ceux sur ordinateur.

Les causes les plus fréquentes, et comment y remédier

1. Un serveur lent à répondre

Rien d'autre ne peut commencer tant que le serveur n'a pas envoyé le HTML. Si le Time to First Byte est élevé, la cause est en général un hébergement bas de gamme ou surchargé, des pages reconstruites de zéro à chaque requête, des requêtes de base de données lentes ou des visiteurs éloignés du serveur. Les remèdes : activez le cache de pages (la plupart des CMS proposent une extension ou un réglage de cache), placez un CDN devant le site, supprimez les extensions inutiles et passez à un hébergement supérieur si le serveur manque tout simplement de puissance. Les recommandations de Google considèrent comme bon un TTFB de 0,8 seconde ou moins. Lors des crawls de site complets, Rudra signale les pages dont le serveur a mis plus de 1,5 seconde à répondre, et classe comme critiques celles qui dépassent 3 secondes.

2. Des images surdimensionnées

Une photo exportée directement d'un appareil photo ou d'un téléphone peut peser plusieurs mégaoctets et mesurer des milliers de pixels de large, pour être affichée en 800 pixels. Redimensionnez, compressez et adoptez des formats modernes. Notre guide comment réduire le poids des images détaille la démarche étape par étape.

3. Trop de JavaScript

Les gros bundles et les balises tierces (mesure d'audience, widgets de chat, tests A/B, scripts publicitaires) se disputent le thread principal du navigateur. Tant qu'un long script s'exécute, la page ne peut pas réagir aux taps, ce qui se traduit par un Total Blocking Time élevé en laboratoire et un mauvais INP sur le terrain. Passez en revue chaque balise tierce et supprimez celles dont personne ne se sert, chargez les widgets non essentiels une fois la page interactive ou lorsque le visiteur les demande, et découpez les gros bundles pour que chaque page ne charge que ce dont elle a besoin.

4. Des CSS et des scripts qui bloquent le rendu

Les scripts placés dans le <head> sans async ni defer, de même que chaque feuille de style, doivent être chargés avant que le navigateur puisse afficher quoi que ce soit. Ajoutez defer aux scripts qui n'ont pas besoin de s'exécuter immédiatement, par exemple <script src="/app.js" defer></script>, regroupez ou supprimez les feuilles de style superflues, et envisagez d'intégrer directement dans la page la petite quantité de CSS nécessaire au haut de page.

5. Pas de compression

Les fichiers texte (HTML, CSS, JavaScript, JSON, SVG) s'allègent considérablement avec gzip ou Brotli. Dans l'onglet Réseau du navigateur, cherchez content-encoding: br ou gzip dans les en-têtes de réponse de votre page. S'il est absent, activez la compression sur le serveur (dans nginx, gzip on; accompagné d'une liste gzip_types) ou au niveau de votre CDN.

6. Des fichiers statiques non mis en cache

Les visiteurs qui reviennent ne devraient pas retélécharger votre logo et votre feuille de style. Pour les fichiers dont le nom change en même temps que le contenu (la plupart des outils de build ajoutent une empreinte, comme dans app.3f9a2c.js), envoyez Cache-Control: public, max-age=31536000, immutable. Gardez pour le HTML un cache court ou une revalidation, afin que les mises à jour apparaissent sans délai.

7. Des polices web trop lourdes

Plusieurs familles de polices, chacune déclinée en de nombreuses graisses, finissent vite par peser, et le texte peut rester invisible pendant leur téléchargement. Limitez le nombre de graisses, servez du WOFF2, réduisez les polices aux seuls caractères utiles, ajoutez font-display: swap pour que le texte s'affiche immédiatement dans une police de remplacement, et ne préchargez que la police utilisée au-dessus de la ligne de flottaison. Une pile de polices système évite totalement le téléchargement.

8. Les décalages de mise en page

Les pages qui sautent le doivent en général à des images et des contenus intégrés sans espace réservé, à des publicités injectées dans le contenu ou à des bandeaux qui surgissent au-dessus du texte après le chargement. Donnez à chaque image des attributs width et height (ou un aspect-ratio en CSS), réservez la place des publicités et des contenus intégrés avec un min-height, et affichez les bandeaux cookies et promotionnels en superposition plutôt qu'en repoussant le contenu vers le bas.

9. Des pages obèses et trop de requêtes

Des documents HTML très volumineux (souvent à cause de données intégrées en ligne ou de grilles de produits interminables), des dizaines de scripts et un même script inclus deux fois : tout cela ralentit une page. Paginez les longues listes, déplacez les données volumineuses intégrées vers des fichiers séparés et mis en cache, et supprimez les balises en double. Le crawl de Rudra signale les documents HTML de plus de 1 Mo, les pages qui référencent plus de 100 ressources et les scripts chargés plusieurs fois.

10. Des redirections avant même que la page ne démarre

Un visiteur qui saisit example.com et se voit redirigé vers https://example.com, puis vers https://www.example.com, puis vers /home, attend à chaque saut. Redirigez directement vers l'URL finale en une seule étape, et pointez partout vos liens vers les URL finales.

Que corriger en premier

1. Si la réponse du serveur est lente, commencez par là. Tous les autres indicateurs en dépendent.
2. Si le LCP est mauvais, identifiez l'élément LCP. Lighthouse le nomme. Il s'agit en général d'une image d'en-tête (compressez-la, ne la chargez pas en différé et envisagez fetchpriority="high") ou d'un titre retardé par les polices ou par des CSS qui bloquent le rendu.
3. Si le Total Blocking Time ou l'INP est mauvais, regardez du côté du JavaScript, en particulier des balises tierces.
4. Si le CLS est mauvais, réservez de l'espace pour les images, les contenus intégrés, les publicités et les bandeaux.
5. Refaites un test après chaque modification, pour savoir ce qui a réellement servi.

Ce qu'un test de vitesse ne peut pas vous dire

Un test de laboratoire charge une seule URL publique, hors connexion à un compte, depuis un seul endroit. Il ne montrera ni l'étape de paiement lente située derrière une authentification, ni la page qui n'est lente que pour les visiteurs d'un autre continent, ni le widget qui ne se dérègle qu'après une minute de défilement. Servez-vous-en pour trouver et expliquer les problèmes, puis confirmez les améliorations dans les données de terrain au cours des semaines suivantes.

Les erreurs courantes

• Courir après un score Lighthouse parfait plutôt qu'après les indicateurs que vos visiteurs ressentent.
• Ne tester que sur ordinateur, avec le Wi-Fi rapide du bureau.
• Charger en différé (lazy loading) l'image d'en-tête, ce qui retarde le LCP.
• Installer plusieurs extensions de « vitesse » ou de cache qui entrent en conflit.
• Juger une modification sur un seul test ; les résultats varient d'une exécution à l'autre.