Static landing page or React SPA: the technical choice that tanks (or saves) your conversion rate

A React landing page can be built in two very different ways: as a single-page application fully rendered on the client (a SPA, like a project started with Create React App), or as a page pre-generated at build time and served already finished (static rendering, SSG). From the visitor's side, the difference is invisible… until they click an ad and wait in front of a blank screen. This architecture choice, often settled by habit or by the default of the tool used, has a direct impact on perceived speed, on Core Web Vitals and on SEO indexing — three levers that carry a lot of weight for a page whose only job is to convert.

What "static" and "SPA" actually mean

A statically rendered page (SSG, for "static site generation") is entirely built at deploy time: the full HTML — headings, copy, images, structure — already exists as a file, ready to be sent as-is by a CDN on the very first request. JavaScript only steps in afterwards, to "hydrate" the few genuinely interactive elements: a form, an FAQ accordion, a countdown timer.

A client-rendered SPA (CSR, for "client-side rendering") works the other way round: the server sends a near-empty HTML shell — often a plain <div id="root"></div> — plus a JavaScript package, the "bundle". The browser has to download it, parse it, execute it, then build the entire page in memory before a single word can appear. Everything, including the static headline at the top of the page, waits for React to finish its work.

Perceived speed: conversion factor number one

Back in 1968, psychologist Robert B. Miller laid out, in what is now a classic study of human-computer interaction, three thresholds for perceived response time: under 0.1 second, the reaction feels instantaneous; up to 1 second, the user's train of thought stays uninterrupted; past 10 seconds, their attention drops off — Miller (1968), "Response Time in Man-Computer Conversational Transactions". A SPA showing a blank screen or a spinner while its JavaScript bundle downloads and then executes very often blows past that one-second threshold on a mobile connection — before the first word is even readable.

This is not just a comfort issue: a study by Gallino, Karacaoglu and Moreno, published in 2022 in the journal Operations Research, measured the effect of these "in-process" delays on online purchase behavior — Gallino, Karacaoglu, Moreno (2022), "Need for Speed: The Impact of In-Process Delays on Customer Behavior in Online Retail". The finding: slowdowns mechanically reduce sales, and visitor sensitivity varies by stage of the journey — and landing right after clicking an ad is precisely the moment attention is most volatile. We break down the numbers in our article on load speed and conversion.

Core Web Vitals: why a SPA starts with a structural handicap

LCP (Largest Contentful Paint, the display of the main content — see our dedicated LCP article) is measured the moment the largest visible element appears on screen. On a static page, that element is part of the initial HTML: it displays as soon as the file arrives. On a SPA, LCP can only happen after the JavaScript bundle is fully downloaded, parsed and executed — three steps that stack up before the first useful pixel.

JavaScript execution also weighs on INP, the responsiveness metric (see our article on INP): on a low-end smartphone, parsing and executing several hundred kilobytes of JavaScript can occupy the CPU for several seconds, during which the page stays unresponsive to taps. And if content "jumps" once hydration finishes — a banner shifting back, a button moving — CLS (see our article on CLS) takes the hit next.

SEO: Google eventually catches up, other bots much less so

Googlebot can execute JavaScript, but in two passes: a first pass indexes the raw HTML, a second — deferred, sometimes by several days — executes the JavaScript to index client-rendered content. For a landing page chasing a fast ranking, or one that depends on its Google Ads Quality Score, that delay is an avoidable handicap. We cover the mechanics in our landing page SEO guide.

The problem is even sharper for bots that execute no JavaScript at all: the sharing crawlers of Meta, LinkedIn or WhatsApp read the raw HTML to generate a shared link's preview (see our article on the Open Graph image). A pure SPA, with no pre-rendered HTML, often shows an empty or generic preview when someone clicks a Facebook or LinkedIn link — an expensive detail when the landing page is precisely meant to receive paid traffic from those platforms.

When SPA-like logic still makes sense

The whole landing page doesn't need to become a pure SPA for application-style logic to have a place. A multi-step configurator, a real-time pricing calculator, or an interactive product demo (see our article on the interactive calculator) genuinely need client-side state managed by React. The right architecture doesn't pit static against SPA: it isolates the application logic in one specific component, while the rest of the page — headline, arguments, social proof, FAQ — stays pure HTML, visible instantly.

The middle ground that wins: static by default, interactive on demand

This is the principle that Next.js and generators like Astro have popularized under the name selective hydration, or an "islands" architecture: the whole page is pre-generated as static HTML at build time, and React only steps in — only "hydrates" — the components that genuinely need it: the capture form, the FAQ accordion, an offer's countdown timer. The visitor gets a near-instant LCP because 90% of the page never waits on JavaScript, and still gets React's interactivity exactly where it serves conversion.

This is exactly the architecture behind the 10 LanderKit templates: Next.js pages statically generated at build time, each built for a specific business — from a SaaS waitlist to a single-product e-commerce page — with a live demo you can check before buying at /demo/saas-waitlist. You get the full source code, deploy for free on Vercel, and never have to choose between speed and interactivity: the architecture already made that trade-off for you, in the right direction.