Améliorer la vitesse de votre site : comprendre et optimiser les Core Web Vitals

Pour améliorer la vitesse de votre site, mesurez d’abord avec PageSpeed Insights où se situent les problèmes, puis attaquez les plus gros freins : images trop lourdes, absence de cache, polices et scripts bloquants, et réponse lente du serveur. Google évalue l’expérience utilisateur avec trois indicateurs, les Core Web Vitals. Cet article explique ce qu’ils signifient, comment bien les mesurer et quelles mesures apportent le plus, avec des conseils spécifiques à WordPress.

Les trois Core Web Vitals et leurs seuils

Les seuils sont ceux de Google (web.dev, état : octobre 2026). Une page les respecte quand au moins 75 % des pages vues sont dans la zone verte, séparément sur mobile et sur ordinateur. En mars 2024, l’INP a remplacé l’ancien indicateur FID (First Input Delay).

Il vaut aussi la peine de regarder le Time to First Byte (TTFB), c’est-à-dire le temps jusqu’à la première réponse du serveur. Google considère 0,8 seconde ou moins comme une bonne valeur. Le TTFB n’est pas un Core Web Vital, mais il influence directement le LCP : ce que le serveur livre tard, le navigateur ne peut pas l’afficher tôt.

Bien mesurer : données de laboratoire et de terrain

• PageSpeed Insights (pagespeed.web.dev) affiche en haut les données de terrain de vrais utilisateurs de Chrome sur les 28 derniers jours, si elles sont suffisantes, et en dessous un test en laboratoire avec Lighthouse et des recommandations concrètes.
• Le rapport « Core Web Vitals » de la Google Search Console regroupe les données de terrain par groupes de pages similaires et montre quelles URL obtiennent de mauvais résultats. Après une correction, vous pouvez y lancer une validation.
• Les Chrome DevTools, avec Lighthouse et l’onglet Performance, conviennent pour tester pendant que vous travaillez sur le site.

Pour l’évaluation par Google, ce sont les données de terrain qui comptent, pas le score du test en laboratoire. Les petits sites ont souvent trop peu de visites pour des données de terrain ; le test en laboratoire est alors le meilleur repère. Testez toujours aussi l’affichage mobile, en général plus lent que sur ordinateur.

Conseil: Mesurez plusieurs pages typiques, pas seulement la page d’accueil : p. ex. une page de produit ou de service, un article de blog et le formulaire de contact. Modifiez ensuite une seule chose à la fois et mesurez à nouveau.

Images : la cause la plus fréquente d’un mauvais LCP

Sur beaucoup de pages, l’élément LCP est une grande image, p. ex. une image d’en-tête ou un carrousel. Ces mesures sont ici les plus efficaces :

• Livrer les images à la taille réellement affichée et proposer avec srcset différentes tailles pour smartphone et ordinateur.
• Utiliser des formats modernes : WebP ou AVIF sont en général nettement plus légers que JPEG ou PNG à qualité comparable.
• Ne pas différer le chargement de l’image principale visible (pas de lazy loading) et la prioriser avec fetchpriority="high" ; les images plus bas, en revanche, en lazy loading.
• Indiquer la largeur et la hauteur de chaque image pour que le navigateur réserve la place. Cela évite les décalages et améliore le CLS.
• Renoncer au carrousel en en-tête si une seule image suffit.

Cache et réponse du serveur

Chaque page que le serveur n’a pas besoin d’assembler arrive plus vite chez les visiteurs. Trois niveaux sont importants :

• Cache de pages : enregistre les pages HTML terminées. Sur les serveurs LiteSpeed, LSCache s’en charge directement dans le serveur web.
• Cache du navigateur : avec les bons en-têtes de cache, le navigateur ne retélécharge pas les images, le CSS et le JavaScript à la visite suivante.
• Cache objet, p. ex. Redis : accélère les pages dynamiques comme le panier ou l’espace membres, qui ne peuvent pas être mises en cache comme page entière.

Si le TTFB reste élevé malgré le cache, la cause est souvent le serveur : une version de PHP obsolète, trop peu de ressources ou un compte surchargé. Une version de PHP actuelle ou un hébergement avec des ressources attribuées aide alors.

Polices et scripts

Polices web

• Héberger les polices vous-même plutôt que les charger depuis des serveurs externes. Cela économise des connexions et respecte mieux la protection des données.
• Ne charger que les graisses nécessaires, p. ex. normal et gras, au format WOFF2.
• Avec font-display: swap, le navigateur affiche immédiatement le texte dans une police de remplacement.
• Précharger la police la plus importante avec rel="preload".

JavaScript et services tiers

L’INP souffre surtout de grandes quantités de JavaScript qui bloquent le navigateur. Les coupables typiques sont les widgets de chat, les scripts de suivi et de publicité, les bannières de cookies intégrant de nombreux services, les contenus de réseaux sociaux intégrés et les constructeurs de pages lourds.

• Supprimer les scripts inutiles plutôt que de seulement les optimiser.
• Charger les scripts avec defer ou async pour qu’ils ne bloquent pas l’affichage de la page.
• Charger vidéos et cartes seulement après un clic : d’abord une image d’aperçu, ensuite l’intégration.
• Minifier et regrouper le CSS et le JavaScript, mais tester le site après chaque modification.

Éviter les décalages de mise en page (CLS)

Peu de choses agacent autant qu’un bouton qui se déplace au moment où on le touche, parce qu’un élément plus haut se charge encore. Ce sont précisément ces décalages que mesure le CLS. Les causes les plus fréquentes et les solutions :

• Images, vidéos et iframes sans dimensions : indiquer la largeur et la hauteur ou un rapport fixe (aspect-ratio).
• Éléments chargés après coup, comme les bannières de cookies, les barres d’information ou les espaces publicitaires : les afficher par-dessus le contenu ou réserver la place à l’avance.
• Polices web qui modifient la largeur du texte en remplaçant la police de secours : choisir une police de secours aux proportions similaires.
• Contenus insérés par JavaScript au-dessus de la zone visible : ne les insérer qu’après une action du visiteur.

CDN : quand cela vaut la peine

Un réseau de diffusion de contenu (CDN) stocke les fichiers statiques sur des serveurs dans de nombreux pays et les livre depuis l’emplacement le plus proche. C’est surtout utile si vos visiteurs sont répartis sur plusieurs continents. Si votre site s’adresse surtout à une clientèle en Suisse et au Liechtenstein, le cache, des images optimisées et une réponse rapide du serveur apportent en général davantage. Un CDN peut tout de même être utile, p. ex. avec beaucoup de grandes images ou de téléchargements.

WordPress : les principaux leviers

• Utiliser un plugin de cache adapté au serveur web. Sur LiteSpeed, c’est LiteSpeed Cache ; il peut aussi optimiser le CSS et le JavaScript, gérer le lazy loading et convertir les images en WebP ou AVIF via le service QUIC.cloud.
• WordPress prend en charge WebP depuis la version 5.8 et AVIF depuis la version 6.5. Depuis la version 6.3, WordPress ajoute automatiquement fetchpriority="high" à l’image qui sera probablement l’élément LCP.
• Utiliser un thème de blocs léger plutôt qu’un constructeur de pages lourd.
• Vérifier régulièrement les plugins et supprimer tout ce qui ne sert pas.
• Nettoyer la base de données : anciennes révisions, commentaires indésirables et transients expirés, après une sauvegarde.
• Utiliser une version de PHP actuelle ; WordPress recommande actuellement PHP 8.3 ou plus récent.

Conseil: Vous trouverez d’autres conseils pratiques dans notre article « Accélérer WordPress : 8 mesures qui font vraiment la différence ».

Procéder dans cet ordre

1. Relever l’état actuel sur mobile et ordinateur avec PageSpeed Insights et la Search Console.
2. Identifier l’élément LCP (PageSpeed Insights l’indique) et l’optimiser de façon ciblée, en général l’image principale.
3. Activer le cache de pages et vérifier le TTFB.
4. Convertir les images en WebP ou AVIF et indiquer largeur et hauteur.
5. Héberger les polices vous-même et réduire les scripts de services tiers.
6. Mesurer à nouveau après chaque modification et contrôler les données de terrain après quelques semaines.

Sur les offres WordPress de HostOn, LiteSpeed Cache est préconfiguré et les sites tournent sur des serveurs LiteSpeed avec stockage NVMe. Le cache de pages et la réponse du serveur sont ainsi couverts ; les images, les polices et les scripts restent l’affaire du site lui-même.