📌 Mon site est lent : le diagnostic en 5 étapes simples

TL;DRArticle à jour en septembre 2026. Google fait évoluer ses indicateurs de vitesse : nous mettons ce guide à jour quand sa documentation officielle change.

📌 ⏱️ Le test en 3 minutes (à faire avant de lire la suite)#

1. Ouvrez PageSpeed Insights, l’outil gratuit de Google.
2. Collez l’adresse de votre page d’accueil. Lancez l’analyse. Restez sur l’onglet Mobile.
3. Refaites le test avec une page produit ou une page service : c’est souvent là que vos clients arrivent depuis Google.
4. Pour chaque page, notez 3 chiffres seulement, dans le bloc du haut « Découvrez ce que vivent vos utilisateurs réels » :
   • LCP (en secondes) → bon si ≤ 2,5 s
   • INP (en millisecondes) → bon si ≤ 200 ms
   • CLS (un nombre sans unité) → bon si ≤ 0,1

Ignorez pour l’instant la note sur 100. Gardez ces 6 chiffres sous la main : ils vous serviront à l’étape 5.

📌 Pourquoi « mon site est lent » est un vrai sujet business#

Un client vous l’a dit, ou vous l’avez senti vous-même sur votre téléphone : votre site rame. Ce n’est pas qu’une question de confort. Une étude menée par Deloitte et l’agence 55 pour Google, « Milliseconds Make Millions » (2020), a observé que gagner 0,1 seconde de temps de chargement sur mobile s’accompagnait, chez les sites e-commerce étudiés, d’une hausse de 8,4 % des conversions.

Côté référencement, Google l’écrit noir sur blanc : les Core Web Vitals sont utilisés par ses systèmes de classement. Mais il précise aussi, et c’est important, qu’il cherche toujours à montrer le contenu le plus pertinent, même si l’expérience de la page est moyenne. La vitesse ne remplace pas un bon contenu, mais elle peut faire fuir les visiteurs qu’il a attirés.

Le problème, c’est que votre ressenti vous trompe. Vous consultez votre site en fibre, sur un ordinateur récent. Votre navigateur a déjà gardé en mémoire (« en cache ») une partie des fichiers. Votre client, lui, arrive pour la première fois, en 4G, sur un téléphone de milieu de gamme.

Bonne nouvelle : dans la grande majorité des cas, 3 ou 4 corrections bien ciblées suffisent. Encore faut-il savoir lesquelles. Voici la méthode.

📌 Étape 1 : mesurer, pas ressentir#

🛠️ Les 4 outils gratuits à connaître#

• PageSpeed Insights : l’outil de référence de Google. Il affiche à la fois les données de vos vrais visiteurs et un test simulé.
• Le rapport « Signaux Web essentiels » de la Google Search Console : il classe toutes vos pages en « Bonnes », « À améliorer » ou « Médiocres ». Idéal pour voir si le problème touche tout le site ou quelques pages.
• WebPageTest : il montre, fichier par fichier, dans quel ordre votre page se charge. Très utile pour démasquer un script qui bloque.
• GTmetrix : une alternative visuelle, avec historique.

📌 La différence capitale : laboratoire contre terrain#

C’est la notion à retenir de cet article.

• Les données de laboratoire sont un test simulé. Un robot charge votre page une fois, avec un téléphone et une connexion fictifs. C’est un crash-test : utile pour trouver les défauts, mais ce n’est pas la route réelle.
• Les données de terrain sont celles de vos vrais visiteurs sur Chrome, collectées anonymement par Google sur les 28 derniers jours. C’est le compteur de votre voiture après un mois de trajets réels.

Google le recommande lui-même : quand vous avez les deux, ce sont les données de terrain qui doivent guider vos priorités.

À noter : si votre site a peu de trafic, PageSpeed Insights peut afficher des données pour l’ensemble du site au lieu de la page, voire aucune donnée de terrain. Dans ce cas, le test de laboratoire devient votre seul repère. Lancez-le 3 fois et retenez la valeur médiane : le score varie naturellement d’un test à l’autre.

Enfin, comparez l’onglet Mobile et l’onglet Ordinateur : un écart important est normal. C’est le mobile qu’il faut regarder en priorité.

📌 Étape 2 : lire les 3 indicateurs qui comptent vraiment#

Google résume l’expérience de vitesse en trois indicateurs, les Core Web Vitals (« signaux web essentiels »). Pour chacun, Google regarde ce que vivent 75 % de vos visiteurs : il ne suffit pas que la moyenne soit bonne.

📌 LCP : « quand est-ce que je vois la page ? »#

Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus gros élément visible : souvent la photo principale ou le grand titre.

• Seuil : bon jusqu’à 2,5 s, médiocre au-delà de 4 s.
• Ce que vit le visiteur : un écran blanc ou à moitié vide. Il repart.

📌 INP : « quand je clique, est-ce que ça réagit ? »#

L’INP (Interaction to Next Paint) mesure le délai entre une action (clic, tap, saisie) et la réponse visible à l’écran. Il a remplacé l’ancien indicateur FID le 12 mars 2024.

• Seuil : bon jusqu’à 200 ms, médiocre au-delà de 500 ms.
• Ce que vit le visiteur : il appuie sur « Ajouter au panier » et rien ne se passe. Il appuie une deuxième fois : le produit est ajouté deux fois.

📌 CLS : « est-ce que la page bouge toute seule ? »#

Le CLS (Cumulative Layout Shift) mesure les décalages de mise en page inattendus. C’est un score sans unité.

• Seuil : bon jusqu’à 0,1, médiocre au-delà de 0,25.
• Ce que vit le visiteur : il veut cliquer sur un lien, une bannière apparaît au-dessus, tout descend, et il clique sur autre chose. Les causes les plus fréquentes : images sans dimensions, publicités, contenus insérés tardivement et polices de caractères.

Ces seuils sont ceux publiés par Google sur web.dev et dans l’aide de la Search Console.

🌐 Bonus : le TTFB, l’indice d’un problème serveur#

Le TTFB (Time to First Byte) mesure le temps que met votre serveur à envoyer le tout premier morceau de la page. C’est le temps que met le serveur du restaurant à vous apporter la carte : tant qu’elle n’est pas là, rien ne peut commencer. Google recommande de viser 0,8 s ou moins. Vous le trouverez dans PageSpeed Insights, dans les indicateurs expérimentaux du bloc terrain. Un TTFB élevé pointe presque toujours vers l’hébergement, la base de données ou l’absence de cache.

📌 Étape 3 : localiser la source du ralentissement#

C’est le cœur du diagnostic. La lenteur vient presque toujours d’une ou plusieurs de ces 6 familles.

🌐 1. Le serveur et l’hébergement#

• Symptôme : TTFB supérieur à 0,8 s, même sur des pages simples. Lenteur aux heures de pointe.
• Causes fréquentes : hébergement mutualisé saturé (vous partagez la machine avec des centaines de sites), version de PHP obsolète, OPcache désactivé. L’OPcache, c’est le serveur qui garde en mémoire le code déjà « traduit » au lieu de le retraduire à chaque visite ; la documentation PrestaShop comme celle de WordPress recommandent de l’activer.
• Comment vérifier : TTFB dans PageSpeed Insights ; version de PHP dans le panneau de votre hébergeur. En septembre 2026, PHP 8.1 et les versions antérieures ne sont plus maintenues, et PHP 8.2 ne reçoit plus que des correctifs de sécurité jusqu’au 31 décembre 2026.
• Qui corrige : vous (version PHP, si le CMS est compatible) ou votre hébergeur / développeur.

🖼️ 2. Les images#

• Symptôme : LCP élevé, page lourde, photo principale qui apparaît en dernier.
• Causes fréquentes : photos de 4 000 pixels affichées dans un cadre de 800 ; images non compressées ; anciens formats (JPEG, PNG) au lieu de WebP ou AVIF, des formats modernes qui pèsent souvent nettement moins lourd à qualité égale ; absence de lazy loading (chargement différé : on ne charge les images du bas de page que lorsque le visiteur fait défiler). Attention au piège inverse : il ne faut pas différer l’image principale du haut de page, sinon le LCP empire.
• Comment vérifier : diagnostics « images » de PageSpeed Insights, poids des fichiers dans WebPageTest.
• Qui corrige : vous, pour les nouvelles images ; un développeur pour convertir automatiquement tout le catalogue.

📌 3. Les scripts tiers : la cause la plus souvent ignorée#

Un script tiers est un petit programme hébergé chez quelqu’un d’autre, que votre site appelle à chaque visite : Google Tag Manager, pixel Meta, chat en ligne, bandeau cookies, avis clients, carte Google Maps, police Google Fonts, outil d’A/B test… Chacun est un invité de plus à votre dîner.

• Symptôme : INP mauvais (le site « fige » au clic), LCP dégradé alors que le serveur répond vite.
• Causes fréquentes : tags de campagnes jamais retirés, chat chargé partout, outils en doublon.
• Comment vérifier : dans WebPageTest, la cascade de chargement (waterfall) montre les fichiers venant d’autres domaines que le vôtre. PageSpeed Insights les liste aussi dans ses diagnostics sur le code tiers.
• Qui corrige : vous, en grande partie (dans Google Tag Manager ou les réglages des applications) ; un développeur pour différer proprement ceux qui restent.

📌 4. Le thème et les extensions#

• Symptôme : toutes les pages sont lentes, y compris les plus simples. Beaucoup de fichiers CSS et JavaScript chargés.
• Causes fréquentes : constructeurs de pages (page builders) lourds, thèmes « tout-en-un », modules installés pour un test puis oubliés. La documentation PrestaShop le résume : certains modules peuvent ralentir votre boutique, surtout s’ils interviennent sur des pages clés du site.
• Comment vérifier : listez vos extensions actives et demandez-vous pour chacune : « À quoi sert-elle aujourd’hui ? »
• Qui corrige : vous, pour supprimer l’inutile (après une sauvegarde) ; un développeur pour alléger le thème.

📊 5. La base de données et le cache applicatif#

La base de données est l’entrepôt où sont rangés vos produits, clients, commandes. Chaque page va y chercher des informations : ce sont des requêtes. Le cache applicatif, c’est une préparation à l’avance : au lieu d’aller à l’entrepôt à chaque visite, le site garde sous la main les réponses les plus demandées.

• Symptôme : TTFB élevé surtout sur les pages de catégorie, la recherche ou le panier. Lenteur qui s’aggrave à mesure que le catalogue grossit.
• Causes fréquentes : cache désactivé, gros catalogue avec de nombreuses déclinaisons, tables gonflées.
• Comment vérifier : comparez le TTFB d’une page simple (mentions légales) et d’une page catégorie. Si l’écart est grand, c’est probablement ici.
• Qui corrige : un développeur. Pour aller plus loin : cache Memcache et Redis, pourquoi cocher la case ne suffit pas.

📌 6. Le front-end#

Le front-end, c’est tout ce que le navigateur doit télécharger et assembler : feuilles de style (CSS), scripts (JavaScript), polices.

• Symptôme : page blanche un moment, puis affichage d’un coup.
• Causes fréquentes : fichiers non minifiés (la minification retire les espaces et commentaires inutiles, comme on enlève l’emballage avant de ranger les courses) ; trop de petits fichiers ; polices « bloquantes », qui empêchent l’affichage du texte tant qu’elles ne sont pas chargées ; pas de CDN (un réseau de serveurs répartis dans le monde, qui livre vos fichiers depuis le point le plus proche du visiteur).
• Comment vérifier : PageSpeed Insights signale les ressources qui bloquent l’affichage.
• Qui corrige : un développeur, même si certains CMS proposent des options simples (voir plus bas).

📌 Étape 4 : ce que vous pouvez corriger vous-même cette semaine#

Classées du meilleur rapport gain / effort au moins bon. Faites une sauvegarde avant chaque changement, et refaites le test PageSpeed après chaque action : vous saurez ce qui a vraiment fonctionné.

1. Compressez les images les plus visibles (bannière d’accueil, visuels des catégories). Redimensionnez-les à leur taille d’affichage réelle et exportez-les en WebP. Gain élevé, effort faible. Voir aussi notre article sur les images optimisées et le serveur performant.
2. Faites le ménage dans vos tags marketing. Ouvrez Google Tag Manager : chaque balise liée à une campagne terminée, un outil résilié ou un doublon peut être mise en pause. Gain élevé, effort faible.
3. Désactivez puis supprimez les extensions inutilisées.Gain moyen à élevé, effort faible.
4. Activez le cache fourni par votre hébergeur ou votre CMS. Beaucoup d’hébergeurs proposent un cache serveur activable en un clic. WordPress le décrit comme le levier offrant le plus de bénéfice pour le moins d’effort. Gain élevé, effort faible.
5. Passez à une version de PHP récente (8.3 ou supérieure), depuis le panneau de votre hébergeur, après avoir vérifié que votre CMS, votre thème et vos modules sont compatibles. Au moindre doute, faites-le d’abord sur une copie du site. Gain moyen, effort faible à moyen.
6. Limitez les éléments lourds en haut de page : carrousel de 6 images, vidéo en lecture automatique, flux Instagram. Gain moyen, effort faible.

📌 Étape 5 : ce qui demande un développeur (et comment le briefer)#

Certaines corrections touchent au code ou au serveur : optimiser les requêtes de la base de données, mettre en place un cache objet (Redis ou Memcached), convertir automatiquement les images, différer les scripts tiers, alléger le thème, activer l’OPcache, mettre en place un CDN.

Vous n’avez pas besoin de savoir le faire. Vous avez besoin de bien le demander. Un brief précis, avec des chiffres, évite les allers-retours et permet de vérifier le résultat.

📌 ✉️ Copiez-collez ce message à votre prestataire#

Bonjour,

Nous avons mesuré les performances du site avec PageSpeed Insights (données de terrain, mobile) le [date] :

• Page d’accueil : LCP [x] s, INP [x] ms, CLS [x]
• Page [produit / service] ([URL]) : LCP [x] s, INP [x] ms, CLS [x]
• TTFB constaté : [x] s

L’objectif est de passer ces pages dans le vert des Core Web Vitals : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, TTFB ≤ 0,8 s.

Pourriez-vous nous transmettre :

1. votre diagnostic des principales causes (serveur, images, scripts tiers, thème / modules, base de données, front-end) ;
2. les actions proposées, classées par gain attendu ;
3. une estimation du temps nécessaire pour chacune ;
4. les mesures avant / après une fois les corrections faites.

Nous avons déjà [compressé les images d’accueil / supprimé X extensions / nettoyé les tags], pour info.

Merci d’avance,

Un bon prestataire appréciera : il a un point de départ clair et un critère de réussite mesurable.

📌 Les fausses bonnes idées#

Viser 100/100 sur PageSpeed. La documentation de Google le dit elle-même : un score parfait de 100 est extrêmement difficile à atteindre et n’est pas attendu. Cette note est un test de laboratoire. Ce qui compte, ce sont vos 3 indicateurs de terrain dans le vert.

Acheter le plugin de cache « miracle ». Un cache aide, mais il ne compensera ni des images de 3 Mo, ni quinze scripts tiers, ni un serveur saturé. Mal configuré, il peut même casser le panier. Diagnostiquez d’abord.

Changer d’hébergeur avant d’avoir diagnostiqué. Si la lenteur vient des scripts tiers ou des images, vous paierez une migration pour un gain quasi nul. Changez d’hébergeur si le TTFB reste élevé une fois le cache activé et PHP à jour. Si vous en êtes là, notre comparatif o2switch vs Hostinger vous aidera à choisir.

Supprimer Google Analytics « parce qu’il ralentit tout ». Le tag Google standard se charge en arrière-plan (de façon « asynchrone »), sans bloquer l’affichage de la page. Le vrai problème vient plutôt de l’accumulation de tags autour de lui. Le supprimer vous privera de mesures, sans résoudre la lenteur.

🛒 Cas particuliers e-commerce#

🛒 PrestaShop#

Les points de lenteur typiques : mode debug laissé actif en production, modules accumulés, catalogue avec de nombreuses déclinaisons, cache mal configuré. La documentation officielle recommande notamment de désactiver le mode développeur en production, d’activer l’OPcache et le cache Smarty, et d’auditer les modules. Dans le back-office, le menu Paramètres avancés > Performances regroupe l’essentiel des réglages (documentation PrestaShop 8).

🛒 Shopify#

L’hébergement est géré par Shopify : le serveur est rarement le coupable. Shopify cite lui-même le code du thème, les applications, les images, vidéos, carrousels, flux de réseaux sociaux et intégrations analytiques comme facteurs de performance. Piège classique : une application désinstallée qui a laissé du code dans le thème.

🛒 WooCommerce#

WooCommerce hérite des faiblesses de WordPress (extensions nombreuses, thèmes lourds). Spécificité : la table des options. WooCommerce explique que trop de données « chargées automatiquement » sont lues à chaque page et ralentissent le site. Le guide officiel de performance WooCommerce insiste sur le cache, les images, la base de données et le CDN.

📌 Tableau récapitulatif#

📌 Checklist finale#

• ☐ J’ai testé l’accueil et une page produit/service dans PageSpeed Insights, en mobile
• ☐ J’ai noté LCP, INP, CLS (données de terrain) et le TTFB
• ☐ J’ai ouvert le rapport « Signaux Web essentiels » de la Search Console
• ☐ J’ai identifié la ou les familles de causes probables
• ☐ J’ai compressé et redimensionné les images principales
• ☐ J’ai nettoyé les tags morts dans Google Tag Manager
• ☐ J’ai supprimé les extensions inutilisées (après sauvegarde)
• ☐ J’ai activé le cache proposé par mon hébergeur ou mon CMS
• ☐ J’ai vérifié ma version de PHP (et sa compatibilité)
• ☐ J’ai envoyé le message type à mon prestataire, avec mes mesures
• ☐ Je referai la mesure dans 28 jours, le temps que les données de terrain se mettent à jour

📌 FAQ#

📌 Quel temps de chargement viser ?#

Plutôt qu’un « temps de chargement » global, visez les seuils de Google pour 75 % de vos visiteurs : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Côté serveur, un TTFB ≤ 0,8 s.

📈 Un site lent est-il pénalisé par Google ?#

Les Core Web Vitals font partie des signaux de classement, mais la pertinence du contenu reste prioritaire. Un site lent perd surtout des visiteurs et des ventes, avant de perdre des positions.

📌 Faut-il changer d’hébergeur ?#

Seulement si le TTFB reste élevé une fois le cache activé, PHP à jour et les extensions allégées. Sinon, le problème est ailleurs et la migration ne le réglera pas.

📌 Le score PageSpeed doit-il être à 100 ?#

Non. Google indique qu’un score parfait n’est pas attendu. L’objectif, ce sont les trois Core Web Vitals au vert dans les données de terrain.

📌 Pourquoi mon site est lent sur mobile mais pas sur ordinateur ?#

Un téléphone a un processeur moins puissant et une connexion souvent moins stable. Le même site, avec les mêmes images et scripts, y met donc plus de temps. C’est aussi le mobile que Google évalue en priorité.

⚡ Combien coûte une optimisation de performance ?#

Cela dépend des causes trouvées. Nettoyer tags et images peut se faire en interne, quasi gratuitement. Un travail sur le serveur, la base de données ou le thème se chiffre après diagnostic. D’où l’intérêt de commencer par un audit.

✅ Conclusion#

Un site lent n’est ni une fatalité, ni le signe que quelqu’un a mal travaillé : les sites vivent, et le poids s’accumule. La méthode est toujours la même : mesurer sur le terrain, lire les trois indicateurs, localiser la cause, corriger ce qui est à votre portée, puis briefer précisément pour le reste.

Si vous souhaitez un regard extérieur, l’équipe Websource, basée à Aix-en-Provence, réalise des audits de performance sur les sites Symfony, PrestaShop et Shopify : diagnostic clair, actions priorisées, mesures avant / après. Parlons de votre site.

📌 Sources#

Consultées le 18 septembre 2026.

• web.dev – Web Vitals
• web.dev – Interaction to Next Paint is officially a Core Web Vital (2024)
• web.dev – Time to First Byte (TTFB)
• web.dev – Optimize Cumulative Layout Shift
• web.dev – Optimize Largest Contentful Paint
• web.dev – Browser-level image lazy loading for the web
• web.dev – Why lab and field data can be different
• web.dev – Milliseconds make millions (Deloitte / 55 pour Google, 2020)
• Google Search Central – Understanding page experience in Google Search results
• Google Search Central – Understanding Core Web Vitals and Google search results
• Aide Search Console – Rapport Signaux Web essentiels
• Google – About PageSpeed Insights
• Chrome for Developers – Lighthouse performance scoring
• PHP – Supported Versions
• PrestaShop Developer Documentation – Optimize your PrestaShop performance
• PrestaShop 8 – Performance
• Shopify Help Center – Performances web de la boutique en ligne
• WordPress Developer Resources – Optimization
• WooCommerce – WP_options table and site speed
• WooCommerce Developer Docs – How to optimize performance for WooCommerce stores