Core Web Vitals : la performance est devenue une décision de design

La performance web n'est plus un sujet « pour la fin du projet ». Depuis l'intégration des Core Web Vitals dans le ranking SEO de Google, c'est un sujet stratégique — et il commence dès la maquette Figma. Si votre designer ne sait pas ce qu'est un LCP, vous allez le payer en visibilité.

Les trois métriques à connaître

LCP — Largest Contentful Paint

Le temps que met le plus gros élément visible à apparaître. En pratique : votre image hero, votre titre H1, votre bloc principal. Cible : < 2,5 s.

C'est la métrique la plus liée au ressenti d'arrivée sur la page.

INP — Interaction to Next Paint

Le temps de réaction de la page à une interaction utilisateur (clic, frappe, tap). Successeur du FID depuis mars 2024. Cible : < 200 ms.

Le pire signal pour un utilisateur : il clique, il ne se passe rien, il reclique, le résultat se déclenche deux fois.

CLS — Cumulative Layout Shift

Combien la page « bouge » pendant son chargement. Une publicité qui se charge en retard et pousse votre bouton vers le bas, c'est un mauvais CLS. Cible : < 0,1.

C'est la métrique du respect du lecteur.

Pourquoi c'est devenu un sujet de design

Pendant longtemps, la performance était un sujet de fin de chantier : on optimisait après. Aujourd'hui, 70 % des problèmes de Core Web Vitals se décident dans Figma, bien avant qu'une ligne de code soit écrite.

Le poids du hero

Un hero avec une vidéo en autoplay 4K de 12 Mo : LCP catastrophique sur mobile. Si la décision de design est « grosse vidéo cinématique », le développeur ne peut pas la sauver. Il peut compresser, mettre du lazy load, du poster — mais l'image prête à voir arrivera tard.

Décision de design : choisir un visuel hero qui pèse moins de 200 Ko en webp ou avif, ou utiliser une vidéo très courte avec un poster optimisé.

La hiérarchie des polices

Trois familles de polices différentes, chacune en 4 graisses, ça fait 12 fichiers de polices à charger. Sur mobile en 4G, c'est 1,5 seconde de retard rien que pour la typographie. Et un FOIT ou un FOUT garantis (texte invisible ou texte qui saute en cours de chargement) — donc un mauvais CLS.

Décision de design : limiter à 2 familles, 4 graisses maximum, en variable fonts quand c'est possible. Et toujours déclarer font-display: swap ou optional.

Les composants qui « grandissent »

Un widget de chat qui apparaît 3 secondes après le chargement. Un cookie banner qui descend depuis le haut. Une carte de produit qui charge son image après le titre. À chaque fois, c'est du CLS qui s'accumule.

Décision de design : prévoir l'espace réservé pour ces éléments dans le wireframe initial. Pas après. Pas « on verra ».

Les animations lourdes au chargement

Une animation GSAP complexe qui tourne sur 12 éléments dès l'arrivée. Très joli. Et un INP désastreux pendant les 4 premières secondes : si l'utilisateur clique, ça lague.

Décision de design : différer les animations non-critiques après le load event, ou les déclencher au scroll plutôt qu'à l'arrivée.

Le test à 1 minute

Avant de livrer une maquette, posez-vous ces 5 questions :

1. Combien pèse mon visuel hero ? (Cible : < 200 Ko mobile)
2. Combien de polices web différentes ?
3. Y a-t-il des éléments qui apparaissent en différé sans espace réservé ?
4. Y a-t-il des animations qui bloquent les 2 premières secondes ?
5. Mes images ont-elles des dimensions explicites (width/height) pour éviter le CLS ?

Si une réponse est mauvaise, c'est dans Figma qu'il faut régler — pas dans le code.

Les outils pour mesurer

• PageSpeed Insights : la référence Google. Mesure les vraies données utilisateurs (CrUX) + un test labo.
• Chrome DevTools → Lighthouse : audit local complet. Utile en preview avant déploiement.
• WebPageTest : pour les analyses fines (waterfall, comparaisons par région).
• Vercel Analytics / Speed Insights : si vous êtes sur Vercel, gratuit, branché en 2 minutes.

La règle : mesurer avant la prod, sur un environnement preview qui ressemble à la prod. Mesurer une fois en prod sans baseline, c'est trop tard pour corriger sans douleur.

Ce que ça change pour le SEO

Google n'a jamais dit que les Core Web Vitals sont le facteur dominant du ranking. Ce sont des tie-breakers : à contenu équivalent, le site qui charge mieux gagne. Sur les recherches concurrentielles, c'est suffisant pour faire perdre 5 à 15 positions.

Et indépendamment du SEO : un site lent réduit la conversion. Amazon documente publiquement qu'une seconde de latence en plus coûte 1 % de revenu. La performance n'est plus un caprice de développeur.

En une phrase

La performance n'est pas une couche d'optimisation. C'est une contrainte créative à embrasser dès le brief.

Voir services Web & interfaces si vous voulez auditer ou refondre un site avec la performance comme cahier des charges.