Server-Side Rendering Won: Stop Shipping JavaScript You Don't Need

We spent six months rebuilding a core product page as a React single-page application (SPA), only to see our Google Lighthouse scores drop by 30 points and search traffic halve. Marketing was furious. We thought we were building for speed, but we built for developer convenience, costing us millions in lost organic reach.

Why this matters in 2026

The web is mostly mobile. Most users aren't on fiber connections with flagship phones. They're on LTE or patchy Wi-Fi, using mid-range Android devices. Google's Core Web Vitals, driven by mobile-first indexing, directly impact your search ranking and ad spend efficiency. Your users feel every millisecond of a slow page load, especially when JavaScript takes over their phone's CPU. Shipping megabytes of JavaScript for client-side rendering isn't just a technical debt, it's a direct hit to your bottom line, user acquisition, and retention.

Three things I learned shipping this in production

Perceived Performance Kills More Than Just SEO

I led a team at an e-commerce startup, building out product detail pages. We were all in on client-side React, using Create React App 5.0.1. The idea was a "rich, interactive experience." What we got was a blank white screen for 2-3 seconds on an average Android phone, followed by a sudden flash of content. Our Google Lighthouse LCP (Largest Contentful Paint) score for these pages hovered around 4.5 seconds. Our bounce rate for mobile users spiked 15% on these new pages.

This wasn't just an SEO problem, though our organic search ranking for key product terms tanked. It was a user experience disaster. Users didn't wait around for the JavaScript bundle, roughly 800KB gzipped, to download, parse, and execute. They just left. We had to pivot. We re-wrote those pages using Next.js 13.5.6, specifically leveraging the App Router and React Server Components. The server rendered the initial HTML, sending a minimal amount of JavaScript for interactivity. Our LCP dropped to under 1.8 seconds, and the page felt instant. The bounce rate normalized within weeks, and organic traffic started climbing back.

Here's a simplified example of how a React Server Component in Next.js serves content directly from the server, minimizing client-side JavaScript:

// app/products/[id]/page.js
import { getProductDetails } from '../../../lib/data';
export default async function ProductPage({ params }) {
  const product = await getProductDetails(params.id);
  if (!product) {
    return <div>Product not found.</div>;
  }
  return (
    <div className="container">
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <img src={product.imageUrl} alt={product.name} width={500} height={500} />
      <p>Price: ${product.price.toFixed(2)}</p>
      {/ Add a client component for interactive elements, e.g., an "Add to Cart" button /}
      {/ <AddToCartButton productId={product.id} /> /}
    </div>
  );
}

This component fetches data on the server and renders the HTML. The client only receives the final HTML and any necessary JavaScript for interactive components, which are explicitly marked with "use client". This approach drastically reduces the initial JavaScript payload and improves perceived performance, because the user sees meaningful content much faster. We didn't need to ship the entire React framework and application logic to render static product details.

The Cost of Client-Side Hydration is Real

At a fintech company, we built a complex dashboard for financial analysts. It was a React 18.2.0 application, heavily reliant on Redux Toolkit 1.9.5 for state management. The initial JavaScript bundle, including all dependencies, weighed in at over 2MB gzipped. On a high-end desktop, it was fine. On a 2018 iPad or a mid-range Android phone, Time To Interactive (TTI) was consistently 8-10 seconds. Users would see the layout, but nothing was clickable, nothing responded.

The problem wasn't just download speed, it was the hydration cost. The browser had to download the 2MB bundle, parse it, execute it, and then React had to "hydrate" the entire DOM, attaching event listeners and re-rendering virtual DOM trees. This process is CPU-intensive and blocks the main thread. We were effectively paying for CDN delivery of code that then choked the client's CPU, costing us not just in slower user interactions, but in actual infrastructure. Our CDN bill for this app alone was roughly $1,500 more per month than comparable server-rendered applications, simply because of the sheer volume of JavaScript we were pushing.

We eventually migrated parts of this dashboard to Astro 4.5.0, using its "islands architecture." This allowed us to server-render most of the static layout and only send interactive components as isolated "islands" of JavaScript. For example, a complex charting widget might be an island, but the static table headers and labels around it were plain HTML. This significantly reduced the initial JavaScript load and hydration time. It meant more thought upfront about what truly needed client-side interactivity, but it paid off in performance and reduced operational costs from less data transfer. The goal shifted from "everything is a component" to "only interactive things are components."

DX is a Trap if It Doesn't Map to User Value

I've seen countless teams prioritize "developer experience" (DX) over actual user experience (UX) or operational simplicity. A previous team spent weeks building a custom Webpack 5.89.0 configuration for a client-side rendered application. They wanted perfect code splitting, lazy loading, and all the "modern" optimizations. The goal was developer happiness, a "modern stack" to attract talent. The result was a fragile build system that broke on minor dependency updates, required deep Webpack knowledge to maintain, and still delivered mediocre performance. The developer experience was great for the initial build, but a nightmare for maintenance and debugging.

The real trap is when DX becomes an end in itself, rather than a means to ship value faster and more reliably to users. When we migrated a legacy PHP application to a shiny new React SPA, purely client-side, it caused a 20% drop in organic traffic for key landing pages. Why? Because the JavaScript took too long to execute, and Google's crawlers, at the time, struggled with fully client-rendered content. It took us eight months of frantic re-optimization, server-side pre-rendering hacks, and extensive SEO work to recover that traffic. The initial "developer happiness" of working with a modern SPA quickly turned into developer misery trying to fix the business impact.

Modern SSR frameworks like Next.js, Remix 2.8.0, or SvelteKit 5.0.0 offer an integrated developer experience that does align with user value. They handle routing, data fetching, and rendering in a cohesive way, abstracting away much of the complex build tooling. You get the benefits of a component-based UI without the performance penalties of a purely client-side application. The DX is good, but it's good because it makes it easier to ship fast, accessible, and SEO-friendly applications.

What I would do differently if I started today

If I were building any new web application from scratch today, I would default to server-side rendering or static site generation for every single page, unless there was an explicit, measurable reason not to. That means starting with a framework like Next.js, Remix, SvelteKit, or Astro. I would push for an HTML-first approach, using JavaScript only for progressive enhancement where interactivity is absolutely required. The idea that you need a "full SPA" for a dynamic experience is a myth. Most interactions can be handled with minimal client-side JavaScript, or even just HTML form submissions and server redirects. Build your core experience with HTML, then sprinkle in interactivity where it truly adds value, rather than building everything in JavaScript and then trying to patch performance.

What this looks like for your team

1. Audit your core conversion funnels for LCP and FCP on mobile devices. Use Google Lighthouse, PageSpeed Insights, or WebPageTest.org. If your critical pages (landing pages, product pages, checkout flows) are above 2.5 seconds LCP, you have a problem that likely SSR can fix. 2. Experiment with a small, non-critical page using a modern SSR framework. Pick a low-traffic page, perhaps an informational blog post or an "about us" page, and rebuild it in Next.js, Remix, SvelteKit, or Astro. Measure the performance gains and evaluate the developer experience. This low-risk approach lets you learn without disrupting core business. 3. Re-evaluate your build tooling complexity. If your frontend team spends more time maintaining Webpack configurations or custom build scripts than shipping features, it's a red flag. Consider migrating to a framework that provides an opinionated, integrated build system, reducing maintenance overhead and freeing up engineering cycles for actual product work.

I write about engineering decisions and production systems at devwithzach.