POURQUOI VOTRE SITE EST LENT
La poignée de causes derrière presque chaque site lent, comment prouver laquelle vous avez, et l'ordre qui fait réellement bouger les données de terrain.
← Guides All guides in this topic
Mesurez avant de deviner
Si vous ouvrez DevTools, changez trois plugins et redéployez sans regarder les données de terrain, vous devinez avec des étapes supplémentaires. Lent est une expérience visiteur. Prouvez-le avec des chiffres d'utilisateurs réels avant de toucher au code.
Commencez par les données de terrain du Chrome UX Report dans PageSpeed Insights ou les Core Web Vitals de la Search Console. Vous voulez le 75e percentile pour Largest Contentful Paint, Interaction to Next Paint, et Cumulative Layout Shift sur mobile. Les scores de lab de Lighthouse sont utiles pour déboguer un chargement de page unique. Ce ne sont pas la métrique que Google utilise pour le classement ni la métrique que vos acheteurs ressentent sur une connexion Wi-Fi en train.
Ce qu'il faut capturer dans les dix premières minutes
URL de la page lente. Classe d'appareil (mobile d'abord). Si le problème est la première visite ou une visite ultérieure. Si les pages connectées diffèrent de la page d'accueil publique. TTFB si vous pouvez le voir. Le nom de l'élément LCP du panneau de diagnostics. Cette courte liste pointe généralement la bonne voie avant que quiconque ne débatte des frameworks.
Point clé : Les données de terrain décident si le site est lent. Les données de lab vous aident à trouver le levier. Ne jamais inverser cet ordre.
Frontend ou serveur ?
Si la page est lente avant l'apparition de tout contenu, c'est généralement le serveur : temps élevé avant le premier octet, une requête de base de données non mise en cache, rendu PHP ou Node à chaque requête, ou un hébergement simplement sous-alimenté. Si le contenu apparaît puis saccade, stagne ou se décale, c'est le front-end : images, scripts, polices et mise en page.
Une séparation utile : TTFB sous environ 0,8 secondes signifie que l'origine est surtout hors du chemin critique. Au-dessus de 1,2 secondes sur une page commercialisée, corrigez l'hébergement, le cache ou le coût du rendu serveur avant de vous acharner sur les codecs d'image. Pour les gros sites, le diagnostic a son propre playbook dans la checklist Core Web Vitals et le guide de correction LCP, INP, CLS sur ce site.
| Symptom | Likely lane | First check |
|---|---|---|
| Blank screen, then everything | Server / TTFB | Host, cache hit rate, SSR cost |
| Hero late, rest fine | Front-end LCP | Hero image size, preload, CDN |
| Taps feel sticky | Front-end INP | JS weight, long tasks, third parties |
| Page jumps while loading | Front-end CLS | Image dimensions, font swap, ads |
Point clé : Nommez d'abord la voie. Le travail serveur et le travail front-end nécessitent des personnes et des outils différents.
Les six suspects habituels
Dans l'ordre de fréquence où ils sont le vrai problème sur les sites commerciaux que je vois :
1. Médias hero surdimensionnés
Un PNG de 2MB ou un upload non recadré du CMS en tant qu'élément LCP. Correction : redimensionner, format moderne (WebP ou AVIF), attributs width et height, précharger l'URL LCP réelle, servir depuis un CDN. Une seule bonne correction hero bat souvent dix micro-optimisations.
2. JavaScript dont vous n'avez pas besoin au premier rendu
Gestionnaires de balises, widgets de chat, outils A/B, hydratation de framework inutilisée, et composants client « au cas où ». Correction : différer ou retirer les tierces parties, envoyer moins de JS sur les routes marketing, garder les îles d'interactivité petites.
3. Hébergement et ratés de cache
Hébergeurs partagés, WordPress sans cache de pages, Next.js SSR sur chaque URL publique, ou motifs ISR qui reconstruisent tout à chaque déploiement. Correction : hébergement géré ou cache edge pour WordPress, statique ou ISR avec une politique de revalidation sensée pour les frameworks d'app.
4. Polices et CSS bloquant le rendu
Cinq graisses d'une police d'affichage, importées depuis un fichier CSS tiers, bloquant le texte. Correction : subsetter, auto-héberger, font-display swap ou optional, CSS critique pour le contenu above-the-fold.
5. Tierces parties sans limites
Des pixels qui injectent d'autres pixels. Correctif : charger après interaction ou en inactivité, éliminer tout ce qui ne justifie pas sa place dans un test de conversion.
6. Décalage de mise en page dû à un contenu tardif
Annonces publicitaires, contenus intégrés et images sans espace réservé. Correctif : boîtes aspect-ratio, emplacements réservés, éviter d'injecter des éléments d'interface au-dessus du contenu existant.
Point clé : la plupart des plaintes « le framework est lent » sont l'une de ces six causes travesties en problème de framework.
Corrigez d'abord la plus grosse chose
N'optimisez pas tout en même temps. Ouvrez l'entrée LCP dans vos diagnostics terrain ou labo, identifiez l'élément qui est le LCP (généralement l'image héros ou le titre), et rendez cette seule chose rapide : dimensionnée correctement, préchargée, servie depuis un CDN. Re-mesurez. Ensuite, supprimez le JavaScript qui s'exécute sur le chemin critique. Re-mesurez à nouveau.
Un ordre pratique pour un site marketing : élément LCP, puis JS tiers, puis chargement des polices, puis cache et TTFB, puis nettoyage CLS, puis micro-optimisations. S'arrêter après les deux premiers met souvent un site commercial dans une bande CWV acceptable.
Note WordPress : un régime de plugins et un vrai cache de pages sur l'hébergement géré battent une réécriture de thème plus souvent que les agences ne l'admettent. Note Next.js et Astro : ne faites pas de SSR pour la brochure. HTML statique ou en cache pour les pages publiques ; réservez le travail serveur aux surfaces de produit authentifiées. Les détails se trouvent dans le guide Next.js vs Astro vs WordPress.
Point clé : une victoire LCP mesurée vaut mieux qu'une semaine de refactors spéculatifs.
Modes de défaillance spécifiques à la pile
WordPress
Les générateurs de pages livrent tout le CSS de chaque widget sur chaque page. Les modèles WooCommerce non mis en cache. Les requêtes de posts liés lourdes. Les tables d'options autoloadées qui ont grossi pendant des années. Chemin de correction : mettre en cache le HTML à la périphérie, réduire les plugins, charger paresseusement les sections du générateur sous la ligne de flottaison, corriger l'encrassement de l'autoload de la base de données.
Next.js
Composants clients enveloppant des pages entières. Des cascades d'attentes séquentielles. Des images passant par le mauvais chargeur. ISR ou SSR sur des pages qui ne se personnalisent jamais. Chemin de correction : Server Components par défaut, statique si possible, auditer le bundle JS par route.
Astro et autres piles statiques
Généralement rapides sauf si vous réintroduisez une île SPA de la taille d'une application de produit, ou des hotlinks de médias CMS géants. Chemin de correction : garder les îles minuscules, traiter les images dans le pipeline, ne pas coller les habitudes WordPress dans un site statique.
Point clé : adapter la correction à la pile. La migration de plateforme est rarement le premier pas en matière de performance.
À quoi ressemble la qualité
Cibles, mesurées sur les vrais visiteurs au 75e percentile 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. Garder le time to first byte sous environ 0,8 secondes pour que le serveur reste en dehors du chemin critique.
Remplissez ceux-ci et le site n'est pas lent de la manière qu'un visiteur ou Google punira, peu importe ce qu'un score de vanité synthétique dit. Tout ce qui est plus rapide est du polissage. Livrez le produit au lieu de chasser des 100.
Si vous voulez la forme de liste de contrôle de ce travail, utilisez la liste de contrôle Core Web Vitals. Si vous avez besoin d'une chirurgie par métrique, utilisez le guide de correction LCP, INP et CLS. Si le cas commercial est une reconstruction, commencez par le pilier de la performance plutôt qu'un deck de redesign.
Point clé : passer les CWV sur le terrain est la ligne d'arrivée pour « c'est lent ? », pas une capture d'écran Lighthouse parfaite.
Quand arrêter le DIY et demander de l'aide
Le DIY suffit quand l'élément LCP est évident, les tiers sont peu nombreux, et vous contrôlez l'hébergement. Faites appel à de l'aide quand les données de terrain restent rouges après deux cycles de correction honnêtes, quand la stack est un hybride que personne dans l'équipe ne maîtrise, ou quand les pages de revenu ne peuvent pas supporter une autre semaine de changements spéculatifs.
Un brief utile pour un tiers : les trois URLs qui comptent, les captures d'écran de terrain, les noms des éléments LCP, l'hébergeur et le CDN, et la liste des tags que vous ne devez pas supprimer. Ce package transforme un vague « le site est lent » en un travail d'un sprint.
Si la conversation se transforme en refonte complète, faites une pause. Le travail de performance et le travail de refonte se combinent mal sauf si la refonte a un budget CWV explicite. Corrigez d'abord les modèles actuels quand l'entreprise en dépend encore.
À retenir : Deux cycles de correction échoués ou pas de propriétaire clairement identifié, c'est la limite entre le DIY et un audit de performance payant.