Why Your Marketing Site Should Be Server-Rendered — Full Article
The problem with client-side rendering
A client-rendered site sends an almost empty HTML document and a large JavaScript bundle. The browser downloads that bundle, executes it, fetches your content over the network, and only then paints anything readable. For a visitor on a fast laptop this costs a second. For a crawler it costs a place in a rendering queue that can run days behind the initial crawl, and for a visitor on a mid-range phone over mobile data it costs a bounce. Nothing about your copy, your headings or your internal links exists in that first response — which means for a short window, the most important page on your site is a blank div.
The four strategies, side by side
Every rendering approach is a trade between when the HTML gets built and how fresh it is. This is what each one gives you in practice on a marketing site.
Rendering strategies compared for a marketing site| Strategy | HTML built | What a crawler receives | TTFB | Best for |
|---|
| CSR (client-side) | In the browser, per visit | Empty shell + JS bundle | Fast, but blank | Logged-in dashboards |
|---|
| SSR (server-side) | On the server, per request | Full HTML | Moderate | Personalized or real-time pages |
|---|
| SSG (static) | Once, at build time | Full HTML | Fastest | Marketing and service pages |
|---|
| ISR (incremental) | At build, revalidated on a timer | Full HTML | Fastest | Blogs and large catalogues |
|---|
For marketing pages, static wins almost every time
Your homepage, service pages and about page change a few times a quarter. There is no reason to rebuild that HTML on every single request, and even less reason to rebuild it in each visitor's browser. Pre-render them at build time and every request becomes a static file read from a CDN edge node. The content is complete in the first response, Time to First Byte drops to whatever the network costs, and the server does no work at all. If a page needs to change more often than your deploy cadence, use ISR with a revalidation window rather than reaching for full server rendering.
What this does to Core Web Vitals
Rendering strategy shows up directly in the three metrics Google reports. Largest Contentful Paint improves because the hero markup is in the first response instead of waiting behind a bundle. Cumulative Layout Shift improves because server-rendered markup can reserve space for images and fonts before paint. Interaction to Next Paint improves because you are hydrating two or three interactive components instead of an entire application. These are the thresholds to hold yourself to.
Core Web Vitals thresholds (75th percentile of real users)| Metric | What it measures | Good | Needs work | Poor |
|---|
| LCP | Time until the main content paints | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
|---|
| INP | Responsiveness to interactions | ≤ 200ms | 200ms – 500ms | > 500ms |
|---|
| CLS | Unexpected layout movement | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
|---|
Ship JavaScript only where the page needs it
Server rendering stops paying off the moment you hydrate the whole page anyway. The discipline that matters is drawing the client boundary as tightly as possible: a contact form needs state and event handlers, a mobile menu needs a toggle, and a pricing calculator needs both. Headings, body copy, cards, breadcrumbs and footers need none of it. On the sites we build, the interactive surface is usually two or three components, which keeps the hydration cost close to zero while the rest of the page stays pure HTML.
How to check what you are actually shipping
Open your page, disable JavaScript, and reload. Whatever remains is what a crawler is guaranteed to see without waiting in a render queue. Then view source — not the inspector, which shows the DOM after scripts run — and search for your H1 and your body copy. If they are missing from the raw HTML, your content is dependent on JavaScript execution. Finally, run the page through Lighthouse on mobile throttling and look at the JavaScript execution time rather than the score, because that number is what your visitors on real phones are paying.
The migration is smaller than it looks
Most teams assume this means a rewrite. Usually it means moving the pages that matter for search onto a server-rendered framework first, leaving the application behind whatever login wall it already lives behind. Marketing pages have few dependencies and no session state, so they port quickly. The care goes into the URL inventory and redirect map, not the components.
Comments
Loading comments…
Sign in to join the conversation.