Pour am\u00e9liorer la vitesse de son site, mesurez d’abord vos Core Web Vitals. Corrigez ensuite, par ordre d’impact, les images, le cache, le code et l’h\u00e9bergement. L’objectif\u00a0: un LCP de 2,5 secondes maximum, un INP sous 200 millisecondes et un CLS sous 0,1.
\nCe guide pr\u00e9sente les seuils \u00e0 viser, les outils de test et la lecture d’un rapport PageSpeed Insights. Il d\u00e9taille aussi les causes d’un site lent, les priorit\u00e9s \u00e0 retenir et les 10 actions \u00e0 mettre en place pour am\u00e9liorer la vitesse de son site.<\/p>\n
Vous trouverez \u00e9galement des conseils pour WordPress, des solutions gratuites, le lien entre vitesse et SEO, les erreurs \u00e0 \u00e9viter et le suivi des performances du site.<\/p>\n
Pour am\u00e9liorer la vitesse de son site, visez un contenu principal affich\u00e9 en 2,5 secondes ou moins, une r\u00e9action aux clics en moins de 200 millisecondes et une page stable \u00e0 l’\u00e9cran. Google mesure ces trois crit\u00e8res avec les Core Web Vitals<\/a>. Une page est jug\u00e9e bonne quand au moins 75\u00a0% de ses visites atteignent ces seuils.<\/p>\n
M\u00e9trique<\/strong><\/th>\n| Ce qu’elle mesure<\/strong><\/th>\n | Bon<\/strong><\/th>\n | \u00c0 am\u00e9liorer<\/strong><\/th>\n | Mauvais<\/strong><\/th>\n<\/tr>\n<\/thead>\n\n | LCP<\/strong><\/td>\n | Affichage du plus grand \u00e9l\u00e9ment visible<\/td>\n | \u2264 2,5\u00a0s<\/td>\n | 2,5 \u00e0 4\u00a0s<\/td>\n | > 4\u00a0s<\/td>\n<\/tr>\n | INP<\/strong><\/td>\n | R\u00e9action de la page aux interactions<\/td>\n | \u2264 200\u00a0ms<\/td>\n | 200 \u00e0 500\u00a0ms<\/td>\n | > 500\u00a0ms<\/td>\n<\/tr>\n | CLS<\/strong><\/td>\n | Stabilit\u00e9 visuelle de la mise en page<\/td>\n | \u2264 0,1<\/td>\n | 0,1 \u00e0 0,25<\/td>\n | > 0,25<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n | Source\u00a0: web.dev, \u00ab\u00a0Web Vitals\u00a0\u00bb et \u00ab\u00a0How the Core Web Vitals metrics thresholds were defined\u00a0\u00bb.<\/em><\/p>\n Le LCP correspond au temps d’affichage du plus grand \u00e9l\u00e9ment visible, souvent l’image principale ou un titre. L’INP mesure ensuite le d\u00e9lai entre un clic, un toucher ou une frappe et la r\u00e9action visible de la page. Quant au CLS, il additionne les d\u00e9calages inattendus de la mise en page.<\/p>\n L’ancien FID n’est plus un Core Web Vital, car il a \u00e9t\u00e9 remplac\u00e9 par l’INP. Les guides qui le pr\u00e9sentent encore comme un indicateur actuel ne sont donc plus \u00e0 jour.<\/p>\n \u00c0 savoir\u00a0: le TTFB :<\/strong> Le TTFB (temps de r\u00e9ponse du serveur) n’est pas un Core Web Vital. Il retarde pourtant le LCP, puisque rien ne s’affiche avant la premi\u00e8re r\u00e9ponse du serveur. Google recommande donc de viser 0,8 seconde ou moins (source\u00a0: web.dev, \u00ab\u00a0Time to First Byte\u00a0\u00bb).<\/p><\/blockquote>\n Avant d’am\u00e9liorer la vitesse de son site, il faut la mesurer. Pour tester votre site, collez d’abord l’adresse d’une page dans PageSpeed Insights, un outil de test gratuit de Google. Ouvrez ensuite le rapport Core Web Vitals de la Search Console. Le premier outil donne ainsi un diagnostic page par page. Quant au second, il classe les URL du site en bonnes, \u00e0 am\u00e9liorer ou mauvaises.<\/p>\n Lancez en priorit\u00e9 un test de vitesse sur la version mobile, car les t\u00e9l\u00e9phones ont des processeurs et des connexions plus lents qu’un ordinateur. Ajoutez \u00e0 ce test les pages qui rapportent du trafic ou des contacts, comme vos pages de service ou vos fiches produit.<\/p>\n Sources\u00a0: Google, \u00ab\u00a0\u00c0 propos de PageSpeed Insights\u00a0\u00bb\u00a0; web.dev, \u00ab\u00a0Tools to measure Core Web Vitals\u00a0\u00bb.<\/em><\/p>\n Commencez par le bloc des donn\u00e9es r\u00e9elles, en haut du rapport, puis consultez le diagnostic Lighthouse. Ce sont surtout les donn\u00e9es r\u00e9elles qui d\u00e9terminent si vos Core Web Vitals sont bons. Le score sur 100 aide surtout \u00e0 rep\u00e9rer les pistes de correction.<\/p>\n Sources\u00a0: Google, \u00ab\u00a0\u00c0 propos de PageSpeed Insights\u00a0\u00bb\u00a0; web.dev, \u00ab\u00a0Why lab and field data can be different\u00a0\u00bb.<\/em><\/p>\n Signal d’alerte\u00a0: le score vert qui trompe :<\/strong> Un score vert en laboratoire peut coexister avec des Core Web Vitals rouges sur le terrain. Vos visiteurs utilisent par exemple des appareils, des r\u00e9seaux et des interactions que la simulation ne reproduit pas. Corrigez donc ce que r\u00e9v\u00e8lent les donn\u00e9es r\u00e9elles avant de viser un score parfait.<\/p><\/blockquote>\n Pour am\u00e9liorer la vitesse de son site, partez de l’indicateur en rouge afin de trouver la cause. Un LCP lent peut ainsi venir d’un serveur qui r\u00e9pond tard ou d’images lourdes. L’INP augmente avec un JavaScript trop charg\u00e9, tandis que le CLS grimpe lorsque des \u00e9l\u00e9ments n’ont pas d’espace r\u00e9serv\u00e9.<\/p>\n Source\u00a0: web.dev, guides \u00ab\u00a0Optimize LCP\u00a0\u00bb, \u00ab\u00a0Optimize INP\u00a0\u00bb et \u00ab\u00a0Cumulative Layout Shift\u00a0\u00bb.<\/em><\/p>\n Diagnostic express :<\/strong> LCP lent\u00a0? Regardez les images et le serveur. INP lent\u00a0? All\u00e9gez le JavaScript. CLS \u00e9lev\u00e9\u00a0? R\u00e9servez l’espace des \u00e9l\u00e9ments dynamiques.<\/p><\/blockquote>\n Pour isoler la cause, proc\u00e9dez par \u00e9limination.<\/p>\n Commencez par les pages qui rapportent le plus de trafic ou de contacts, en visant d’abord l’indicateur class\u00e9 \u00ab\u00a0mauvais\u00a0\u00bb dans la Search Console. Les optimisations \u00e0 fort impact et \u00e0 faible effort passent donc avant les chantiers lourds.<\/p>\n Le tableau classe ensuite les 10 actions pr\u00e9sent\u00e9es plus bas. L’impact et l’effort restent des estimations g\u00e9n\u00e9rales, car ils varient selon votre site.<\/p>\n Classement indicatif, \u00e0 ajuster selon vos propres tests.<\/em><\/p>\n Ces 10 actions ciblent les causes de lenteur les plus courantes. Voici comment les appliquer.<\/p>\n Compressez chaque image, convertissez-la en WebP ou en AVIF et adaptez ses dimensions \u00e0 l’affichage. Le poids des images, surtout celui de l’image principale, retarde souvent le LCP.<\/p>\n Source\u00a0: web.dev, guides \u00ab\u00a0Optimize LCP\u00a0\u00bb et \u00ab\u00a0Fetch Priority API\u00a0\u00bb.<\/em><\/p>\n Activez le cache navigateur en fixant une dur\u00e9e de conservation pour les fichiers statiques, puis le cache serveur pour les pages g\u00e9n\u00e9r\u00e9es. Un visiteur qui revient t\u00e9l\u00e9charge alors beaucoup moins de fichiers.<\/p>\n Source\u00a0: web.dev, \u00ab\u00a0Prevent unnecessary network requests with the HTTP Cache\u00a0\u00bb.<\/em><\/p>\n La minification retire les espaces, les commentaires et les caract\u00e8res superflus des fichiers CSS et JavaScript sans modifier leur comportement. Les fichiers sont alors plus l\u00e9gers et plus rapides \u00e0 t\u00e9l\u00e9charger et \u00e0 analyser. Le temps de chargement des pages diminue donc.<\/p>\n Listez chaque plugin et chaque ressource externe, puis supprimez ceux qui ne servent pas ou qui font double emploi. Les pixels publicitaires, les widgets de chat et les cartes int\u00e9gr\u00e9es alourdissent le JavaScript \u00e0 ex\u00e9cuter, ce qui p\u00e9nalise surtout l’INP.<\/p>\n Source\u00a0: web.dev, \u00ab\u00a0Optimize INP\u00a0\u00bb.<\/em><\/p>\n Ce service est particuli\u00e8rement utile lorsque vos visiteurs sont \u00e9loign\u00e9s de votre serveur. Il stocke pour cela des copies de vos fichiers sur des serveurs r\u00e9partis dans le monde et les livre depuis le point le plus proche. En revanche, il ne compense ni un h\u00e9bergement satur\u00e9 ni des images trop lourdes.<\/p>\n Choisissez un h\u00e9bergement web dont le serveur r\u00e9pond en 0,8 seconde ou moins, avec un cache serveur et des ressources adapt\u00e9es \u00e0 votre trafic. Selon web.dev, l’h\u00e9bergement est le premier point \u00e0 examiner quand le TTFB est \u00e9lev\u00e9.<\/p>\n Le co\u00fbt de l’h\u00e9bergement fait partie du budget d’un site internet<\/a>, \u00e0 pr\u00e9voir d\u00e8s le d\u00e9part. Pour acc\u00e9l\u00e9rer le chargement, affichez d’abord ce qui appara\u00eet \u00e0 l’\u00e9cran et diff\u00e9rez le reste. Le chargement diff\u00e9r\u00e9 (lazy loading) s’applique aux images et aux iframes situ\u00e9es sous la ligne de flottaison, jamais \u00e0 l’image principale.<\/p>\n Supprimez les donn\u00e9es qui s’accumulent sans servir, comme les r\u00e9visions d’articles, les commentaires ind\u00e9sirables et les tables de plugins d\u00e9sinstall\u00e9s. Une base all\u00e9g\u00e9e r\u00e9pond alors plus vite, ce qui aide le TTFB et le chargement du site.<\/p>\n Une redirection ajoute un aller-retour r\u00e9seau avant l’affichage de la page. Chaque fichier suppl\u00e9mentaire ajoute aussi une requ\u00eate. Supprimez donc les redirections en cha\u00eene et r\u00e9duisez le nombre de requ\u00eates en retirant les fichiers qui ne servent pas.<\/p>\n Pour am\u00e9liorer la vitesse de son site sur smartphone, testez d’abord la version mobile, car les t\u00e9l\u00e9phones ont des processeurs et des connexions plus lents qu’un ordinateur. Misez ensuite sur un design responsive l\u00e9ger, avec des images adapt\u00e9es \u00e0 l’\u00e9cran, moins de JavaScript et des \u00e9l\u00e9ments stables au toucher.<\/p>\n Votre site est-il trop lent ?<\/p> On mesure vos Core Web Vitals sur vos pages cl\u00e9s, puis on vous dit quoi corriger en premier. L'audit est gratuit et sans engagement.<\/p>Demander mon audit gratuit |
|---|