Because rendering decides what a crawler sees and how fast a visitor sees anything. The framework is a preference. Where the HTML gets built is an outcome. A React site can be excellent or invisible depending on that one decision, and most teams make it by accident rather than on purpose.
We have this conversation with almost every founder who arrives with a site that "should be ranking". The content is fine. The design is fine. The HTML that arrives at the browser is nearly empty, and everything real appears only after JavaScript runs.
So this is the comparison worth having. Not React against Vue, but static against server-rendered against client-rendered, and what each one costs you.
Static rendering builds the HTML for every page ahead of time, during a build. Server-side rendering builds the HTML fresh on each request. Both send a complete page to the browser. The difference is when the work happens, and that timing drives almost every tradeoff that follows.
Google's web.dev guidance on rendering describes static rendering as producing HTML files at build time for each URL. Server-side rendering instead renders the application on the server and sends complete HTML to the browser per request.
Client-side rendering is the third option and the one to be careful with. There, the server sends a mostly empty shell and the browser assembles the page with JavaScript. It is the default in a lot of modern tooling, which is exactly why it catches people out.
Speed and reliability, mostly. Because the page already exists as a file, there is no computation between the request and the response. Google's own documentation notes that static rendering "achieves a consistently fast TTFB, because the HTML for a page doesn't have to be dynamically generated." Fast and consistent are both doing work in that sentence.
Google also credits static rendering with fast First Contentful Paint and lower Total Blocking Time and Interaction to Next Paint, since the content arrives pre-built rather than being assembled in the browser.
That consistency is underrated. A server-rendered page is fast when the server is healthy and slow when it is not. A static file is the same speed on your busiest day as on your quietest. For a marketing site, that predictability is worth a great deal.
It also happens to be how our own blog works. Every article you read on this site is generated into static HTML at build time from our content database, rather than fetched in your browser. That is a deliberate choice, and the next few sections explain why.
Anything you cannot predict in advance. Google's guidance is direct about the limit: static rendering requires knowing all your URLs ahead of time, which becomes impractical for sites with a very large number of unique pages. If you cannot list the pages at build time, you cannot pre-build them.
The second cost is freshness. A static page reflects the moment it was built. If your content changes hourly, you either rebuild constantly or accept staleness. For a blog or a marketing site, a daily rebuild is fine. For live inventory or pricing, it is not.
Build time is the third. A site with tens of thousands of pages can take a long time to build, and every content edit waits on that. This is solvable with incremental builds, but it is a real constraint rather than a theoretical one.
Fresh content on demand, with a complete HTML response. SSR gives you a page built from live data at the moment of the request, which suits dashboards, search results, personalised pages, and anything driven by user state. Google notes it delivers fast First Contentful Paint and reduces the JavaScript shipped to clients.
The tradeoff Google names is straightforward: "generating pages on the server takes time, which can increase your page's TTFB." You are trading a compute step for freshness. That step is small on a good day and large under load.
Google also flags a subtler cost, which is that SSR can double the data being sent when application state is inlined into the HTML alongside the rendered markup. It is easy to ship the page and the data used to build the page, and pay for both.
Because the cost grows quietly as the app grows. Google puts it plainly: "The primary downside to client-side rendering is that the amount of JavaScript required tends to grow as an application grows." Nobody chooses a heavy bundle. It accumulates one feature at a time until the site is slow on the phones most people use.
Google's documentation lists the specific damage: large JavaScript bundles harm Interaction to Next Paint, First Contentful Paint gets delayed, and the whole thing is hard to optimize for mobile. Those are the metrics that decide whether a page feels usable.
Our position is that client-side rendering is a fine choice for an application behind a login and a poor choice for anything you want found. The moment a page needs to be discovered, cited, or shared, you are relying on someone else's willingness to run your JavaScript.
Static and server rendering hand Google finished HTML. Client rendering asks Google to run your code first. Google does run it, but not immediately. Its JavaScript SEO documentation describes three phases: crawling, rendering, and indexing, with pages queued for rendering in between.
That queue is the part people miss. Google says a page "may stay on this queue for a few seconds, but it can take longer than that." Rendering happens as Google's resources permit, using a headless Chromium browser, not as part of the initial crawl. Your content is indexed only after it comes back off the queue.
Google's own recommendation is unambiguous, and we quote it often: "Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript." Google saying pre-rendering is still a great idea, in Google's own JavaScript documentation, should settle the argument.
The phrase "not all bots" matters more every year. AI answer engines crawl too, and they are not all running a full browser. We went into that in detail in our piece on why AI crawlers miss JavaScript-rendered content.
Static, in almost every case. A marketing site has a knowable set of pages, content that changes on a human schedule rather than a per-second one, and a hard requirement to be crawlable. That is the exact profile static rendering was built for.
We take a firm line here because the alternative keeps producing the same failure. A team picks an application framework for a brochure site, ships client-side rendering by default, and then spends a year wondering why pages are indexed slowly and score badly on speed.
This is also why Webflow works so well for the sites we build. Publishing a Webflow site produces real HTML and CSS served from its hosting network, rather than a shell that assembles itself in the browser. The rendering question is answered correctly by default, which removes an entire category of problem before it starts.
When the page cannot exist until the request does. Personalised content, authenticated views, live search, real-time inventory, and anything that depends on who is asking. If two visitors must see different HTML at the same moment, static cannot do it alone.
Be honest about which pages those are. On most business sites it is a small handful, and the other ninety percent are the same for everyone. Rendering the whole site dynamically to serve a few dynamic pages is a common and expensive mistake.
The related question is where your content lives, because that shapes what is easy to pre-build. Our overview of headless CMS architecture covers how to keep content editable without forcing every page to be rendered on demand.
Yes, and most good architectures do. Modern frameworks let you choose per route, so your marketing pages, blog, and documentation are built statically while your account area and search render on the server. Google's rendering guidance also describes hybrid approaches such as streaming server rendering and progressive rehydration.
Our default is to start static and add dynamic rendering only where a page genuinely requires it. Starting dynamic and trying to make it static later is much harder, because assumptions about request-time data spread through the codebase.
The practical test is simple. For each template, ask whether the HTML depends on who is asking. If it does not, build it ahead of time. Doing that consistently is usually worth more to your Largest Contentful Paint than any amount of image tuning.
Find out what you actually ship. Open your most important page, view the raw source rather than the inspector, and search for a sentence from your main content. If it is not there, your content is arriving by JavaScript and everything above applies to you.
If it is missing, the fix is usually smaller than a rebuild. Many frameworks can pre-render existing routes with a configuration change, and moving your highest-value pages first gets most of the benefit.
If you check and are not sure what you are looking at, or the answer is bad and you would rather not untangle it alone, we are happy to walk through it with you. Let's talk. You can find our team at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.