Choosing Next.js over React.js

frontendreactnextjsperformanceseo

Context

Our legacy marketing site was built as a Client-Side Rendered (CSR) React SPA. As our content grew, we saw a decline in SEO rankings and significant 'Cumulative Layout Shift' (CLS) on slower mobile connections. We needed a solution that maintained our React component library while solving for performance and indexability.

Decision

Migrate the frontend architecture to Next.js to leverage Server-Side Rendering (SSR) and Incremental Static Regeneration (ISR).

Alternatives Considered

Vanilla React with Vite & Prerender.io

Pros
  • Maintains existing build pipeline
  • Cheaper hosting on standard CDNs
Cons
  • Prerendering is fragile and difficult to debug
  • No native support for Image Optimization
  • Manual routing management

Remix

Pros
  • Excellent handling of form actions and mutations
  • Built-in web standards focus
Cons
  • Smaller ecosystem and plugin community
  • Steeper learning curve for teams used to the 'Next' way of doing things

Reasoning

Next.js provides a production-ready framework that solves the 'empty root div' problem of standard React. By moving data fetching to the server-side, we send fully formed HTML to the browser, which drastically improves Time to Interactive (TTI) and allows search engine crawlers to index our content without executing heavy JavaScript.

The React SPA Bottleneck

While React is excellent for interactive dashboards, using it for a public-facing website created a “loading spinner” culture.

  • SEO Limitations: Most crawlers struggled to parse our content because it was injected into the DOM after the initial page load.
  • The Largest Contentful Paint (LCP) Issue: Users on 3G networks were staring at a blank screen for 4+ seconds while the main bundle downloaded.

Why Next.js?

We identified three “killer features” that made the transition a necessity for our growth:

1. Hybrid Rendering (SSR + ISR)

We no longer had to choose between static and dynamic.

  • SSR (Server-Side Rendering): Used for user-specific data (profiles).
  • ISR (Incremental Static Regeneration): Used for blog posts. This allowed us to update content in the background without a full site rebuild.

2. The Next/Image Component

One of our biggest performance drains was unoptimized hero images. The native Next.js Image component handles automatic resizing, WebP conversion, and lazy loading out of the box.

3. Middleware & Edge Functions

We moved our A/B testing logic and geolocation redirects to the “Edge.” By running this logic closer to the user, we eliminated the “flash of unstyled content” (FOUC) that occurred when we handled these via React useEffect.

Implementation & Transition

The migration was handled in phases to minimize downtime:

  • Phase 1: Setup a monorepo and moved the UI Kit into a shared package.
  • Phase 2: Leveraged Next.js rewrites to serve the new Next.js pages alongside the old React SPA during the transition.
  • Phase 3: Switched data fetching from useEffect hooks to getServerSideProps and getStaticProps.

Results & Impact

  • Lighthouse Performance Score: Jumped from 62 to 96 on mobile.
  • Organic Search Traffic: We saw a 40% increase in indexed pages within the first month.
  • Bundle Size: Reduced initial JS execution by 28% through automatic code-splitting.
  • Developer Experience: The “File-based Routing” system reduced the complexity of our App.js, making it easier for new hires to find specific views.

The Road Ahead

With the move to Next.js 14+, we are now looking into React Server Components (RSC). This will allow us to move even more logic off the client-side, reducing the JavaScript hydrate-cost to nearly zero for our purely informational pages.

All decisions