Un site lent perd des clients. Ce n'est pas une intuition : Google intègre les Core Web Vitals dans son algorithme de classement depuis 2021, et les études sectorielles montrent de façon constante qu'un délai de chargement supplémentaire d'une seconde réduit le taux de conversion de 7 à 20 %. Ce que beaucoup ignorent, c'est que la majorité des problèmes de performance ne viennent pas du code. Ils viennent des décisions de design.
Ce que Google mesure vraiment avec les Core Web Vitals
Les Core Web Vitals sont trois métriques que Google considère comme les indicateurs les plus représentatifs de l'expérience utilisateur réelle d'une page web. Pas la vitesse théorique mesurée en laboratoire, mais ce que ressent un utilisateur sur son téléphone, sur une connexion 4G moyenne, en situation de navigation normale.
Les trois métriques actuelles :
| Métrique | Ce qu'elle mesure | Seuil « Bon » | Seuil « À améliorer » |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Temps avant que le contenu principal soit visible | < 2,5 s | 2,5 s à 4 s |
| INP (Interaction to Next Paint) | Réactivité aux interactions utilisateur | < 200 ms | 200 ms à 500 ms |
| CLS (Cumulative Layout Shift) | Stabilité visuelle de la page | < 0,1 | 0,1 à 0,25 |
Ce tableau a une conséquence directe pour les clients : un site qui dépasse les seuils « À améliorer » sur l'une de ces métriques est pénalisé dans les résultats de recherche Google, même si son contenu est excellent. Le design est donc un levier SEO autant qu'un levier de conversion.
LCP : le hero tue la performance sans qu'on s'en rende compte
Le LCP mesure le temps avant que le plus grand élément visible de la page soit rendu. Dans 80 % des cas sur les sites marketing, cet élément est le hero : l'image ou la vidéo de fond en haut de page.
C'est là que les décisions de design ont l'impact le plus immédiat.
Une image hero non optimisée de 3 ou 4 Mo est le scénario le plus fréquent que l'on rencontre sur des sites en refonte. Sur mobile avec une connexion standard, cette image met 4 à 8 secondes à s'afficher. Le LCP est immédiatement dans la zone rouge. Google le détecte, les utilisateurs partent avant même de voir le contenu.
Les choix de design qui dégradent le LCP :
Les vidéos en autoplay en hero. Une vidéo de fond, même compressée, représente plusieurs Mo à charger avant que l'utilisateur voit quoi que ce soit. Le LCP attend que l'élément soit visible. Si la vidéo est le plus grand élément, le LCP attend la vidéo.
Les images non dimensionnées. Un design qui ne spécifie pas de dimensions explicites pour les images force le navigateur à les calculer après le téléchargement. Temps perdu, LCP dégradé.
Les polices personnalisées non préchargées. Si le titre principal est rendu avec une police web qui n'est pas préchargée, le navigateur affiche un texte invisible (FOIT) ou un texte de substitution (FOUT) pendant le chargement. Le LCP peut pointer vers un élément qui n'est pas encore dans sa forme finale.
<!-- Ce que le code doit faire pour un hero optimisé -->
<link rel="preload" as="image" href="/hero.webp" />
<link rel="preload" as="font" href="/fonts/MessinaSans.woff2" crossorigin />
<img
src="/hero.webp"
width="1600"
height="900"
fetchpriority="high"
alt="Description du hero"
/>
L'attribut fetchpriority="high" indique au navigateur de charger cette image en priorité absolue, avant les autres ressources. C'est une décision qui se prend au moment de l'intégration du design, pas après coup.
CLS : quand la page « saute » et fait fuir les utilisateurs
Le CLS mesure les décalages visuels inattendus : ces moments où le contenu se déplace pendant le chargement et où l'utilisateur clique sur le mauvais bouton parce que la page a bougé sous ses doigts.
C'est la métrique la plus directement liée aux choix de design, et souvent la plus ignorée lors des maquettes.
Les causes les plus fréquentes :
Les images sans dimensions déclarées. Si le CSS ou le HTML ne réserve pas d'espace pour une image avant qu'elle soit chargée, le navigateur insère l'image une fois téléchargée et pousse tout le contenu en dessous vers le bas. Chaque image sans width et height explicites est un risque de CLS.
Les polices web qui remplacent les polices système. Quand une police web se charge, elle remplace la police de substitution. Si les deux n'ont pas la même taille de caractères, le texte change de taille et décale tout le contenu autour. Le descripteur CSS size-adjust permet de calibrer la police de substitution pour minimiser ce décalage.
/* Calibrer la police de substitution pour réduire le CLS au chargement */
@font-face {
font-family: "MessinaFallback";
src: local("Arial");
size-adjust: 94%;
ascent-override: 96%;
descent-override: normal;
}
body {
font-family: "MessinaSans", "MessinaFallback", sans-serif;
}
Les bannières et popups qui s'insèrent dynamiquement. Un bandeau cookies ou une barre de notification qui apparaît en haut de page après le chargement décale tout le contenu visible. Le design doit prévoir un espace réservé statique pour ces éléments, ou les positionner en fixed pour qu'ils ne perturbent pas le flux du document.
Les publicités et widgets tiers sans dimensions fixes. Si un composant tiers (chat, avis clients, iframe) n'a pas de hauteur minimale réservée dans le CSS, il génère un décalage à chaque chargement.
INP : les animations et interactions qui bloquent le fil principal
Le INP mesure la réactivité. Si un utilisateur clique sur un bouton et que la page met plus de 200 ms à répondre visuellement, Google le note. Si ça arrive régulièrement pendant la session, le score INP se dégrade.
D'un point de vue design, les coupables les plus fréquents sont les animations JavaScript lourdes et les interactions complexes qui monopolisent le fil principal du navigateur.
Le navigateur a un seul fil principal pour traiter le JavaScript, calculer les layouts et peindre les pixels. Une animation qui s'exécute en JavaScript (plutôt qu'en CSS ou via le compositor) bloque ce fil pendant son exécution. Pendant ce temps, aucune interaction utilisateur ne peut être traitée.
/* Animations qui passent par le compositor GPU — n'impactent pas l'INP */
.card {
transition: transform 300ms ease, opacity 300ms ease;
}
.card:hover {
transform: translateY(-4px);
opacity: 0.9;
}
/* À éviter : animer des propriétés qui déclenchent un recalcul de layout */
.card:hover {
margin-top: -4px; /* déclenche un reflow, bloque le fil principal */
width: 105%; /* idem */
}
Les propriétés transform et opacity sont traitées par le GPU sans passer par le fil principal. margin, width, height, padding et top/left déclenchent un recalcul de layout à chaque frame. Sur des animations à 60 fps avec des dizaines d'éléments, la différence est mesurable.
Pour les effets de scroll élaborés (parallax, révélations au scroll), la API Intersection Observer est la solution qui n'impacte pas l'INP. Elle s'exécute hors du fil principal et déclenche les callbacks uniquement quand les éléments entrent dans le viewport.
Pourquoi c'est un argument commercial, pas juste technique
Les clients ne pensent pas en millisecondes. Ils pensent en résultats : trafic organique, taux de conversion, panier moyen. La bonne façon de présenter l'impact des Core Web Vitals à un client n'est pas technique, c'est économique.
Un site e-commerce qui passe de 4 secondes à 2 secondes de LCP observe en général une augmentation du taux de conversion de 15 à 25 %. Sur un chiffre d'affaires en ligne de 500 000 euros annuels, c'est entre 75 000 et 125 000 euros de revenus supplémentaires sans changer une ligne de contenu ni le budget publicitaire.
Un site vitrine B2B qui passe du rouge au vert sur les Core Web Vitals améliore son positionnement Google. Sur des mots-clés à fort volume où la concurrence est établie, remonter de quelques positions dans les résultats peut doubler le trafic organique. C'est du trafic qualifié, sans coût d'acquisition.
Ce qu'on en retient
Les Core Web Vitals ne sont pas un problème de développement à résoudre après que le design est figé. Ce sont des contraintes de design à intégrer dès les maquettes. La taille du hero, le choix des polices, les animations, les composants dynamiques : chaque décision visuelle a une conséquence mesurable sur LCP, CLS et INP.
Pour les clients, l'enjeu est simple : un site bien noté sur les Core Web Vitals est mieux classé sur Google, se charge plus vite sur mobile, et convertit davantage. C'est un investissement dont le retour est mesurable, pas une dépense esthétique.