La plupart des articles sur les Core Web Vitals répètent qu'il faut « optimiser ses images ». C'est vrai et inutile. Voici ce qui, dans Webflow spécifiquement, fait bouger l'aiguille : et les pièges que l'éditeur vous tend sans le dire.

1. Votre image hero est en lazy loading, et c'est elle qui plombe le LCP

Webflow applique loading="lazy" par défaut sur les images. Sur une image située sous la ligne de flottaison, c'est parfait. Sur l'image de votre hero, c'est un contresens : le navigateur retarde volontairement le chargement de l'élément que Google chronomètre pour calculer votre LCP.

Sélectionnez l'image du premier écran, ouvrez les paramètres de l'élément et passez Loading sur « Eager ». C'est un réglage, dix secondes, et c'est souvent le gain le plus important de toute la page.

2. Le srcset automatique ne se déclenche pas en dessous d'une certaine taille

Webflow génère automatiquement des variantes responsives de vos images : mais uniquement au-dessus d'un certain seuil de largeur. Une image uploadée en 1200px de large est servie telle quelle à tout le monde, y compris sur un mobile de 390px.

Conséquence contre-intuitive : uploader une image plus grande peut alléger votre page, parce qu'elle déclenche la génération des variantes. Uploadez vos visuels en 2000px de large minimum et laissez Webflow découper.

3. Vos polices personnalisées sont probablement en .ttf

Un fichier .ttf pèse en moyenne trois à quatre fois plus lourd que son équivalent .woff2, pour un rendu identique. Webflow accepte les deux formats sans rien signaler.

Allez dans Project Settings → Fonts, vérifiez le format de chaque police uploadée, et remplacez les .ttf par des .woff2. Un convertisseur en ligne fait ça en une minute. Sur un site avec trois graisses de police, le gain se compte en centaines de kilo-octets sur le premier chargement.

4. Le CLS vient presque toujours des images sans dimensions

Le Cumulative Layout Shift mesure les éléments qui bougent pendant le chargement. La cause numéro un : une image dont le navigateur ne connaît pas les proportions avant de l'avoir téléchargée. Il réserve zéro pixel, puis pousse tout le contenu vers le bas quand l'image arrive.

Dans Webflow, définissez une largeur et une hauteur explicites sur vos images, ou au minimum un aspect-ratio sur leur conteneur. Le navigateur réserve alors la place correcte dès le premier rendu.

5. Chaque interaction IX2 sur le premier écran coûte du JavaScript bloquant

Les interactions Webflow sont pratiques et grisantes. Elles s'appuient sur webflow.js, chargé sur toutes les pages, dont le poids augmente avec le nombre d'interactions du projet.

La règle à appliquer : aucune animation d'apparition sur le contenu du premier écran. Un titre qui fait un fondu à l'arrivée est un titre que Google voit apparaître en retard. Gardez les interactions pour ce qui est sous la ligne de flottaison, là où elles ont un vrai rôle narratif.

Pensez aussi à nettoyer les interactions orphelines : celles créées pendant le design puis abandonnées restent dans le fichier et continuent de peser.

6. Votre vidéo de fond n'a pas de poster

Le Background Video de Webflow encode automatiquement plusieurs résolutions, ce qui est bien fait. En revanche, si vous ne définissez pas d'image poster, le bloc reste noir jusqu'à ce que la vidéo soit prête. Sur mobile, où la lecture automatique est souvent bloquée, le visiteur peut rester sur un rectangle noir.

Définissez toujours un poster, et posez-vous la vraie question : cette vidéo de fond apporte-t-elle quelque chose, ou est-elle là parce que ça fait joli en présentation client ?

Dans quel ordre s'y prendre

1. Passez l'image hero en eager
2. Vérifiez le format des polices
3. Définissez les dimensions de toutes les images
4. Supprimez les interactions du premier écran
5. Réuploadez les images trop petites en 2000px
6. Ajoutez les posters de vidéo

Mesurez avant et après avec PageSpeed Insights, en testant l'URL publiée et non le prévisualiseur Webflow : le Designer ajoute ses propres scripts et fausse complètement la mesure.

Un dernier point que personne ne mentionne

Les Core Web Vitals que Google utilise pour le classement ne sont pas ceux de PageSpeed Insights. Ce sont les données de terrain du rapport CrUX, collectées auprès des vrais visiteurs de Chrome, sur 28 jours glissants.

Deux conséquences pratiques : un site à faible trafic n'a parfois aucune donnée de terrain, et vos améliorations mettent jusqu'à quatre semaines à apparaître dans Search Console. Ne refaites pas dix fois vos réglages parce que le score n'a pas bougé le lendemain.