Pourquoi un simple formulaire de contact, sur un site entièrement pré-rendu en statique, met-il plus d’une seconde à afficher son message de confirmation ? La question s’est posée sur un site vitrine construit avec Gatsby et WordPress en headless, où chaque page se charge en moins de 300 millisecondes — sauf au moment précis où l’utilisateur clique sur « Envoyer ».
La réponse tenait en deux appels réseau exécutés l’un après l’autre plutôt qu’en parallèle, un schéma fréquent dès qu’un formulaire marketing s’ajoute à un front statique sans qu’on prenne le temps de mesurer son coût réel.
Le cas observé
Le formulaire, embarqué via le composant React officiel @hubspot/forms, soumettait d’abord les données au endpoint de collecte de HubSpot (api.hsforms.com), attendait sa réponse, puis déclenchait un second appel vers une fonction serverless Netlify chargée de notifier une équipe interne sur un canal Slack. Les deux appels s’enchaînaient de façon strictement séquentielle dans le gestionnaire de soumission.
Mesuré avec l’onglet Réseau des outils de développement, le temps total entre le clic sur le bouton et l’affichage du message de succès atteignait 1,4 seconde en moyenne, dont environ 900 millisecondes pour le seul appel HubSpot et 500 millisecondes pour la fonction Netlify. Sur mobile avec une connexion 4G dégradée, ce total dépassait régulièrement les 2,5 secondes.
Pourquoi la génération statique ne protège pas de ce problème
Gatsby pré-rend les pages en HTML au moment du build, ce qui élimine toute latence de rendu côté serveur pour la navigation. Mais un formulaire reste, par nature, une interaction côté client qui déclenche des appels réseau au runtime, indépendamment de la stratégie de rendu de la page qui l’héberge. La performance perçue d’un site headless ne se limite donc pas au temps de chargement initial : elle inclut chaque interaction qui suit.
Le correctif : découpler l’appel secondaire
La notification Slack n’a aucune raison de bloquer l’affichage du message de confirmation à l’utilisateur : elle concerne une équipe interne, pas la personne qui vient de remplir le formulaire. Le correctif a consisté à rendre cet appel réellement asynchrone, sans attendre sa résolution avant de mettre à jour l’interface :
async function handleSubmit(formData) {
const hubspotResponse = await submitToHubspot(formData);
if (hubspotResponse.ok) {
setStatus('success');
// Notification interne : on ne bloque plus l'UI dessus.
notifySlack(formData).catch((err) =>
console.error('Notification Slack en echec', err)
);
}
}Le message de succès s’affiche désormais dès que HubSpot confirme la réception, sans attendre l’issue de la notification Slack qui continue en arrière-plan. Le temps perçu par l’utilisateur est passé de 1,4 seconde à environ 900 millisecondes — exactement le temps de l’appel HubSpot, qui reste, lui, incompressible sans changer de fournisseur de formulaires.
Un garde-fou nécessaire
Rendre un appel asynchrone sans surveillance revient à perdre silencieusement des notifications en cas d’échec réseau. Un journal d’erreurs côté fonction serverless, couplé à une nouvelle tentative automatique après un court délai, évite que ce découplage ne se transforme en trou noir pour les notifications ratées.
Ce que ce cas ne couvre pas
Cette optimisation porte sur la latence perçue, pas sur la stratégie de génération de leads elle-même : le choix des champs du formulaire, la segmentation dans HubSpot ou le scoring des prospects restent des sujets indépendants, qui n’ont pas d’incidence sur le temps de réponse mesuré ici.
- Deux appels réseau séquentiels doublent presque mécaniquement la latence perçue.
- Seul l’appel qui conditionne réellement le retour utilisateur doit bloquer l’interface.
- Un appel rendu asynchrone doit rester surveillé, sous peine de pertes silencieuses.
Sur un formulaire, chaque aller-retour compte double : une fois pour la donnée qui doit vraiment arriver à destination, une fois pour la confiance que l’utilisateur accorde au site en attendant la confirmation.
Notre verdict
Un front statique élimine la latence de rendu, pas celle des interactions. Dès qu’un formulaire déclenche plusieurs appels réseau, seule leur orchestration détermine la vitesse perçue — et un simple découplage entre l’appel bloquant et l’appel secondaire suffit, la plupart du temps, à retrouver une expérience à la hauteur du reste du site.
