
Un audit de performance sur Webflow suit la même logique que sur n'importe quel CMS -- LCP, INP, CLS restent les trois métriques qui comptent -- mais les causes racines diffèrent radicalement. Sur WordPress, on chasse les plugins mal codés et les thèmes surchargés. Sur Webflow, les problèmes viennent presque toujours d'ailleurs : des images mal exportées, des animations Interactions empilées sans discernement, des polices custom chargées en cascade, ou des scripts tiers collés dans le Custom Code sans réflexion.
Chez Mazette.co, on a repris un site e-commerce Webflow dont le LCP dépassait 4,2 secondes sur mobile. Le diagnostic initial du client pointait "Webflow qui rame". Après audit complet, la cause tenait en trois lignes : une image hero de 3,8 Mo non compressée, une police Google Fonts chargée en synchrone bloquant le rendu, et un script de chat tiers injecté en tête de page. Zéro ligne de code Webflow en cause. Le LCP est redescendu à 1,6 seconde après correction -- sans toucher à la structure du site.
Le LCP mesure le temps nécessaire pour afficher le plus gros élément visible à l'écran -- souvent une image hero, parfois un bloc de texte avec background. Sur Webflow, il est presque toujours corrélé au poids des images et au moment où les polices custom se chargent.
Un LCP correct se situe sous 2,5 secondes. Entre 2,5 et 4 secondes, c'est "à améliorer". Au-delà, c'est un problème avéré qui affecte directement le référencement et le taux de rebond.
L'INP a remplacé le FID en 2024 et reste la métrique la moins bien comprise en 2026. Elle mesure le délai entre une interaction utilisateur (clic, tap, saisie clavier) et le rendu visuel de la réponse. Sur Webflow, les coupables habituels sont les animations Interactions trop lourdes déclenchées au scroll, les scripts Finsweet mal configurés, ou l'empilement de plusieurs bibliothèques JavaScript tierces qui bloquent le thread principal.
Un site avec beaucoup de micro-interactions soignées -- ce qui fait justement la force créative de Webflow -- peut voir son INP se dégrader si ces animations ne sont pas optimisées. C'est un vrai sujet d'équilibre entre expérience visuelle et performance technique, qu'on documente d'ailleurs plus en détail dans notre article sur l'art subtil des animations d'interface.
Le CLS mesure les décalages de mise en page pendant que la page se charge -- ce moment frustrant où un bouton se déplace juste avant que l'utilisateur clique. Sur Webflow, les causes fréquentes sont les images sans dimensions définies, les polices custom qui provoquent un "flash" de texte non stylé (FOUT), ou des embeds tiers (vidéos, widgets) qui réservent leur espace trop tard.
Un score CLS correct reste sous 0,1. C'est souvent la métrique la plus facile à corriger une fois identifiée -- et pourtant la plus négligée dans les audits rapides.
| Métrique | Seuil correct | Cause fréquente sur Webflow |
|---|---|---|
| LCP | Moins de 2,5s | Images non compressées, polices bloquantes |
| INP | Moins de 200ms | Animations Interactions lourdes, scripts tiers |
| CLS | Moins de 0,1 | Images sans dimensions, FOUT, embeds tardifs |
La première erreur courante, c'est de se fier uniquement à un score PageSpeed Insights obtenu en une seule mesure. Ce score est une donnée de laboratoire, mesurée dans des conditions contrôlées. Elle ne dit rien de l'expérience réelle vécue par vos visiteurs sur des réseaux mobiles variables, des appareils d'entrée de gamme, ou des connexions saturées.
La vraie source de vérité, c'est le rapport Core Web Vitals de la Google Search Console, alimenté par le CrUX (Chrome User Experience Report) -- des données réelles collectées auprès des utilisateurs Chrome ayant visité le site sur les 28 derniers jours. C'est toujours la première chose qu'on ouvre sur un audit Mazette.co, avant même de lancer un seul test.
Une fois les pages problématiques identifiées via Search Console, on passe aux outils de diagnostic détaillé :
C'est le waterfall de WebPageTest qui révèle le plus souvent la vraie cause : un script tiers qui bloque tout, une police chargée trop tôt, une ressource qui devrait être différée et ne l'est pas.
Sur la grande majorité des audits qu'on mène, les images représentent 60 à 80% du poids total de la page. Webflow propose une compression automatique WebP décente, mais elle ne remplace pas un travail d'export soigné en amont : dimensions adaptées au format d'affichage réel, compression manuelle avant upload, et usage systématique du lazy loading sur tout ce qui n'est pas visible immédiatement (au-dessus de la ligne de flottaison).
Chat en direct, pixels publicitaires, outils d'analytics multiples, widgets de réservation -- chaque script ajouté dans le Custom Code de Webflow a un coût de performance. L'audit doit lister tous les scripts tiers présents, mesurer leur impact individuel via l'onglet Network de Chrome DevTools, et se poser une question simple : est-ce que ce script justifie son coût en performance ?
On a par exemple retiré, sur le site d'un client dans l'événementiel, trois outils d'analytics qui faisaient doublon -- gain immédiat de 400ms sur le LCP mobile, sans aucune perte fonctionnelle.
Les polices custom (hors Google Fonts natives à Webflow) doivent être auto-hébergées et préchargées avec l'attribut preload. Côté Interactions, l'audit consiste à repérer les animations déclenchées au scroll sur des éléments trop nombreux simultanément, ou les triggers configurés en "While scrolling in view" sur des sections entières plutôt que sur des éléments ciblés.
C'est l'objection qu'on entend le plus souvent en phase d'avant-vente, et elle mérite d'être démontée. Webflow génère un code propre, sémantique, et héberge sur une infrastructure CDN (Fastly) largement à la hauteur des standards actuels. Les audits qu'on réalise chez Mazette.co montrent, année après année, que les sites Webflow lents le sont pour des raisons de configuration -- pas de plateforme.
La nuance à connaître : un site codé sur mesure offre un contrôle plus fin sur certains aspects très pointus (bundle JavaScript ultra-minimal, SSR complexe). Mais pour l'immense majorité des sites marketing, vitrines et e-commerce de taille moyenne, un Webflow bien construit rivalise sans complexe avec du sur-mesure -- pour une fraction du coût de développement et de maintenance.
Voici la stack qu'on recommande, du diagnostic rapide à l'analyse fine :
Toutes les recommandations d'un rapport Lighthouse ne se valent pas. Certaines optimisations suggérées (comme éliminer certains CSS non utilisés générés automatiquement par Webflow) apportent un gain marginal pour un risque de casse important sur le design. On les ignore sciemment.
En revanche, trois actions reviennent quasi systématiquement en tête de nos plans de correction :
Ces trois leviers concentrent, dans notre expérience, environ 80% du gain de performance obtenu -- pour 20% de l'effort technique. C'est ce qu'on documente et priorise systématiquement dans nos audits, en lien avec notre approche plus large du SEO technique sur Webflow.
Un audit ponctuel a une durée de vie limitée. Chaque nouvelle section ajoutée, chaque script tiers intégré par une équipe marketing, chaque nouvelle image uploadée sans compression peut faire dériver les scores. On recommande un contrôle trimestriel via Search Console, et un audit approfondi après toute refonte ou ajout significatif de fonctionnalités -- notamment avant une campagne d'acquisition importante, moment où chaque seconde de chargement pèse directement sur le taux de conversion.
Pour les équipes qui pilotent plusieurs sites Webflow en parallèle, on recommande aussi de suivre l'évolution du reporting analytics Webflow, qui s'enrichit régulièrement de nouveaux indicateurs utiles au diagnostic global de la santé d'un site.
Code