POURQUOI VOTRE SITE EST-IL LENT ?
Les quelques causes à l'origine de la lenteur de presque tous les sites web, comment déterminer celle qui s'applique à votre cas, et l'ordre dans lequel les données sont réellement transférées.
← Tous les guides Tous les guides de ce sujet
Mesurez avant de deviner
Si vous ouvrez DevTools, modifiez trois extensions et effectuez un nouveau déploiement sans consulter les données de terrain, vous avancez à l'aveuglette en multipliant les étapes inutiles. La lenteur est une expérience vécue par les visiteurs. Prouvez-le à l'aide de chiffres provenant d'utilisateurs réels avant de toucher au code.
Commencez par consulter les données de terrain du rapport Chrome UX dans PageSpeed Insights ou dans la section « Core Web Vitals » de la Search Console. Visez le 75e centile pour les indicateurs « Largest Contentful Paint », « Interaction to Next Paint » et « Cumulative Layout Shift » sur mobile. Les scores de laboratoire fournis par Lighthouse sont utiles pour déboguer le chargement d'une page spécifique. Ils ne correspondent toutefois pas aux indicateurs utilisés par Google pour le classement, ni à ceux que vos clients perçoivent lorsqu'ils se connectent au Wi-Fi dans un train.
Ce qu'il faut montrer dans les dix premières minutes
URL de la page lente. Catégorie d'appareil (priorité au téléphone). S'il s'agit d'une première visite ou d'une visite récurrente. Si les pages accessibles après connexion diffèrent de la page d'accueil publique. Le TTFB si vous pouvez le voir. Le nom de l'élément LCP indiqué dans le panneau de diagnostic. Cette courte liste permet généralement de s'orienter dans la bonne direction avant même d'aborder la question des frameworks.
Point clé : ce sont les données de terrain qui déterminent si le site est lent. Les données de laboratoire vous aident à identifier le levier d'action. Ne inversez jamais cet ordre.
Côté client ou côté serveur ?
Si la page est lente avant même que le contenu n'apparaisse, le problème vient généralement du serveur : un temps de réponse trop long entre la requête et le premier octet, une requête de base de données non mise en cache, un rendu PHP ou Node à chaque requête, ou encore un hébergeur tout simplement sous-dimensionné. Si le contenu s'affiche mais présente des saccades, des blocages ou des décalages, le problème vient du front-end : images, scripts, polices et mise en page.
Une distinction utile : un TTFB inférieur à environ 0,8 seconde signifie que l’origine se trouve pour l’essentiel hors du chemin critique. Au-delà de 1,2 seconde sur une page commercialisée, corrigez les problèmes liés à l’hébergement, au cache ou au temps de rendu serveur avant de vous focaliser sur les codecs d’images. Pour les sites de grande envergure, le diagnostic fait l’objet d’un guide spécifique dans la liste de contrôle des Core Web Vitals et dans le guide de correction des indicateurs LCP, INP et CLS disponible sur ce site.
| Symptôme | Voie probable | Première vérification |
|---|---|---|
| Un écran noir, puis tout s'affiche | Serveur / TTFB | Hôte, taux de réussite du cache, coût du SSR |
| Hero en retard, les autres vont bien | LCP côté client | Taille de l'image hero, preload, CDN |
| Les robinets semblent difficiles à ouvrir | INP côté client | Poids du code JS, tâches longues, composants tiers |
| La page saute pendant le chargement | CLS côté client | Dimensions des images, remplacement des polices, publicités |
Point clé : définissez d'abord le domaine d'intervention. Le travail côté serveur et celui côté front-end nécessitent des personnes et des outils différents.
Les six suspects habituels
Par ordre de fréquence, voici les problèmes qui, d'après mon expérience, constituent le véritable problème sur les sites commerciaux :
1. Visuels grand format
Un fichier PNG de 2 Mo ou un fichier non recadré téléchargé via le CMS comme élément LCP. Solution : redimensionnement adapté, format moderne (WebP ou AVIF), attributs « width » et « height », préchargement de l'URL LCP réelle, diffusion via un CDN. Une bonne solution globale vaut souvent mieux que dix micro-ajustements.
2. Le code JavaScript dont vous n'avez pas besoin lors du premier affichage
Gestionnaires de balises, widgets de chat, outils A/B, intégration de frameworks inutilisés et composants client « au cas où ». Solution : différer ou supprimer les éléments tiers, réduire la quantité de code JS transmise sur les routes marketing, limiter la taille des zones d'interactivité.
3. Hébergement et échecs de mise en cache
Hébergements mutualisés, WordPress « à froid » sans cache de page, Next.js SSR sur chaque URL publique, ou modèles ISR qui reconstruisent l'ensemble du site à chaque déploiement. Solution : hébergement géré ou cache en périphérie pour WordPress, contenu statique ou ISR avec une politique de revalidation raisonnable pour les frameworks d'applications.
4. Polices et CSS bloquant le rendu
Cinq graisses d'une police d'affichage, importées depuis un fichier CSS tiers, bloquent le texte. Solution : utiliser un sous-ensemble, héberger la police en local, utiliser la propriété `font-display` avec la valeur « swap » ou « optional », ou encore mettre en place un CSS critique pour la partie visible de la page.
5. Tiers non liés
Des pixels qui génèrent encore plus de pixels. Solution : charger après une interaction ou en mode veille, supprimer tout ce qui ne justifie pas sa présence dans un test de conversion.
6. Modification de la mise en page due à l'ajout de contenu en fin de document
Publicités, éléments intégrés et images sans espace réservé. Solution : zones au format adapté, emplacements réservés, éviter d'insérer des éléments d'interface utilisateur au-dessus du contenu existant.
Point à retenir : la plupart des plaintes du type « le framework est lent » relèvent en réalité de l'un de ces six cas, sous le couvert du framework.
Commencez par régler le problème le plus important
N’essayez pas d’optimiser tout en même temps. Ouvrez l’entrée « LCP » dans vos outils de diagnostic sur le terrain ou en laboratoire, identifiez l’élément qui correspond au LCP (généralement l’image principale ou le titre), et veillez à ce que cet élément soit rapide : redimensionné, préchargé et diffusé via un CDN. Effectuez une nouvelle mesure. Supprimez ensuite le code JavaScript qui s’exécute sur le chemin critique. Effectuez une nouvelle mesure.
Un ordre d'priorité pratique pour un site commercial : élément LCP, puis scripts JS tiers, puis chargement des polices, puis cache et TTFB, puis correction du CLS, puis micro-optimisations. En s'arrêtant après les deux premières étapes, on parvient souvent à faire entrer un site commercial dans une fourchette de CWV acceptable.
Remarque concernant WordPress : un allègement des plugins et une véritable mise en cache des pages sur un hébergement géré s’avèrent souvent plus efficaces qu’une refonte du thème, même si les agences ont tendance à ne pas l’admettre. Remarque concernant Next.js et Astro : n’utilisez pas le SSR pour la brochure. Privilégiez le HTML statique ou mis en cache pour les pages publiques ; réservez la charge de travail du serveur aux interfaces produit nécessitant une authentification. Vous trouverez plus de détails dans le guide comparatif Next.js vs Astro vs WordPress.
Point à retenir : une amélioration LCP mûrement réfléchie vaut mieux qu'une semaine de refactorisations hasardeuses.
Modes de défaillance spécifiques à la pile
WordPress
Les éditeurs de pages intègrent le CSS de chaque widget sur toutes les pages. Modèles WooCommerce non mis en cache. Requêtes lourdes pour les articles connexes. Tables d’options chargées automatiquement qui n’ont cessé de grossir au fil des ans. Solution : mettre l’HTML en cache en périphérie, supprimer les plugins superflus, activer le chargement différé des sections de l’éditeur situées sous la ligne de flottaison, et remédier au gonflement de la base de données dû au chargement automatique.
Next.js
Des composants client encapsulant des pages entières. Une succession interminable d’attentes séquentielles. Des images chargées via le mauvais chargeur. ISR ou SSR sur des pages qui ne s’adaptent jamais à l’utilisateur. Solution : privilégier les composants serveur par défaut, utiliser du contenu statique lorsque cela est possible, et auditer le bundle JS pour chaque route.
Astro et autres piles statiques
En général, cela fonctionne rapidement, sauf si vous réintroduisez une « île SPA » de la taille d'une application produit ou si vous créez des liens directs vers des fichiers multimédias volumineux provenant d'un CMS. Solution : veillez à ce que les « îles » restent minuscules, traitez les images en amont et ne reproduisez pas les pratiques de WordPress sur un site statique.
Point clé : adapter la solution à la pile technologique. Le changement de plateforme est rarement la première mesure à prendre pour améliorer les performances.
À quoi ressemble la qualité ?
Objectifs, mesurés sur les visiteurs réels au 75e centile sur mobile : « Largest Contentful Paint » inférieur à 2,5 secondes, « Interaction to Next Paint » inférieur à 200 millisecondes, « Cumulative Layout Shift » inférieur à 0,1. Maintenir le temps jusqu'au premier octet (TTPB) en dessous d'environ 0,8 seconde afin que le serveur reste hors du chemin critique.
Si vous respectez ces critères, le site ne présentera aucun ralentissement susceptible d'être sanctionné par les visiteurs ou par Google, quel que soit le score de « vanité » calculé de manière artificielle. Tout ce qui va plus vite n'est qu'une question de finition. Lancez le produit plutôt que de courir après les notes parfaites.
Si vous souhaitez disposer d'une liste de contrôle pour ce travail, utilisez la liste de contrôle Core Web Vitals. Si vous avez besoin d'interventions spécifiques à chaque indicateur, utilisez le guide de correction LCP, INP et CLS. Si le projet consiste en une refonte, commencez par le pilier « performances » plutôt que par un dossier de refonte.
Point clé : la réussite du test CWV correspond à la ligne d'arrivée de la question « est-ce lent ? », et non à une capture d'écran parfaite de Lighthouse.
Quand faut-il renoncer au « faites-le vous-même » et demander de l'aide ?
Le « faites-le vous-même » suffit lorsque le problème LCP est évident, que les tiers sont peu nombreux et que vous contrôlez l'hébergement. Faites appel à de l'aide lorsque les données de terrain restent dans le rouge après deux cycles de correction sérieux, lorsque la pile est hybride et qu'aucun membre de l'équipe n'en est responsable, ou lorsque les pages génératrices de revenus ne peuvent pas se permettre une semaine supplémentaire de modifications aléatoires.
Un récapitulatif utile pour les non-initiés : les trois URL essentielles, les captures d'écran des champs, les noms des éléments LCP, l'hébergeur et le CDN, ainsi que la liste des balises que vous n'avez pas le droit de supprimer. Ce dossier permet de transformer un vague « le site est lent » en une tâche réalisable en un seul sprint.
Si la discussion débouche sur une refonte complète, prenez le temps de réfléchir. Les travaux d'optimisation des performances et de refonte ne font pas bon ménage, à moins que la refonte ne dispose d'un budget CWV clairement défini. Commencez par corriger les modèles actuels tant que l'entreprise en dépend encore.
Point clé : deux cycles de correction infructueux ou l'absence d'un responsable clairement identifié constituent la ligne de démarcation entre le « faites-le vous-même » et le recours à un service payant.