La plupart des guides sur les Core Web Vitals vous donnent 12 choses à corriger. C’est accablant. Vous ne ferez pas les 12. Vous n’en ferez aucune.
Voici ce qui fonctionne vraiment. Corrigez trois choses. Obtenez 80% du résultat. Passez à la suite de votre vie.
Ce que vous allez apprendre
Ce guide vous montre comment prioriser les correctifs des Core Web Vitals sans perdre de temps. Vous apprendrez quelles métriques importent le plus pour votre type de site. Vous apprendrez les trois correctifs qui font la différence. Vous apprendrez comment mesurer les résultats en environ 15 minutes.
Ce n’est pas de la théorie. C’est ce qui fonctionne pour les petites entreprises et les agences qui n’ont pas d’ingénieur de performance à temps plein.
101 : Pourquoi les Core Web Vitals importent vraiment
Les Core Web Vitals mesurent la vitesse de chargement de votre site et la stabilité qu’il procure. Google les utilise comme facteur de classement. Plus important encore, les sites lents perdent des clients.
Il y a trois métriques :
Largest Contentful Paint (LCP) mesure la vitesse de chargement. Il suit le temps nécessaire pour que le contenu principal apparaisse. Bon est inférieur à 2,5 secondes. La plupart des petits sites commerciaux atteignent 3,5 à 4,5 secondes.
Interaction to Next Paint (INP) mesure la réactivité. Il suit la rapidité avec laquelle votre site réagit quand quelqu’un clique ou appuie. Bon est inférieur à 200 millisecondes. Les sites chargés en JavaScript atteignent souvent 400 à 600 millisecondes.
Cumulative Layout Shift (CLS) mesure la stabilité visuelle. Il suit le saut de votre page pendant le chargement. Bon est inférieur à 0,1. Les sites avec des annonces ou des images chargées paresseusement atteignent souvent 0,3 ou plus.
La plupart des sites échouent au moins l’un de ces éléments. Le site commercial moyen en échoue deux.
Une recherche de HubSpot en 2024 a révélé que 75% des utilisateurs ne font jamais défiler au-delà de la première page des résultats de recherche. Les Core Web Vitals sont un bris d’égalité quand la qualité du contenu est égale. Si votre concurrent a le même contenu mais charge plus rapidement, il se classera plus haut.
Le problème avec les conseils actuels
Cherchez l’optimisation des Core Web Vitals. Vous trouverez des guides complets. Ils listent 12 à 15 tactiques. Ils couvrent tous les cas limites.
Ils sont corrects. Ils sont aussi inutiles.
Un propriétaire de taqueria n’a pas le temps de mettre en œuvre 15 optimisations de performance. Une agence gérant 30 sites clients ne peut pas auditer manuellement chaque fichier JavaScript.
Les guides complets manquent le point. Vous devez savoir quoi corriger en premier. Vous devez savoir ce qui change vraiment vos chiffres.
Les outils SEO traditionnels aggravent les choses. Ils vous donnent des vidages de données. Vous obtenez 100 problèmes sans priorité. Vous obtenez du jargon technique sans contexte. Vous passez des heures à essayer de comprendre quel problème compte.
Lighthouse vous donne un score de performance. Il ne vous dit pas s’il faut corriger vos images ou votre JavaScript en premier. PageSpeed Insights vous montre ce qui est lent. Il ne vous dit pas quel correctif vous fera passer du statut d’échec au statut de réussite.
201 : Les trois correctifs qui fonctionnent vraiment
Correctif 1 : Optimisez votre élément Largest Contentful Paint
LCP est presque toujours votre plus gros problème. C’est aussi le plus facile à corriger.
Votre élément LCP est généralement votre image de héros ou votre titre principal. La plupart des sites chargent ceci lentement parce que l’image est énorme et non compressée.
Site Audit l’a détecté sur notre propre site. Nous avions une image de héros de 2,4 Mo qui s’affichait seulement à 1200 pixels de large. L’image a été prise à 4000 pixels. Ces pixels supplémentaires n’ont fait que nous ralentir.
Voici ce qu’il faut faire :
Convertissez votre image de héros au format WebP. Les fichiers WebP sont 30% plus petits que JPEG avec la même qualité. Vous pouvez utiliser des outils gratuits comme Squoosh ou CloudConvert. Les navigateurs modernes supportent WebP. Safari a ajouté le support en 2020. Edge a ajouté le support en 2018.
Voici le HTML :
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Your hero image" width="1200" height="800">
</picture>Le navigateur charge WebP s’il est supporté. Il revient à JPEG pour les anciens navigateurs.
Redimensionnez l’image pour correspondre à sa taille d’affichage réelle. Si votre image de héros s’affiche à 1200 pixels de large, ne téléchargez pas une image de 4000 pixels. Utilisez 1200 pixels pour le bureau. Utilisez 800 pixels pour mobile. Servez différentes tailles selon la largeur de l’écran.
Voici le code :
<img
src="hero-1200.webp"
srcset="hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 800px, 1200px"
alt="Your hero image"
width="1200"
height="800"
>Ajoutez les attributs width et height à votre balise d’image. Cela indique au navigateur l’espace à réserver. Cela empêche le décalage de disposition pendant le chargement de l’image. Les navigateurs modernes utilisent ceux-ci pour calculer automatiquement le rapport d’aspect.
Utilisez un Content Delivery Network (CDN). Les CDN servent vos images à partir de serveurs proches de vos visiteurs. CloudFlare et BunnyCDN ont tous deux des niveaux gratuits. Un CDN réduit généralement le temps de chargement des images de 40% à 60%.
Ajoutez fetchpriority=“high” à votre image LCP. Cela indique au navigateur de charger cette image avant d’autres ressources. C’est un indice, pas une commande. Les navigateurs le respectent quand ils le peuvent.
<img
src="hero.webp"
alt="Your hero image"
width="1200"
height="800"
fetchpriority="high"
>Ce correctif seul peut réduire votre LCP de 4 secondes à 2 secondes. C’est la différence entre un score de réussite et d’échec.
Erreurs courantes avec l’optimisation LCP :
Ne chargez pas paresseusement votre élément LCP. Le chargement paresseux indique au navigateur d’attendre. Votre élément LCP devrait charger immédiatement.
Ne mettez pas votre élément LCP en bas de l’écran. LCP mesure le plus grand contenu visible. Si votre héros est minuscule et que votre contenu principal se trouve plus bas, optimisez le contenu qui s’affiche réellement en premier.
Ne compressez pas les images trop agressivement. WebP à 80% de qualité va bien. WebP à 40% de qualité a l’air terrible. Les utilisateurs remarquent les baisses de qualité. Trouvez l’équilibre.
Correctif 2 : Reportez le JavaScript non critique
JavaScript bloque le rendu. Le navigateur doit télécharger, analyser et exécuter chaque script avant d’afficher votre page. La plupart de ce JavaScript ne fait rien au chargement initial.
Le site commercial moyen charge 8 à 12 fichiers JavaScript au chargement. La plupart de ces fichiers alimentent des fonctionnalités en bas de l’écran. Ils n’ont pas besoin de charger en premier.
Voici ce qu’il faut faire :
Ajoutez l’attribut defer à vos balises de script. Cela indique au navigateur de télécharger le script en arrière-plan et de l’exécuter après le chargement de la page.
<!-- Before: blocks rendering -->
<script src="analytics.js"></script>
<!-- After: loads in background -->
<script src="analytics.js" defer></script>L’attribut defer maintient l’ordre d’exécution du script. Si le script B dépend du script A, ils s’exécutent toujours dans l’ordre. Ils ne font que ne pas bloquer le rendu.
Déplacez les scripts d’analyse et de suivi en bas de votre page. Google Analytics n’a pas besoin de charger avant que votre contenu apparaisse. Pas plus que Facebook Pixel. Pas plus que votre widget de chat en direct.
Mettez ces scripts juste avant la balise fermante </body>. Ils se chargent après tout le reste.
Supprimez complètement le JavaScript inutilisé. La plupart des sites WordPress chargent jQuery pour des fonctionnalités qu’ils n’utilisent pas. Beaucoup de thèmes chargent des bibliothèques d’animation qui alimentent un bouton.
Vérifiez quels scripts s’exécutent réellement au chargement de la page. Ouvrez Chrome DevTools. Allez à l’onglet Coverage. Actualisez votre page. Chrome vous montre combien de chaque fichier JavaScript s’exécute réellement.
Si un fichier est 80% inutilisé, vous n’en avez probablement pas besoin. Supprimez-le ou divisez-le en fichiers plus petits.
Utilisez async pour les scripts qui ne dépendent pas les uns des autres. L’attribut async télécharge les scripts en parallèle et les exécute dès qu’ils ont terminé le téléchargement. Utilisez async pour les scripts indépendants comme l’analyse.
<script src="analytics.js" async></script>
<script src="chat-widget.js" async></script>N’utilisez pas async pour les scripts qui dépendent les uns des autres. Si le script B a besoin que le script A s’exécute en premier, utilisez defer à la place.
Ce correctif améliore généralement l’INP de 100 à 200 millisecondes. Cela accélère également LCP car le navigateur peut se concentrer sur le contenu au lieu des scripts.
Erreurs courantes avec l’optimisation JavaScript :
Ne reportez pas le JavaScript qui ajoute une fonctionnalité critique. Si votre navigation principale nécessite JavaScript pour fonctionner, ne la reportez pas. Les utilisateurs verront un menu brisé.
Ne déployez pas async aveuglément partout. Async change l’ordre d’exécution. Si vos scripts dépendent les uns des autres, async les cassera.
Ne supprimez pas le JavaScript sans tester. Supprimez un fichier à la fois. Vérifiez que tout fonctionne toujours. Passez ensuite au fichier suivant.
Correctif 3 : Spécifiez les dimensions des images et des éléments
Le décalage de disposition se produit quand les éléments se chargent sans tailles définies. Le navigateur devine l’espace à réserver. Le navigateur se trompe. Votre page saute partout.
C’est le problème des Core Web Vitals le plus ennuyeux pour les utilisateurs. Le contenu se déplace pendant qu’ils lisent. Ils cliquent sur un lien. La page saute. Ils cliquent sur la mauvaise chose.
Voici ce qu’il faut faire :
Ajoutez des attributs width et height explicites à chaque image. Les navigateurs modernes utilisent ceux-ci pour calculer le rapport d’aspect et réserver de l’espace.
<!-- Before: no dimensions, causes layout shift -->
<img src="product.jpg" alt="Product photo">
<!-- After: browser reserves correct space -->
<img src="product.jpg" alt="Product photo" width="600" height="400">Vous n’avez pas besoin de correspondre exactement à la taille d’affichage. Le navigateur met à l’échelle proportionnellement. Vous devez juste lui donner le rapport d’aspect correct.
Définissez les dimensions des annonces et des intégrations avant qu’elles ne se chargent. Si vous exécutez Google Ads, réservez les dimensions exactes en pixels dans votre CSS. Si vous intégrez des vidéos YouTube, réservez l’espace 16:9 avant le chargement de l’intégration.
.ad-container {
width: 300px;
height: 250px;
background: #f0f0f0;
}Chargez les polices Web avec font-display swap. Cela affiche immédiatement les polices système et bascule vers votre police personnalisée quand elle est prête. Cela empêche le texte invisible et le reflux de disposition.
@font-face {
font-family: 'YourFont';
src: url('your-font.woff2') format('woff2');
font-display: swap;
}Le texte apparaît immédiatement dans une police de secours. Quand votre police personnalisée se charge, elle bascule. C’est mieux que d’attendre que la police se charge avant d’afficher du texte.
Évitez d’injecter du contenu au-dessus du contenu existant. Si vous chargez paresseusement des images ou des annonces, injectez-les en bas de l’écran où elles ne pousseront pas le contenu vers le bas.
Utilisez l’attribut loading="lazy" pour les images en bas de l’écran. Cela diffère le chargement jusqu’à ce que l’utilisateur se rapproche d’elles.
<img src="below-fold.jpg" alt="Image below fold" loading="lazy" width="800" height="600">Ce correctif peut réduire votre CLS de 0,3 à moins de 0,1. C’est la différence entre une note d’échec et un score parfait.
Erreurs courantes avec le décalage de disposition :
N’injectez pas de bannières promotionnelles en haut de la page après le chargement. Les utilisateurs détestent cela. Cela ruine leur expérience de lecture. Si vous devez afficher une bannière, réservez de l’espace pour elle dans votre HTML initial.
N’utilisez pas d’animations CSS qui modifient les dimensions des éléments. Les animations qui agrandissent ou réduisent les éléments causent un décalage de disposition. Utilisez plutôt les transformations. Les transformations n’affectent pas la disposition.
Ne chargez pas les polices sans solutions de secours. Si votre police personnalisée échoue à se charger, les utilisateurs devraient toujours voir du texte. Définissez une pile de polices de secours dans votre CSS.
Savoir ce qu’il faut corriger sur votre site
Les trois correctifs ci-dessus fonctionnent pour la plupart des sites. Mais votre site pourrait être différent.
Les sites de commerce électronique échouent généralement au LCP à cause des images de produits. Vous avez des dizaines de photos haute résolution. Ces photos font souvent 3 à 5 Mo chacune. Les compresser réduit de moitié le LCP.
Les sites SaaS échouent généralement à l’INP à cause de tableaux de bord chargés en JavaScript. Vous avez des frameworks, de la gestion d’état et des mises à jour en temps réel. Différer les scripts non critiques améliore la réactivité.
Les sites d’actualités échouent généralement au CLS à cause des annonces et du chargement paresseux. Vous injectez des annonces entre les paragraphes. Vous chargez paresseusement les images dans les articles. Les deux causent un décalage de disposition.
Vous devez savoir quelle métrique est votre maillon faible. Vous devez savoir quel correctif changera vos chiffres spécifiques.
301 : Pourquoi les outils traditionnels rateent la cible
PageSpeed Insights vous donne des scores. Lighthouse vous donne des opportunités. Ni l’un ni l’autre ne vous dit quoi corriger en premier.
Vous obtenez une liste de 20 problèmes. Chaque problème a une économie de temps potentielle. Le problème qui économise 2 secondes semble plus important que le problème qui économise 0,5 secondes.
Ces mathématiques sont trompeuses.
L’économie de 2 secondes pourrait nécessiter de réécrire votre architecture JavaScript entière. L’économie de 0,5 secondes pourrait nécessiter de compresser une seule image. L’une prend 40 heures. L’autre prend 5 minutes.
Les outils traditionnels ne tiennent pas compte de la difficulté de mise en œuvre. Ils ne vous disent pas quels correctifs vous font passer de l’échec au succès. Ils vidangent simplement les données et vous laissent comprendre.
Site Audit exécute un audit technique en environ 15 minutes. Forfaits à partir de 50 $ par rapport. Il vérifie les trois métriques Core Web Vitals. Il vous dit exactement quels éléments vous ralentissent. Il classe les correctifs par impact pour que vous sachiez quoi faire en premier.
Vous obtenez un rapport complet avec des projections avant et après. Vous obtenez les fichiers spécifiques et les numéros de ligne à modifier. Vous obtenez un fichier JSON si vous souhaitez automatiser les correctifs sur plusieurs sites.
La plupart des audits coûtent 500 $ et prennent trois jours. Site Audit coûte 50 $ et s’exécute pendant que vous prenez un café.
Comment Site Audit fonctionne réellement
Site Audit combine plusieurs outils de test dans un seul rapport classé par priorité.
Il exécute Google PageSpeed Insights pour les métriques de laboratoire. Il extrait les données Chrome UX Report pour les métriques des utilisateurs réels. Il exécute Pa11y pour les tests d’accessibilité. Il vérifie la compatibilité des navigateurs sur Chrome, Firefox, Safari et Edge.
Ensuite, il utilise l’IA pour synthétiser les résultats dans un plan d’action classé par priorité.
Vous n’obtenez pas 100 problèmes sans contexte. Vous obtenez 5 actions classées par priorité avec des estimations d’effort et des scores d’impact. Chaque action comprend le problème, l’impact sur votre entreprise, le correctif et le résultat attendu.
Site Audit offre deux portées : 30 pages ou 100 pages. La portée de 30 pages est parfaite pour les petits sites. Vous obtenez des audits principaux, 5 actions classées par priorité et des tests de navigateur.
La portée de 100 pages ajoute l’analyse des concurrents. Site Audit compare votre site avec jusqu’à 2 concurrents côte à côte. Vous voyez exactement où vous êtes en retard. Vous voyez les lacunes de mots-clés, la couverture du schéma et les références de performance.
La portée étendue comprend également l’analyse des lacunes de contenu. Site Audit identifie les sujets pour lesquels vos concurrents se classent mais pas vous. Vous obtenez une recherche alimentée par l’IA sur le prochain sujet à écrire.
Chiffres réels de vrais sites
Site Audit a détecté 4 problèmes légitimes sur surmado.com.
Nous manquions le schéma LocalBusiness. Ces données structurées génèrent 15% à 30% d’augmentation de la recherche locale. Nous l’avons ajouté. Le trafic local a augmenté de 18% en 30 jours.
Nous avions 3 en-têtes de sécurité manquants. Notre score de sécurité était de 2 sur 5. Nous avons ajouté Content-Security-Policy, X-Content-Type-Options et Strict-Transport-Security. Notre score a bondi à 5 sur 5.
Nous avions des goulots d’étranglement de Speed Index des polices non optimisées. Nous sommes passés au swap de font-display. Speed Index a chuté de 3,2 secondes à 2,1 secondes.
Lighthouse n’a pas détecté ces problèmes. Lighthouse teste un navigateur dans des conditions idéales. Site Audit teste 4 navigateurs avec les métriques des utilisateurs réels. Site Audit teste également les navigateurs in-app des réseaux sociaux dans la version Pro. Les navigateurs Instagram, Facebook et LinkedIn se comportent différemment des navigateurs standards.
30% à 50% du trafic provient des réseaux sociaux. Si votre site se casse dans le navigateur in-app d’Instagram, vous perdez ce trafic.
La comparaison d’outils dont vous avez vraiment besoin
Voici comment Site Audit se compare à d’autres options :
PageSpeed Insights est gratuit et vous donne des scores de laboratoire. Il ne classe pas les correctifs. Il ne vous compare pas aux concurrents. Il ne teste pas les navigateurs sociaux. Il vous donne des données. Vous trouvez la stratégie.
Lighthouse est gratuit et intégré à Chrome DevTools. Il nécessite une expertise technique. Vous devez savoir comment lire les graphiques en cascade. Vous devez comprendre les ressources qui bloquent le rendu. Il vous donne les opportunités. Vous trouvez lesquelles importent.
Semrush Site Audit coûte 1 400 $ par an. Il parcourt votre site entier et trouve tout ce qui ne va pas. Vous obtenez 100+ problèmes sans priorité. Vous obtenez des tableaux de bord pour surveiller les tendances. Vous passez des heures à essayer de comprendre quoi corriger en premier.
Screaming Frog coûte 199 $ par an. C’est un robot d’exploration de bureau. Il trouve les liens brisés, le contenu dupliqué et les problèmes de métadonnées. Il ne teste pas la performance. Il ne teste pas les métriques des utilisateurs réels. Il ne vous dit pas l’impact commercial.
Site Audit commence à 50 $/travail. Vous obtenez un plan d’action classé par priorité en environ 15 minutes. Vous obtenez 5 à 10 choses spécifiques à faire avec des estimations d’effort. Vous obtenez l’analyse des concurrents en Pro. Vous obtenez les métriques des utilisateurs réels du Chrome UX Report. Vous obtenez les tests de navigateur social en Pro.
Vous obtenez l’audit que vous écririez après avoir utilisé ces autres outils.
Site Audit est la couche stratégique. Les autres outils vous donnent des données. Site Audit vous dit quoi en faire.
Quand l’optimisation des Core Web Vitals échoue
Tous les sites ne bénéficient pas de l’optimisation des Core Web Vitals. Vous devez savoir quand cela compte et quand ce n’est pas le cas.
Si votre site se classe à la page 5 pour vos mots-clés cibles, les Core Web Vitals ne vous sauveront pas. La qualité du contenu et les liens retour importent plus. Corrigez ceux-ci en premier.
Si vos concurrents ont également de mauvais Core Web Vitals, optimiser les vôtres vous donne un avantage. Si vos concurrents ont des scores parfaits, égaler les leurs nivelle simplement le terrain de jeu.
Les Core Web Vitals sont un bris d’égalité. Ils importent le plus quand la qualité du contenu est égale et que vous concourrez pour les positions 1 à 5 à la page 1.
Les fils de discussion Reddit des praticiens du SEO technique confirment cela. Les sites avec des scores Core Web Vitals parfaits se classent parfois en dessous de sites avec des scores défaillants. Google considère des centaines de facteurs de classement. Les Core Web Vitals en sont un.
Ne gaspillez pas 40 heures à optimiser les Core Web Vitals si votre contenu est mince ou que votre site n’a pas de liens retour. Corrigez les fondamentaux en premier.
API et automatisation pour les agences
Si vous gérez plusieurs sites clients, vous avez besoin d’automatisation.
Site Audit comprend le support complet de l’API et des webhooks. Vous pouvez déclencher les audits par programmation. Vous obtenez la sortie JSON avec des données structurées. Vous pouvez créer des tableaux de bord ou automatiser les rapports.
L’API est basée sur REST avec une authentification simple. Vous envoyez une demande POST avec une URL. Site Audit s’exécute de manière asynchrone. Vous obtenez un webhook à la fin du rapport. Vous pouvez interroger le point de terminaison d’état si vous préférez.
La sortie JSON comprend toutes les métriques, les actions classées par priorité et les comparaisons concurrentes. Vous pouvez analyser cela dans vos propres systèmes. Vous pouvez générer des rapports personnalisés pour les clients. Vous pouvez suivre la progression au fil du temps.
Site Audit prend également en charge le mode clean-label sur Portfolio. Le nom de votre agence apparaît dans les rapports au lieu de Surmado. Vos clients voient votre marque.
La plupart des agences facturent 500 à 1 000 $ pour les audits SEO. Scout livre la même qualité en environ 15 minutes. Vous gardez la marge. Vos clients obtiennent des résultats rapides et actionnables.
Conseils spécifiques au framework
Vos correctifs dépendent de votre pile technologique.
Sites WordPress : Utilisez un plugin de mise en cache comme WP Rocket ou W3 Total Cache. Ces plugins gèrent l’optimisation des images, le report du JavaScript et l’intégration du CDN automatiquement. La plupart de la configuration prend 10 minutes.
Sites Shopify : Utilisez le chargement paresseux intégré pour les images de produits. Reportez les applications tierces qui ajoutent du JavaScript. La plupart des magasins Shopify chargent 8 à 12 scripts tiers. Auditez ceux que vous utilisez réellement.
Sites Next.js : Utilisez le composant Image intégré. Il gère le dimensionnement réactif, le chargement paresseux et la conversion de format automatiquement. Utilisez les importations dynamiques pour le JavaScript côté client. Cela diffère le code qui n’a pas besoin de s’exécuter sur le serveur.
Sites React : Utilisez React.lazy() pour le fractionnement du code. Cela divise votre JavaScript en petits morceaux qui se chargent à la demande. Utilisez l’API Intersection Observer pour le chargement paresseux en bas de l’écran.
Sites statiques : Prérendez tout au moment de la compilation. Utilisez un outil de compilation comme Eleventy ou Hugo. HTML statique se charge plus rapidement que le contenu rendu en JavaScript. Utilisez un CDN pour servir vos fichiers statiques mondialement.
Comment mesurer les résultats
Une fois que vous avez effectué les correctifs, vous devez vérifier qu’ils ont fonctionné.
Utilisez Google PageSpeed Insights. Entrez votre URL. Vérifiez vos scores Core Web Vitals. Comparez-les à votre ligne de base avant les correctifs.
Exécutez le test trois fois. Les scores fluctuent en fonction des conditions réseau et de la charge du serveur. Moyennez les résultats. Ne paniquez pas si un test montre des scores pires. Regardez la tendance sur plusieurs tests.
Vérifiez à la fois mobile et bureau. Google classe en fonction de la performance mobile. Les scores de bureau sont généralement plus élevés mais importent moins pour les classements.
Attendez 28 jours pour les données des utilisateurs réels. Chrome UX Report agrège les données sur une fenêtre de 28 jours. Vos scores de laboratoire s’améliorent immédiatement. Vos scores de terrain s’améliorent progressivement au fur et à mesure que les utilisateurs réels visitent votre site mis à jour.
Si vous souhaitez une surveillance continue, les forfaits Pro et Portfolio incluent une surveillance hebdomadaire. Vous voyez comment vos scores changent au fil du temps. Des travaux supplémentaires disponibles pour 25 $ quand vous avez besoin d’un regard plus approfondi.
Questions courantes
Combien de temps l’optimisation prend-elle ?
Les trois correctifs de ce guide prennent 1 à 3 heures au total pour la plupart des sites. L’optimisation des images prend 30 minutes. Le report du JavaScript prend 30 minutes. L’ajout de dimensions aux images prend 1 à 2 heures selon le nombre d’images que vous avez.
Ai-je besoin d’aide au développement ?
Pour les correctifs de base, non. La compression des images et l’ajout de dimensions peuvent être faits via votre CMS. Pour les modifications JavaScript, vous pourriez avoir besoin d’un développeur si votre site utilise un thème personnalisé ou un processus de compilation.
Cela va-t-il casser mon site ?
Non si vous testez les modifications dans un environnement d’évaluation d’abord. Faites un changement à la fois. Testez que tout fonctionne toujours. Puis passez au changement suivant. Ne poussez pas 10 modifications en production à la fois.
Combien d’amélioration du trafic puis-je attendre ?
Cela dépend de vos classements actuels. Si vous vous classez aux positions 4 à 7 à la page 1, améliorer les Core Web Vitals peut vous déplacer aux positions 2 à 4. Cela augmente généralement le trafic de 20% à 40%. Si vous vous classez à la page 2 ou 3, les Core Web Vitals seuls ne vous mèneront pas à la page 1. Concentrez-vous sur le contenu et les liens retour en premier.
Dois-je optimiser chaque page ?
Non. Commencez par vos pages à trafic élevé. Optimisez votre page d’accueil, vos 10 meilleures pages de destination et vos 10 meilleures pages de produit ou de service. Ces pages génèrent 80% de votre trafic. Corrigez-les en premier.
Et si j’utilise un générateur de pages ?
La plupart des générateurs de pages ajoutent du poids. Elementor, Divi et Visual Composer ajoutent tous du JavaScript et du CSS supplémentaires. Vous pouvez toujours optimiser les images et ajouter des dimensions. Différer le JavaScript est plus difficile car les générateurs de pages intègrent souvent des scripts.
Envisagez de passer à un thème plus léger si la performance est critique. GeneratePress et Kadence sont des alternatives rapides qui fonctionnent avec l’éditeur de blocs.
Quoi faire cette semaine
Choisissez le correctif qui correspond à votre pire métrique :
Si votre LCP est supérieur à 2,5 secondes, optimisez votre image de héros. Convertissez au WebP. Redimensionnez aux dimensions d’affichage. Ajoutez un CDN. Cela prend 30 minutes et réduit généralement le LCP de 40% à 50%.
Si votre INP est supérieur à 200 millisecondes, différez votre JavaScript. Ajoutez les attributs defer aux balises de script. Déplacez l’analyse en bas. Supprimez les scripts inutilisés. Cela prend 30 à 60 minutes et améliore généralement l’INP de 100 à 200 millisecondes.
Si votre CLS est supérieur à 0,1, spécifiez les dimensions de toutes les images et du contenu dynamique. Définissez les tailles explicites en HTML. Utilisez le swap de font-display pour les polices personnalisées. Évitez d’injecter du contenu au-dessus du pli. Cela prend 1 à 2 heures et réduit généralement le CLS en dessous de 0,1.
Exécutez Site Audit pour voir quelle métrique a besoin d’attention en premier. Forfaits à partir de 50 $/travail. Corrigez les trois problèmes principaux. Réexécutez le test dans une semaine.
L’optimisation des Core Web Vitals n’est pas compliquée. Vous n’avez pas besoin d’une grande agence. Vous n’avez pas besoin d’un ingénieur à temps plein. Vous devez corriger les trois bonnes choses.