Core Web Vitals sur Webflow : comment obtenir 90+ sur PageSpeed en 2026

Vous avez livré un site Webflow propre, designé au cordeau, et PageSpeed affiche 64 sur mobile.

‍

Le réflexe est de blâmer Webflow. Dans 9 cas sur 10, le problème vient d'ailleurs : une image héros de 2 Mo, trois scripts marketing en header, deux polices Google chargées en synchrone. Les Core Web Vitals sur Webflow ne se règlent pas en cochant une case, mais en traitant un par un les trois indicateurs que mesure Google : le LCP, le CLS et le INP.

‍

Ce guide reprend ce que j'applique sur les sites Webflow de mes clients PME pour passer le seuil des 90 sur PageSpeed Insights. Vous trouverez les seuils à viser en 2026, un cas réel chiffré, les leviers d'optimisation par métrique, et une checklist à dérouler en moins d'une heure.

Core Web Vitals en 2026 : ce que Google mesure vraiment

Les Core Web Vitals sont trois métriques de performance utilisateur que Google intègre depuis 2021 dans ses signaux de classement. Elles concernent toutes les pages, mobiles comme desktop, et alimentent le rapport Expérience sur la page dans la Search Console.

‍

LCP, CLS, INP : les seuils 2026

Le LCP (Largest Contentful Paint) mesure le temps que met le plus gros élément visible à s'afficher. Cible : moins de 2,5 secondes. Sur un site Webflow, c'est presque toujours l'image héros ou un bloc de texte en H1.

‍

Le CLS (Cumulative Layout Shift) mesure les sauts visuels pendant le chargement. Cible : moins de 0,1. Les images sans dimensions, les bannières cookies qui poussent le contenu et les polices qui swap en cours de route font grimper ce score.

‍

Le INP (Interaction to Next Paint) a remplacé le FID en mars 2024. Il mesure la latence entre l'interaction d'un utilisateur (clic, tap, saisie clavier) et la prochaine peinture visuelle. Cible : moins de 200 millisecondes. Selon les données CrUX publiées par Google début 2026, 43 % des sites échouent encore sur cet indicateur. C'est aujourd'hui le talon d'Achille des sites Webflow chargés de scripts tiers.

‍

Pourquoi PageSpeed et CrUX ne donnent pas le même score

PageSpeed Insights affiche deux blocs : "Données de terrain" (CrUX, les vraies données utilisateurs) et "Données de laboratoire" (test simulé via Lighthouse). Le SEO est jugé sur les données de terrain. Vous pouvez très bien avoir 95 en laboratoire et un signal rouge dans la Search Console si les vrais visiteurs subissent un INP dégradé. C'est pour ça qu'il faut suivre les deux.

Webflow est-il vraiment rapide par défaut ?

Oui, dans une certaine mesure. Webflow sert son code via Amazon CloudFront, compresse automatiquement les images en WebP, gère le lazy loading des images en dessous de la ligne de flottaison et minifie HTML, CSS et JS si vous activez l'option dans les Site Settings.

‍

Mais cette base ne suffit pas pour passer 90 sur PageSpeed. Un site Webflow non optimisé partira typiquement entre 55 et 75 sur mobile. La marge à grappiller, ce sont les fichiers que vous uploadez (images, polices, embeds) et les scripts que vous ajoutez (analytics, chat, pixels). C'est là que se joue le score.

Cas réel : un site PME passé de 62 à 94 sur PageSpeed

Sur un site Webflow refait pour un cabinet de conseil basé à Boulogne-Billancourt en mars 2026, le score PageSpeed mobile au lancement était de 62. Pas catastrophique, pas suffisant. La page d'accueil pesait 3,4 Mo, avec un LCP à 4,1 secondes et un INP à 380 ms.

‍

Voici ce qui a bougé en deux heures de travail :

L'image héros (1,8 Mo en JPEG) a été remplacée par un WebP de 180 Ko, dimensionné à la taille d'affichage réelle, avec un <link rel="preload"> posé dans le head. Les six polices Google ont été ramenées à deux fichiers WOFF2 auto-hébergés, avec font-display: swap. Les scripts marketing (GTM, HubSpot, chatbot) sont passés du header au footer, avec un chargement différé après le load event. Trois interactions IX2 sur des éléments hors écran ont été supprimées.

‍

Résultat mesuré après deux semaines de données CrUX : PageSpeed mobile à 94, LCP à 1,9 s, CLS à 0,03, INP à 140 ms. Tous les voyants au vert dans la Search Console, et un gain de 22 % sur le temps moyen passé sur la page d'accueil.

Optimiser le LCP sur Webflow : les leviers qui paient

Compresser et dimensionner les images

Webflow génère automatiquement plusieurs tailles d'image responsive si vous uploadez une image de plus de 100 px de large via le designer. Bonne nouvelle. Mauvaise nouvelle : il ne touche pas au poids du fichier source. Un JPEG de 4 Mo téléversé reste un JPEG de 4 Mo dans votre Asset Manager, et c'est ce poids qui plombe le LCP sur mobile.

‍

La règle qui fonctionne : passer toutes les images par un compresseur (Squoosh, TinyPNG ou ImageOptim) avant l'upload, viser moins de 200 Ko pour les images héros et moins de 80 Ko pour les images de section. Le format WebP est servi automatiquement par Webflow aux navigateurs compatibles, donc inutile de convertir manuellement.

‍

Précharger l'image héros

L'image au-dessus de la ligne de flottaison est presque toujours votre LCP. Forcer son chargement prioritaire via un <link rel="preload" as="image" href="..." fetchpriority="high"> dans le head du Page Settings fait gagner 300 à 800 ms sur mobile 4G. C'est un des seuls custom code qu'il faut placer en header sur Webflow, justement parce qu'on veut qu'il bloque.

‍

Maîtriser le chargement des polices

Trois polices Google chargées en synchrone, c'est 600 à 900 ms de blocage rendu. Sur Webflow, deux options : limiter à deux polices maximum, ou auto-héberger les fichiers WOFF2 (uploadés dans l'Asset Manager) et déclarer un @font-face avec font-display: swap. La seconde option supprime aussi le ping vers fonts.googleapis.com, ce qui aide pour la conformité RGPD au passage.

Réduire le CLS : éviter les sauts de mise en page

Sur Webflow, le CLS se règle en trois mouvements. Premièrement, toujours définir une width et une height (ou un aspect ratio) sur les images dans le designer. Webflow le fait par défaut sur les images insérées via le Asset Panel, mais pas systématiquement sur les images de fond CSS.

‍

Deuxièmement, réserver l'espace des bannières cookies, des chatbots et des embeds vidéo. Un bandeau RGPD qui apparaît 500 ms après le chargement et pousse le contenu vers le bas fait exploser le CLS. La parade : positionner ce type d'élément en fixed ou sticky plutôt qu'en flux.

‍

Troisièmement, charger les polices avec font-display: swap ET pré-charger les fichiers de la police principale. Sans pré-chargement, la police par défaut s'affiche puis swap brutalement vers la vraie police, ce qui décale tous les blocs de texte.

Améliorer l'INP : la métrique 2026 qui plombe les sites Webflow

L'INP est devenu en 2026 le principal point de blocage des sites Webflow. La raison est simple : Webflow rend très facile l'ajout de scripts tiers via les Custom Code embeds, et chaque script ajoute du JavaScript qui se bat avec les gestionnaires d'événements de la page.

‍

Auditer les scripts tiers

Lancez un audit Lighthouse en mode mobile et regardez l'onglet "Réduire le code JavaScript inutilisé". Vous y verrez le poids exact de chaque script tiers. Sur un site PME typique, Google Tag Manager charge 6 à 10 tags, plus un chat (Intercom, Tidio), un pixel Meta, parfois un outil d'A/B testing. Cumulé, ça ajoute facilement 200 ms d'overhead sur chaque interaction.

‍

La règle : garder GTM, le pixel Meta et un seul outil d'analytics. Tout le reste passe par GTM en chargement déclenché par interaction utilisateur, pas au pageview.

‍

Différer le JavaScript non critique

Sur Webflow, tout custom code en footer est par défaut chargé après le rendu du DOM. Profitez-en : déplacez tous les scripts marketing du Page Settings header vers le footer, sauf si un consultant SEO ou marketing exige le contraire pour des raisons de mesure first-party.

‍

Pour les scripts vraiment lourds (chatbot, widget de prise de RDV, lecteur vidéo embed), utilisez une initialisation paresseuse : ne les charger qu'au scroll ou au clic sur un bouton. Une dizaine de lignes de JavaScript suffisent.

‍

Limiter les interactions IX2

Webflow Interactions (IX2) est un outil puissant, mais chaque interaction posée sur la page ajoute du JavaScript qui s'exécute au scroll, au hover ou au load.

‍

Sur la page d'accueil, gardez les interactions essentielles au-dessus de la ligne de flottaison, et préférez des animations CSS pures (transition, keyframes) pour les effets simples de hover ou de fade-in. Le gain sur l'INP est mesurable dès la première mise à jour.

Checklist Webflow Core Web Vitals à dérouler en 60 minutes

Avant de partir chercher la perfection, déroulez cette liste. Sur 80 % des sites Webflow que je reprends, elle suffit à passer 85+.

‍

Compresser toutes les images héros à moins de 200 Ko avant upload. Limiter à deux polices, idéalement auto-hébergées en WOFF2. Pré-charger l'image héros via un <link rel="preload"> en header. Activer le minify HTML, CSS et JS dans les Site Settings, onglet Publishing. Déplacer tous les scripts marketing du header vers le footer du Page Settings. Auditer GTM et supprimer les tags inutiles.

‍

Vérifier que chaque image a des dimensions définies. Désactiver les interactions IX2 hors écran sur la home. Lancer un test PageSpeed mobile et noter les trois premiers warnings, qui sont presque toujours les bons indicateurs à travailler en priorité.

‍

Pour aller plus loin sur la performance globale et la migration depuis WordPress, mon guide complet sur la refonte de site avec Webflow détaille les étapes méthodologiques. Et si vous démarrez votre projet, le SEO sur Webflow couvre les points techniques complémentaires aux Core Web Vitals.

FAQ

Quel score PageSpeed viser sur un site Webflow professionnel ?

Visez 90+ sur mobile et 95+ sur desktop dans les données de laboratoire. Sur les données de terrain (CrUX), l'objectif est d'avoir les trois Core Web Vitals au vert : LCP sous 2,5 s, CLS sous 0,1 et INP sous 200 ms.

‍

Webflow est-il plus rapide que WordPress sur les Core Web Vitals ?

En moyenne, oui. Les benchmarks 2026 placent Webflow 2,3 fois plus rapide sur le LCP qu'un WordPress avec un page builder. Mais un Webflow mal optimisé peut être plus lent qu'un WordPress bien tenu. Le CMS ne fait pas tout, le travail d'optimisation reste indispensable.

‍

Combien de temps faut-il pour optimiser un site Webflow existant ?

Pour un site PME de 5 à 15 pages, comptez deux à quatre heures de travail concentré : audit, compression d'images, déplacement des scripts, ajustement des polices et des IX2. Les gains apparaissent dans les données CrUX au bout de 14 à 28 jours.

‍

L'INP remplace-t-il vraiment le FID dans Search Console ? Oui, depuis mars 2024. Le rapport Expérience sur la page de la Search Console n'affiche plus que LCP, CLS et INP. C'est la métrique sur laquelle un nombre grandissant de sites Webflow se font pénaliser en 2026.

‍

Faut-il un développeur pour optimiser les Core Web Vitals sur Webflow ? Pour les 80 % des cas, non. La compression d'images, le tri des scripts dans GTM et la gestion des polices sont faisables par un éditeur de contenu formé. Pour les 20 % restants (préchargement, custom code, gestion fine de l'INP), un accompagnement spécialisé Webflow est plus efficace que des heures de tâtonnement.

Conclusion

Trois points à retenir. Premièrement, les Core Web Vitals sur Webflow ne dépendent pas du CMS lui-même mais de ce que vous y ajoutez : images, polices, scripts. Deuxièmement, l'INP est devenu en 2026 le point de blocage principal, et il se règle en faisant le ménage dans les scripts tiers.

‍

Troisièmement, une checklist d'optimisation bien menée passe la plupart des sites PME de 60-70 à 90+ sur PageSpeed en moins d'une demi-journée.

‍

Si vous voulez auditer votre site Webflow ou faire optimiser ses Core Web Vitals par une agence qui pratique au quotidien, contactez Dresscodes pour un audit gratuit. Pour en savoir plus sur la philosophie de la plateforme, consultez aussi la documentation officielle de Google sur les Core Web Vitals et le guide Webflow Speed Mastery sur le blog officiel Webflow.