# HubSpot et un bloc Gutenberg : afficher un formulaire sans ralentir l’éditeur

> Charger le script HubSpot Forms en différé dans un bloc dynamique, avec une mesure concrète de l'impact sur les performances de l'éditeur Gutenberg.

- Auteur : WordPress Développement
- Publié le : 2021-01-21
- Mis à jour le : 2021-01-21
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/hubspot-bloc-gutenberg-formulaire-sans-ralentir-editeur/

## L’essentiel

- Script HubSpot chargé en différé, jamais dans l'éditeur
- Aperçu statique côté édition, formulaire réel côté front
- Gain mesuré sur le temps de chargement de l'éditeur

Deux blocs HubSpot suffisaient à faire ramer l'éditeur d'un site institutionnel : chaque bloc rechargeait son propre script `js.hsforms.net`, chacun réinitialisant son iframe, sans aucune mise en cache entre eux. Le contraste avec le front, rapide, rendait le problème d'autant plus visible pour l'équipe éditoriale qui perdait de longues secondes à chaque ouverture d'article.

Comparé à un simple copier-coller du code d'intégration HubSpot, un bloc dynamique permet de séparer clairement ce qui doit se charger en édition (un aperçu léger, statique) de ce qui doit se charger côté front (le vrai formulaire interactif) — la source du ralentissement observé.

## Le script HubSpot n'a rien à faire dans l'éditeur

Le composant `ServerSideRender`, souvent utilisé pour prévisualiser un bloc dynamique dans l'éditeur, exécute le `render_callback` PHP exactement comme sur le front. Si ce rendu inclut le script HubSpot et son appel à `hbspt.forms.create()`, l'éditeur charge et exécute un formulaire complet à chaque frappe de texte dans l'article, ce qui explique la lenteur constatée.

La bonne pratique consiste à ne jamais charger de scripts tiers lourds via `ServerSideRender` : l'aperçu en édition doit rester une simple maquette visuelle, sans appel réseau vers HubSpot.

## Séparer aperçu d'édition et rendu front

Le bloc utilise deux chemins de rendu distincts, ce qui demande un peu plus de code mais règle le problème à la racine.

```
// edit.js — aperçu statique, aucun appel réseau
export default function Edit( { attributes } ) {
    return (
        <div className="wpm-hubspot-apercu">
            <p>Formulaire HubSpot : { attributes.formId }</p>
            <p><em>Aperçu simplifié — le vrai formulaire s'affiche côté front.</em></p>
        </div>
    );
}
```

> L'essentiel à retenir : Script HubSpot chargé en différé, jamais dans l'éditeur ; Aperçu statique côté édition, formulaire réel côté front ; Gain mesuré sur le temps de chargement de l'éditeur

## Charger le script HubSpot en différé côté front

Côté `render_callback`, le script HubSpot n'est enqueue qu'en `footer`, avec l'attribut `defer`, pour ne bloquer ni le rendu ni les autres scripts de la page :

```
function wpmoderne_render_hubspot_form( $attributes ) {
    wp_enqueue_script(
        'hubspot-forms',
        'https://js.hsforms.net/forms/embed/v2.js',
        array(),
        null,
        true // dans le footer
    );

    $form_id = esc_attr( $attributes['formId'] );
    $portal_id = esc_attr( $attributes['portalId'] );

    return sprintf(
        '<div class="wpm-hubspot-form" data-form-id="%s" data-portal-id="%s"></div>
        <script>
        window.addEventListener("load", function () {
            if (window.hbspt) {
                hbspt.forms.create({ portalId: "%s", formId: "%s", target: ".wpm-hubspot-form" });
            }
        });
        </script>',
        $form_id, $portal_id, $portal_id, $form_id
    );
}
```

L'initialisation attend l'évènement `load` plutôt que de s'exécuter immédiatement : cela laisse le temps au script HubSpot externe de se charger sans bloquer le rendu du reste de la page.

## Mesurer l'impact avant et après

Le test s'est fait sur un article contenant trois blocs HubSpot, chronométré à l'aide de l'onglet Performance du navigateur, sur la même machine et la même connexion :

- Avant correctif : 3,1 secondes pour que l'éditeur devienne interactif, avec trois requêtes vers `js.hsforms.net` et trois initialisations de formulaire en parallèle.
- Après correctif : 1,7 seconde, aucune requête HubSpot déclenchée avant l'affichage du front.
- Côté front, aucune différence perceptible, le script se chargeant de toute façon en tâche de fond pendant que la page s'affiche.

## Ce que cet article ne couvre pas

La configuration du CRM HubSpot lui-même — création des formulaires, mapping des propriétés de contact — se fait entièrement côté plateforme HubSpot et ne dépend pas de l'implémentation du bloc. Les workflows marketing déclenchés après soumission relèvent de la même logique : une fois le formulaire soumis, HubSpot prend le relais indépendamment du code WordPress.

## En résumé

Le ralentissement de l'éditeur n'avait rien à voir avec HubSpot en tant que service : il venait d'un choix d'implémentation qui exécutait, en édition, exactement le même code lourd qu'en production. Séparer clairement l'aperçu d'édition du rendu front règle ce type de problème pour n'importe quel bloc qui embarque un script tiers volumineux.