Pourquoi mon site est lent, et est-ce que ça nous coûte des clients ?

Le site s’ouvre sur l’ordinateur du bureau et tout a l’air normal. Puis un client vous glisse qu’il a mis une éternité à charger sur son téléphone, ou vous l’ouvrez vous-même en données mobiles sur un parking et regardez le logo rester seul sur fond blanc pendant que le reste arrive. Vous tapez « pourquoi mon site est lent », lancez un test de vitesse gratuit et obtenez une page de voyants rouges et de jargon qui ne dit pas quoi faire concrètement.

Les conclusions habituelles : il faut monter en gamme d’hébergement ou refaire tout le site. Parfois l’une des deux est vraie. Le plus souvent, les causes sont peu nombreuses, visibles dans le navigateur que vous avez déjà, et les moins chères viennent en premier. Un site lent n’est pas qu’un agacement : un visiteur qui a attendu assez longtemps pour s’énerver remplit rarement un formulaire, et c’est l’une des raisons discrètes pour lesquelles un site reçoit des visites mais aucune demande.

Pourquoi mon site est lent : les causes habituelles

Les images sont bien plus grandes que l’espace qu’elles occupent. Les photos passent directement de l’appareil photo ou de la banque d’images à la page, plusieurs fois plus larges que le cadre où elles s’affichent, et le navigateur télécharge le fichier entier avant de le réduire. Le signe : la structure de la page apparaît vite, mais les images se remplissent une à une, et le site est nettement moins bon sur téléphone que sur un ordinateur câblé.

Trop de plugins, de widgets et de scripts. Un site sur un CMS ou un constructeur de sites accumule des modules au fil des ans : un carrousel, un widget de chat, plusieurs balises d’analyse, une bannière de cookies, un module de réservation que plus personne n’utilise, une vidéo en lecture automatique dans l’en-tête. Chacun charge son propre code avant que la page ne se stabilise. Le signe : la page continue de travailler longtemps après que le texte est visible, les boutons ne répondent pas tout de suite, et la mise en page saute à mesure que les éléments arrivent.

Le serveur met du temps à répondre. Avant que le moindre élément n’apparaisse, le navigateur attend le serveur. Un hébergement mutualisé bon marché, un CMS qui reconstruit chaque page à chaque visite parce que le cache est désactivé, ou une base de données qui a grossi pendant des années : tout cela se manifeste de la même façon, un écran blanc pendant un instant, puis tout d’un coup.

Le visiteur est loin du serveur. Un site hébergé dans un pays et consulté depuis un autre perd du temps sur la seule distance ; il paraît rapide chez vous et lent à l’étranger, et personne chez vous ne s’en aperçoit. Le signe : les plaintes viennent d’une région précise.

Un élément de la page bloque tout le reste. Une police qui doit être téléchargée avant qu’un seul mot ne s’affiche, une carte intégrée sur chaque page, un script qui attend un service tiers qui passe une mauvaise journée. Le signe : le site va bien certains jours et pas d’autres, ou reste blanc jusqu’à ce qu’un élément précis apparaisse.

Comment savoir laquelle est la vôtre

Tout ce qui suit se fait avec un téléphone, un ordinateur portable et les outils gratuits déjà intégrés à votre navigateur. Procédez dans l’ordre ; la première vérification qui échoue est généralement votre cause.

1. Ouvrez le site sur un téléphone en données mobiles, pas en Wi-Fi. Chronométrez grossièrement avec une montre, du moment où vous touchez le lien jusqu’à celui où vous pouvez lire et cliquer, puis faites de même sur l’ordinateur. Un téléphone nettement plus lent pointe vers les images et les scripts lourds.
2. Observez ce qui apparaît en premier. Rechargez et notez l’ordre. Un écran blanc suivi de tout d’un coup pointe vers le serveur ; le texte d’abord et les images au compte-gouttes pointent vers les images ; une mise en page qui saute et des boutons qui ne répondent pas pointent vers les scripts.
3. Lancez un test de vitesse gratuit d’un grand moteur de recherche ou éditeur de navigateur et ignorez la note. Lisez seulement la liste des fichiers les plus lourds et les améliorations suggérées : elles nomment en termes clairs les images surdimensionnées, les scripts inutilisés et la réponse lente du serveur. Testez une page de service, pas seulement la page d’accueil.
4. Ouvrez les outils de développement du navigateur sur l’onglet réseau, rechargez et triez par taille. Si les plus grosses entrées sont des fichiers image bien plus grands que l’image visible, vous avez votre réponse ; si la liste contient des dizaines de scripts venant de domaines que vous ne reconnaissez pas, comptez les plugins.
5. Listez chaque plugin, widget et balise tierce du site et écrivez à côté qui s’en sert et pour quoi. D’après notre expérience, la liste est plus longue que prévu, et une partie est morte.
6. Vérifiez la formule d’hébergement et le réglage du cache. Connectez-vous au panneau d’hébergement et regardez ce que vous payez et si le cache de page est activé. Si vous ne savez pas, la personne qui a construit le site le sait, et la question tient en un e-mail.
7. Testez depuis vos autres marchés. Demandez à un collègue à l’étranger de chronométrer la même page, ou utilisez un test gratuit qui permet de choisir le lieu du test.

La correction, dans l’ordre

Le moins cher d’abord. D’après notre expérience, la plupart des sites récupèrent l’essentiel de leur vitesse dès les trois premières étapes, sans refonte.

1. Redimensionnez et compressez les images. Exportez les photos à la taille que la mise en page utilise réellement, dans un format web moderne, et remplacez les originaux ; sur un CMS, un plugin d’optimisation d’images traite toute la bibliothèque en une passe. C’est la correction la plus courante et elle coûte un après-midi.
2. Supprimez ce qui ne sert pas. Désactivez et supprimez chaque plugin, widget et balise pour lesquels personne n’a pu nommer un utilisateur, fusionnez les balises d’analyse en double en une seule, remplacez une carte intégrée par une image statique qui renvoie vers la carte, et chargez en différé tout ce qui se trouve sous le premier écran.
3. Activez le cache. Le cache de page signifie que le serveur distribue une copie toute prête au lieu de reconstruire la page pour chaque visiteur. La plupart des CMS et des hébergeurs le proposent sous forme de réglage ou de plugin.
4. Corrigez les éléments bloquants. Chargez les polices de façon que le texte s’affiche immédiatement dans une police de substitution avant d’être remplacé, différez les scripts inutiles au premier écran et retirez toute vidéo de l’en-tête. En général une heure de développeur, pas un projet.
5. Rapprochez le site du visiteur. Un réseau de diffusion de contenu (CDN) conserve des copies de vos fichiers statiques dans de nombreuses régions, de sorte qu’un visiteur d’un autre pays télécharge depuis un point proche. La plupart des hébergeurs et des services de domaines en proposent un ; si vous vendez à l’international, cela passe avant toute montée en gamme d’hébergement.
6. Ne changez d’hébergement que si le serveur est prouvé lent. Si l’attente sur écran blanc persiste une fois le cache activé, la formule est le goulot d’étranglement. Passez à une formule adaptée au trafic, pas à la moins chère qui fonctionne techniquement.
7. Refaites les pages les plus lourdes, pas le site. Si un modèle traîne des dizaines de composants sur chaque page, reconstruire les pages d’atterrissage clés sur une structure plus légère suffit souvent. Dans nos projets de création de sites web, la vitesse est un critère de mise en ligne, et c’est l’étape où une page est conçue autour de ce qu’elle doit faire plutôt que de ce que le thème propose.

La vitesse influe aussi sur la façon dont le site est trouvé : les moteurs de recherche mesurent les mêmes attentes que vos visiteurs ressentent, donc les changements ci-dessus font partie de tout travail SEO honnête. Et si le site est lent depuis longtemps, des demandes ont été perdues en silence ; noter d’où vient chaque demande, ce par quoi commencent nos projets CRM et analytics, vous dit si la correction a changé quelque chose.

Quoi mesurer

• Le temps jusqu’à une page utilisable sur téléphone en données mobiles, chronométré à la main de la même façon à chaque fois, tous les mois.
• Le poids des pages et le nombre de requêtes pour les principales pages d’atterrissage, depuis l’onglet réseau, avant et après chaque changement.
• Le temps de réponse du serveur affiché dans le test de vitesse, l’attente avant que quoi que ce soit n’arrive, qui devrait baisser une fois le cache activé.
• Le taux de rebond et les formulaires envoyés sur les pages modifiées, dans vos statistiques, quelques semaines après le changement contre quelques semaines avant.

Là où nous intervenons

Un dirigeant avec une soirée, une heure de développeur et un accès à l’hébergement peut faire tout cela. Ce que nous ajoutons, c’est l’ordre : les images et le poids mort avant l’hébergement, le cache avant la refonte, et une mesure avant et après pour que l’amélioration soit un fait et non une impression. Si vous préférez confier le diagnostic, un court brief avec l’adresse du site et les pages qui comptent le plus suffit pour commencer.

← Tous les articles