Custom Code Webflow

Notre point de vue sur le custom code dans Webflow

Webflow est puissant tant qu'on reste dans son périmètre. Dès qu'on en sort (intégrations API exotiques, animations qu'aucun outil no-code ne couvre, logique métier spécifique), il faut du JavaScript. La question n'est pas "est-ce qu'on code", c'est "comment on code proprement".

La majorité des sites Webflow qu'on audite ont du custom code, mais mal organisé : scripts collés inline dans plusieurs pages, copies de Stack Overflow non testées, pas de versioning, pas de documentation. Notre approche est inverse : tout custom code passe par GitHub, est testé, versionné et documenté.

Quand on choisit d'ajouter du custom code

• Fonctionnalité hors-Webflow. API tierce non couverte par Zapier ou n8n, intégration à un système client interne, calcul métier spécifique.
• Animation impossible en natif. Quand GSAP ou Webflow Interactions atteignent leurs limites et qu'on a besoin d'un comportement vraiment sur-mesure.
• Optimisation performance ciblée. Lazy-loading conditionnel, préchargement intelligent, gestion fine des Web Vitals.
• Logique conditionnelle complexe. Affichage différencié selon utilisateur, géolocalisation, device, heure de la journée.

Quand on déconseille le custom code

• Solution no-code disponible. Avant de coder, on vérifie systématiquement Finsweet Attributes, Wized, et les natifs Webflow. Si une option no-code existe, elle gagne.
• Client non technique qui devra maintenir. Si le client va modifier seul, le code custom devient un risque. On préfère une solution no-code même moins élégante.
• Besoin one-shot pour un test. Pour valider une hypothèse rapidement, un script collé suffit. On formalise seulement si le besoin reste.
• Performance critique sur cas simple. Parfois 10 lignes de CSS suffisent là où on serait tenté d'écrire 200 lignes de JS.

Comment on code dans Webflow chez Justa

1. Tout sur GitHub, jamais inline

Notre code custom vit dans des repositories GitHub par client. Chaque modification est un commit, chaque déploiement est une release. On ne colle jamais de scripts directement dans les pages Webflow autres que le bootstrap.

2. Hébergement via Cloudflare Pages ou jsDelivr

Le repo GitHub est connecté à Cloudflare Pages (préféré) ou exposé via jsDelivr. Webflow charge un seul script bootstrap qui pointe vers le bundle hébergé. Mise à jour par push, pas par copy-paste.

3. Code organisé par domaine

Plutôt qu'un fichier monolithique, on structure : `animations/`, `integrations/`, `forms/`, `analytics/`. Chaque module est isolé, testé indépendamment, chargé conditionnellement selon la page.

4. Performance comme contrainte

Tout script est chargé en defer ou async. Les bundles sont minifiés. Le impact sur le LCP et l'INP est mesuré avant déploiement. Pas de jQuery sur les nouveaux projets, vanilla JS uniquement.

5. Documentation systématique

Chaque script a un README qui explique : ce qu'il fait, où il est utilisé sur le site, comment le tester, comment le rollback. Quand on passe la main au client ou à un freelance, c'est lisible.

Les zones où on injecte du code dans Webflow

• Project Settings > Custom Code > Head Code. Pour les scripts à charger en priorité (analytics, fonts, polyfills).
• Project Settings > Custom Code > Footer Code. Pour les scripts non bloquants, chargés après le rendu.
• Page Settings > Custom Code. Pour les scripts spécifiques à une page.
• Embed element. Pour du HTML/JS contenu dans une partie spécifique du design.

Les limites qu'on gère

• Limite de caractères Webflow. Le plan gratuit limite à 300 caractères par champ custom code. Toujours vérifier le plan client. Sur Site Plan, la limite est levée.
• Pas de TypeScript natif. Webflow ne sait pas exécuter du TypeScript. On compile en JS avant déploiement (via Vite ou esbuild).
• Debugging plus complexe. Sans outils dev intégrés, le debug se fait dans les DevTools du navigateur. On instrumente avec des logs explicites.
• Risques de régression silencieuse. Une mise à jour Webflow peut casser un script qui marchait. Veille régulière, tests post-update.

Alternatives qu'on connaît aussi

• Finsweet Attributes. Notre premier réflexe pour des comportements CMS avancés sans coder.
• Wized. Quand le besoin dépasse le script et entre dans la logique d'application.
• Webflow Interactions. Pour les animations basiques, suffit largement.
• Memberstack ou Outseta. Pour de l'auth utilisateur sans coder le système d'authentification.