Comprendre et optimiser les Core Web Vitals
L’optimisation des Core Web Vitals n’est plus une option pour les sites web modernes, mais une nécessité technique. Ces indicateurs, définis par Google, mesurent la qualité de l’expérience utilisateur à travers trois dimensions : le chargement, l’interactivité et la stabilité visuelle. Pour un profil expérimenté, l’enjeu ne réside pas seulement dans l’obtention d’un score vert sur PageSpeed Insights, mais dans la mise en place d’une stratégie d’optimisation durable et scalable.
Comprendre les indicateurs Core Web Vitals
Avant d’intervenir sur le code, il est crucial de définir précisément ce que nous cherchons à optimiser. Les Core Web Vitals se concentrent sur trois métriques clés.
| Métrique | Cible (Bon) | Ce qu’elle mesure | Impact principal |
|---|---|---|---|
| LCP (Largest Contentful Paint) | < 2,5 s | Vitesse de chargement du plus gros élément visible | Performance perçue |
| INP (Interaction to Next Paint) | < 200 ms | Réactivité globale du site aux interactions | Fluidité d’utilisation |
| CLS (Cumulative Layout Shift) | < 0,1 | Stabilité des éléments lors du chargement | Confort visuel |
Optimiser le Largest Contentful Paint (LCP)
Le LCP est souvent impacté par le temps de réponse du serveur (TTFB), le blocage du rendu par le CSS/JavaScript, ou des ressources trop lourdes.
Prioriser le chargement des ressources critiques
Pour réduire le LCP, vous devez indiquer au navigateur quelle ressource est prioritaire. L’utilisation de l’attribut fetchpriority sur l’image principale (hero image) est une technique efficace.
<link
rel="preload"
as="image"
href="/images/hero.webp"
fetchpriority="high"
>
<img
src="/images/hero.webp"
alt="Description de l'image principale"
width="1280"
height="720"
fetchpriority="high"
decoding="async"
>fetchpriority="high" indique au navigateur que l’image est importante pour le rendu initial. L’utilisation de preload permet également de demander la ressource plus tôt lorsqu’elle est réellement critique.
Les attributs width et height permettent quant à eux au navigateur de connaître les dimensions de l’image avant son téléchargement et contribuent ainsi à limiter les changements de mise en page.
Attention : il ne faut pas précharger toutes les images. Le preload doit être réservé aux ressources réellement critiques, notamment l’image qui constitue le LCP.
Éliminer les ressources bloquant le rendu
Le CSS et le JavaScript placés dans le <head> peuvent bloquer ou retarder le rendu initial. Une stratégie efficace consiste à extraire le CSS critique et à différer le chargement des ressources secondaires.
Ne placez pas de scripts JavaScript lourds dans le <head> sans stratégie de chargement appropriée, car leur téléchargement et leur exécution peuvent retarder le rendu et dégrader le LCP.
<head>
<!-- CSS critique directement disponible -->
<style>
body {
margin: 0;
font-family: system-ui, sans-serif;
}
.hero {
min-height: 60vh;
display: grid;
place-items: center;
}
</style>
<!-- CSS secondaire chargé après le rendu initial -->
<link
rel="preload"
href="/css/main.css"
as="style"
onload="this.onload=null;this.rel='stylesheet'"
>
<noscript>
<link rel="stylesheet" href="/css/main.css">
</noscript>
<!-- JavaScript différé -->
<script src="/js/main.js" defer></script>
</head>Le principe consiste à séparer les ressources selon leur importance :
- CSS critique : nécessaire au premier affichage et disponible immédiatement.
- CSS secondaire : chargé sans bloquer inutilement le rendu initial.
- JavaScript : différé lorsque son exécution n’est pas nécessaire au rendu initial.
Les attributs async et defer ne sont pas interchangeables.
<!-- À éviter pour un script lourd -->
<script src="/js/main.js"></script>
<!-- Préférable pour un script dépendant du DOM -->
<script src="/js/main.js" defer></script>
<!-- Adapté à un script indépendant -->
<script src="/js/analytics.js" async></script>defer permet au navigateur de poursuivre l’analyse du document HTML et d’exécuter le script une fois le parsing terminé. L’ordre entre plusieurs scripts defer est conservé.
async permet au script de s’exécuter dès que son téléchargement est terminé. L’ordre d’exécution entre plusieurs scripts async n’est donc pas garanti.
Réduire le Cumulative Layout Shift (CLS)
Le CLS survient lorsque des éléments se déplacent brusquement, provoquant des clics accidentels ou une frustration visuelle.
Réserver l’espace pour les médias
L’erreur la plus commune est l’absence de dimensions sur les images, les vidéos ou certains composants dynamiques. Le navigateur ne peut alors pas calculer correctement l’espace nécessaire avant le téléchargement de la ressource.
<img
src="/images/article.webp"
alt="Illustration de l'article"
width="1200"
height="800"
loading="lazy"
decoding="async"
>
Pour une image responsive, utilisez srcset et sizes afin de permettre au navigateur de sélectionner une ressource adaptée à la taille d’affichage.
<img
src="/images/article-1200.webp"
srcset="
/images/article-480.webp 480w,
/images/article-768.webp 768w,
/images/article-1200.webp 1200w
"
sizes="(max-width: 768px) 100vw, 1200px"
alt="Illustration de l'article"
width="1200"
height="800"
loading="lazy"
decoding="async"
>Pour les composants dont les dimensions sont déterminées dynamiquement, la propriété CSS aspect-ratio permet également de réserver l’espace nécessaire avant le chargement du média.
.media-container {
width: 100%;
aspect-ratio: 16 / 9;
overflow: hidden;
}
.media-container img {
width: 100%;
height: 100%;
object-fit: cover;
}
<div class="media-container">
<img
src="/images/video-thumbnail.webp"
alt="Aperçu de la vidéo"
width="1280"
height="720"
loading="lazy"
decoding="async"
>
</div>
Cette technique est particulièrement utile pour les images, vidéos, publicités et composants intégrés dont le contenu est chargé de manière asynchrone.
Gérer le chargement des polices de caractères
Le chargement d’une police personnalisée peut provoquer des changements visuels lorsque le navigateur passe d’une police système à la police finale. Utilisez font-display: swap dans vos règles @font-face afin de permettre l’affichage rapide d’une police de remplacement.
@font-face{
font-family: 'MaPoliceCustom';
src: url('/fonts/ma-police.woff2') format('woff2');
font-display: swap;
}Lorsque cela est pertinent, privilégiez également les formats modernes comme WOFF2 et limitez le nombre de variantes et de graisses réellement utilisées par le site.
Améliorer l’Interaction to Next Paint (INP)
L’INP mesure le délai entre une interaction de l’utilisateur et la mise à jour visuelle correspondante de l’interface. Un INP élevé est généralement le signe d’un thread principal (Main Thread) saturé par du JavaScript.
Décomposer les tâches JavaScript longues
Une tâche JavaScript de plus de 50 ms est considérée comme une Long Task. Elle peut monopoliser le thread principal et retarder le traitement des interactions utilisateur, ce qui peut dégrader l’INP.
Une solution consiste à découper les traitements lourds afin de permettre au navigateur de traiter d’autres tâches entre deux lots d’exécution.
*
async function processLargeData(data) {
for (let i = 0; i < data.length; i++) {
doHeavyWork(data[i]);
if (i % 10 === 0) {
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
}
}Dans cet exemple, le traitement est interrompu périodiquement afin de rendre la main au navigateur. scheduler.yield() constitue une approche moderne lorsqu’elle est disponible, tandis que setTimeout peut servir de solution de repli.
Optimiser l’exécution du JavaScript
Réduisez la quantité de JavaScript exécutée au démarrage. Toutes les fonctionnalités d’une application n’ont pas nécessairement besoin d’être chargées immédiatement.
Analysez vos bundles avec des outils comme Webpack Bundle Analyzer, identifiez les dépendances coûteuses et supprimez le code mort grâce au Tree Shaking.
Le code splitting permet également de charger certaines fonctionnalités uniquement lorsqu’elles deviennent nécessaires :
const button = document.querySelector('#open-editor');
button.addEventListener('click', async () => {
const { openEditor } = await import('./editor.js');
openEditor();
});Dans cet exemple, le module de l’éditeur n’est téléchargé qu’au moment où l’utilisateur en a réellement besoin. Cette approche réduit le JavaScript initial et peut contribuer à améliorer la réactivité de la page.
Vérification et monitoring continu
L’optimisation des Core Web Vitals n’est pas un événement unique, mais un cycle continu. Une modification du code, l’ajout d’un plugin ou l’intégration d’un nouveau service tiers peut rapidement dégrader les performances.
Utilisez plusieurs sources de données pour surveiller les performances :
- PageSpeed Insights : pour effectuer un diagnostic ponctuel et comparer les données de laboratoire aux données de terrain lorsqu’elles sont disponibles.
- Chrome User Experience Report (CrUX) : pour analyser les performances observées auprès de véritables utilisateurs sur une période glissante de 28 jours.
- Google Search Console : pour identifier les groupes de pages présentant des problèmes de Core Web Vitals.
- Chrome DevTools : pour identifier les tâches longues, analyser le Main Thread et comprendre précisément l’origine des problèmes de performance.
Une démarche efficace consiste à mesurer avant toute modification, identifier la métrique problématique, corriger la cause technique, puis mesurer à nouveau afin de vérifier que l’amélioration est réelle.
Conclusion
L’optimisation des Core Web Vitals demande une approche rigoureuse : d’abord mesurer, puis prioriser les ressources critiques pour le LCP, stabiliser le layout pour le CLS et alléger le thread principal pour l’INP.
Les optimisations les plus efficaces ne consistent pas simplement à accumuler des hacks destinés à obtenir un meilleur score dans un outil de test. Elles consistent à améliorer durablement l’architecture du site : réduire les ressources inutiles, charger les éléments au moment opportun, réserver l’espace des contenus dynamiques et limiter le travail effectué sur le thread principal.
En combinant ces techniques avec un monitoring régulier des données réelles, vous améliorez non seulement les performances techniques du site, mais surtout la qualité de l’expérience réellement vécue par vos utilisateurs.
