Landing page statique ou SPA React : le choix technique qui plombe (ou sauve) votre taux de conversion

Une landing page en React se construit de deux façons très différentes : en application monopage entièrement rendue côté client (SPA, comme un projet démarré avec Create React App), ou en page pré-générée au moment du build et servie déjà prête (rendu statique, SSG). Vu du visiteur, la différence est invisible… jusqu’à ce qu’il clique sur une publicité et patiente devant un écran blanc. Ce choix d’architecture, souvent tranché par habitude ou par défaut de l’outil utilisé, a un impact direct sur la vitesse perçue, sur les Core Web Vitals et sur l’indexation SEO — trois leviers qui pèsent lourd sur le taux de conversion d’une page dont l’unique métier est de convertir.

Ce que « statique » et « SPA » veulent dire, concrètement

Une page en rendu statique (SSG, pour « static site generation ») est entièrement construite au moment du build : le HTML complet — titres, textes, images, structure — existe déjà comme fichier, prêt à être envoyé tel quel par un CDN dès la première requête. Le JavaScript n’intervient qu’ensuite, pour « hydrater » les quelques éléments réellement interactifs : un formulaire, un accordéon de FAQ, un compte à rebours.

Une SPA en rendu client (CSR, pour « client-side rendering ») fonctionne à l’inverse : le serveur envoie un HTML quasi vide — souvent une simple balise <div id="root"></div> — accompagné d’un paquet JavaScript, le « bundle ». Le navigateur doit le télécharger, l’analyser, l’exécuter, puis construire la page entière en mémoire avant que le moindre mot ne s’affiche à l’écran. Tout, y compris le titre statique en haut de page, attend que React ait fini son travail.

La vitesse perçue : l’enjeu de conversion numéro un

Dès 1968, le psychologue Robert B. Miller posait, dans une étude désormais classique de l’interaction homme-machine, trois seuils de perception du temps de réponse : en dessous de 0,1 seconde, l’utilisateur perçoit une réaction instantanée ; jusqu’à 1 seconde, le fil de sa pensée n’est pas interrompu ; au-delà de 10 secondes, son attention décroche — Miller (1968), « Response Time in Man-Computer Conversational Transactions ». Une SPA qui affiche un écran blanc ou un spineur pendant le téléchargement puis l’exécution de son bundle JavaScript franchit très souvent ce seuil d’une seconde sur une connexion mobile — avant même que le premier mot ne soit lisible.

Ce n’est pas qu’une question de confort : une étude de Gallino, Karacaoglu et Moreno, publiée en 2022 dans la revue Operations Research, a mesuré l’effet de ces délais « en cours de parcours » sur le comportement d’achat en ligne — Gallino, Karacaoglu, Moreno (2022), « Need for Speed: The Impact of In-Process Delays on Customer Behavior in Online Retail ». Résultat : les ralentissements font mécaniquement baisser les ventes, avec une sensibilité des visiteurs qui varie selon l’étape du parcours — et l’arrivée sur une landing page, juste après le clic sur une publicité, est précisément le moment où l’attention est la plus volatile. Nous détaillons les chiffres dans notre article sur la vitesse de chargement et la conversion.

Core Web Vitals : pourquoi une SPA part avec un handicap structurel

Le LCP (Largest Contentful Paint, l’affichage du contenu principal — voir notre article dédié au LCP) se mesure au moment où l’élément le plus visible apparaît à l’écran. Sur une page statique, cet élément fait partie du HTML initial : il s’affiche dès que le fichier arrive. Sur une SPA, le LCP ne peut survenir qu’après téléchargement, analyse et exécution complète du bundle JavaScript — trois étapes qui s’additionnent avant le premier pixel utile.

L’exécution du JavaScript pèse aussi sur l’INP, la mesure de réactivité (voir notre article sur l’INP) : sur un smartphone d’entrée de gamme, analyser et exécuter plusieurs centaines de kilo-octets de JavaScript peut occuper le processeur pendant plusieurs secondes, période durant laquelle la page reste figée aux interactions. Et si le contenu « saute » à l’écran une fois l’hydratation terminée — un bandeau qui recule, un bouton qui se décale — c’est le CLS (voir notre article sur le CLS) qui se dégrade à son tour.

Le SEO : Google finit par s’en sortir, les autres robots beaucoup moins

Googlebot sait exécuter du JavaScript, mais en deux temps : une première passe indexe le HTML brut, une seconde — différée, parfois de plusieurs jours — exécute le JavaScript pour indexer le contenu généré côté client. Pour une landing page qui vise un classement rapide ou qui dépend du Quality Score de Google Ads, ce délai est un handicap évitable. Nous détaillons la mécanique dans notre guide SEO landing page.

Le problème est plus net encore pour les robots qui n’exécutent aucun JavaScript : les crawlers de partage de Meta, LinkedIn ou WhatsApp lisent le HTML brut pour générer l’aperçu d’un lien partagé (voir notre article sur l’image Open Graph). Une SPA pure, sans HTML pré-rendu, affiche souvent un aperçu vide ou générique au clic sur un lien Facebook ou LinkedIn — un détail qui coûte cher quand la landing page est justement destinée à recevoir du trafic publicitaire depuis ces plateformes.

Quand une logique proche de la SPA garde du sens

Toute la landing page ne doit pas devenir un pur SPA pour qu’une logique d’application ait sa place. Un configurateur à plusieurs étapes, un simulateur de prix avec calculs en temps réel ou une démonstration produit interactive (voir notre article sur le calculateur interactif) ont besoin d’un vrai état côté client, géré par React. La bonne architecture n’oppose pas statique et SPA : elle isole la logique applicative dans un composant précis, pendant que le reste de la page — titre, arguments, preuve sociale, FAQ — reste du HTML pur, visible instantanément.

L’entre-deux qui gagne : statique par défaut, interactif à la demande

C’est le principe que Next.js et des générateurs comme Astro ont généralisé sous le nom d’hydratation sélective, ou d’architecture en « îlots » : la page entière est pré-générée en HTML statique au moment du build, et React n’intervient — ne « s’hydrate » — que sur les composants qui en ont réellement besoin : le formulaire de capture, l’accordéon de FAQ, le compte à rebours d’une offre. Le visiteur obtient un LCP quasi instantané parce que 90 % de la page n’attend jamais JavaScript, et récupère l’interactivité React exactement là où elle sert la conversion.

C’est très exactement l’architecture des 10 templates LanderKit : des pages Next.js générées en statique au build, chacune pensée pour un métier précis — de la liste d’attente SaaS à la vente e-commerce monoproduit — avec une démo live consultable avant achat sur /demo/saas-waitlist. Vous récupérez le code source complet, vous déployez gratuitement sur Vercel, et vous n’avez jamais à choisir entre vitesse et interactivité : l’architecture fait déjà le compromis pour vous, dans le bon sens.