Skip to main content

Next.js vs React.js Performance Analysis

· 13 min read
Semih Ozden

Next.js vs React.js Performance Analysis

Back in the early days of the internet, making websites fast was pretty straightforward. Pages were static, and the most exciting thing happening might be a flashy banner ad. However, as the internet grew up, so did our aspirations. Nowadays, it's not just about creating web pages; it's about crafting meaningful experiences. The speed at which pages load and optimizing for search engines (SEO) are just as crucial as the content itself.

This brings us to a significant decision between React and Next.js, one that has practical consequences in the real world. Let's dive into how these frameworks handle rendering and see how they impact performance, user experience, and SEO, ultimately deciding which one comes out on top.

React.js vs. Next.js Rendering Comparison​

When someone visits your website, their browser eagerly waits for your server to send over a package of code that it can then turn into a visible page.

In a classic React app, this whole process relies heavily on what's called Client-Side Rendering. The server sends a basic HTML outline with links to JavaScript files. Most of the heavy lifting for rendering is left to the user's browser, which has to fetch, understand, and finally display the content. This sometimes results in a noticeable delay before the user gets to see the complete and interactive page.

Now, let's contrast this with Next.js, where the focus is on Server-Side Rendering. Here, the server takes on the bulk of the workload. When a user asks for a page, the content gets "pre-rendered" on the server, and a fully formed HTML page is sent straight to the browser. This means the user gets to see the content faster, even though it's not fully interactive right away. The initial page load is quicker, and shortly after, the JavaScript kicks in, making the page fully interactive.

Next.js consumes server resources, thereby offering a faster site to the client, but it comes with a cost for the server delivering the site. On the other hand, Pure React is rendered on the client side, which might be a bit slower but it's a cost-saving approach for whoever serves the site. We can conclude that in the end, the choice between the two is entirely dependent on the business and use-case requirements.

Comparison with Code Examples​

In the example below, you'll notice that Next.js does server-side rendering using the getServerSideProps function, which grabs data from the server before creating the webpage. This means a pre-made page is sent to the user, making the initial loading time shorter and providing a smoother experience.

Next.js Example: Server-Side Rendering​

import React from 'react';

const NextMainComp = ({ data }) => {
  return (
    <div>
      {data.map((item) => (
        <p key={item.id}>{item.name}</p>
      ))}
    </div>
  );
};

export async function getServerSideProps() {
  const response = await fetch('https://api.example.com/data');
  const data = await response.json();

  return {
    props: {
      data,
    },
  };
}

export default NextMainComp;


React.js Example: Client-Side Rendering​


import React, { useEffect, useState } from 'react';

const ReactApp = () => {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetch('https://api.example.com/data')
      .then((response) => response.json())
      .then((result) => setData(result));
  }, []);

  return (
    <div>
      {data.map((item) => (
        <p key={item.id}>{item.name}</p>
      ))}
    </div>
  );
};

export default ReactApp;

Next.js Server-side Rendering vs. Static Site Generation​

Rendering methods in Next.js​

SSR vs SSG vs CSR vs ISR​

But before we dive into comparing SSG and SSR, let's take a moment to understand all the ways Next.js can render content. This will provide a better context for our comparison. Here's a quick overview in case you're not familiar with them.

  • CSR (Client-Side Rendering) : This method renders content in the browser using JavaScript. The server sends a basic HTML document to the browser, and JavaScript then fills in the missing parts by fetching data.

  • SSR (Server-Side Rendering) : In SSR, all the rendering happens on the server when a request is made. For each request, the server compiles the fetched data and HTML document, sending the client a fully formed page. Importantly, the server constructs and renders a new page for every request.

  • SSG (Static Site Generation): SSG is almost identical to SSR in terms of rendering, but with a key difference. Instead of rendering when a user requests a page, SSG does it at build time, creating fully prepared files served from a CDN. It builds the data and HTML into a page once and then uses that output for all requests until the next site rebuild.

  • ISR (Incremental Static Regeneration): ISR tackles a potential challenge with SSG, which requires rebuilding the entire website to update a page's content. When dealing with frequent content updates, like in a blog, SSG might force you to rebuild the entire site often for changes in a single page. ISR allows you to rebuild only the updated pages after the site is initially built.

When considering server-side rendering (SSR) and static site generation (SSG) in Next.js, each approach caters to specific scenarios, offering distinct benefits and trade-offs.

Server-side Rendering (SSR):​

Server-side rendering in Next.js involves dynamically generating HTML on the server for each request. This real-time rendering ensures that users receive a fully formed HTML page, making it suitable for dynamic content that may change with each request.

Example Code:

// pages/[slug].js
import React from 'react';

const DynamicPage = ({ data }) => {
  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </div>
  );
};

export async function getServerSideProps(context) {
  const { params } = context;
  // Fetch data based on dynamic parameter
  const response = await fetch(`https://api.example.com/pages/${params.slug}`);
  const data = await response.json();

  return {
    props: {
      data,
    },
  };
}

export default DynamicPage;

Static Site Generation (SSG):​

Static site generation, on the other hand, involves pre-rendering pages at build time. This results in static HTML files that are served to users, minimizing server load and enabling faster page loads. SSG is ideal for content that doesn't change frequently.

Example Code:


// pages/index.js
import React from 'react';

const HomePage = ({ data }) => {
  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </div>
  );
};

export async function getStaticProps() {
  // Fetch data during build time
  const response = await fetch('https://api.example.com/homepage');
  const data = await response.json();

  return {
    props: {
      data,
    },
  };
}

export default HomePage;

Choosing Between SSR and SSG:​

  • Use SSR when real-time data fetching is crucial, and content changes frequently.
  • Use SSG when content updates are less frequent, optimizing for faster page loads and reduced server load.

Remember, the choice between SSR and SSG depends on your specific project requirements and performance goals. Next.js offers the flexibility to use either approach or even a combination of both within the same application.

Next.js conveniently offers solutions for both server-side rendering and static site generation right out of the box. In contrast, React needs extra setup and tools to handle both of these.

Winner: Next.js

Next.js vs. React Code Splitting Comparison​

Code splitting is like a performance boost trick that makes things faster by only loading the bits of code that a particular webpage needs.

In React, you have to manually set up code splitting, which can be a bit of a hassle. Next.js, on the other hand, comes with automatic code splitting, which makes the development process smoother and more efficient.

Comparison with Code Examples​

Next.js Example: Code Splitting​

Using Next.js, breaking up code is super smooth. Every page acts like a cutoff point for dividing the code, resulting in smaller starting bundles and, in turn, better performance.

// pages/how-it-works.js
import React from 'react';

const HowItWorksPage = () => {
  // Component code goes here...
};

export default HowItWorksPage;

React.js Example: Code Splitting​

In React.js, splitting up code needs a bit more hands-on work with the lazy function and the Suspense component. This might make things a bit more intricate. React.lazy() is like a dynamic loader that brings in a component and wraps it with Suspense, managing the loading state. It's like loading components exactly when you need them.

import React, { lazy, Suspense } from 'react';

// Create a lazy-loaded component
const LazyComponent = lazy(() => import('./LazyComponent'));

// Regular component
const RegularComponent = () => (
  <div>
    <p>This is a regular component that loads immediately.</p>
  </div>
);

// Wrapper component using Suspense for loading state
const MyPage = () => (
  <div>
    <h1>My Page</h1>

    {/* Regular component loaded immediately */}
    <RegularComponent />

    {/* Lazy-loaded component with Suspense */}
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  </div>
);

export default MyPage;

In this example, LazyComponent is loaded lazily using React.lazy() and is wrapped with a Suspense component. The fallback prop of Suspense specifies what to show while the lazy component is loading. This way, the LazyComponent is only loaded when it's actually needed, reducing the initial bundle size and improving performance.

Winner: Next.js

Next.js vs. React SEO Comparison​

When Googlebot explores a webpage, it first displays the HTML and CSS, executes the JavaScript, and then catalogs the visible content. It also follows the links on that page to explore more pages.

There are two common issues that websites often face in this process:

Google may not be able to view the content that's rendered dynamically. Google may struggle to follow the links on the page, missing out on discovering other pages on the site. These challenges are particularly noticeable for websites built with React, which is client-side rendered.

For instance, picture a property search site created with React that loads property listings through an API call. If the website relies solely on client-side rendering, the initial HTML sent to the browser (and Googlebot) might only contain placeholders or loading indicators. The actual property listings, crucial for SEO, would only appear after JavaScript fetches the data and updates the page. If Googlebot encounters difficulties executing this JavaScript or if there's a delay in fetching data, the property listings might not get properly indexed.

Let's compare the SEO aspects of Next.js and React with some examples:

React.js Example: SEO​

React is a library for building user interfaces, and by default, it primarily relies on client-side rendering (CSR). In a typical React application, the initial HTML sent to the browser may be minimal, containing placeholders or loading indicators. The actual content often appears after the JavaScript is executed.

import React, { useEffect, useState } from 'react';

const PropertySearch = () => {
  const [propertyListings, setPropertyListings] = useState([]);

  useEffect(() => {
    // Simulating an API call to fetch property listings
    fetch('https://api.example.com/propertyListings')
      .then((response) => response.json())
      .then((data) => setPropertyListings(data));
  }, []);

  return (
    <div>
      <h1>Property Search</h1>
      {/* Placeholder or loading indicator initially */}
      <p>Loading property listings...</p>
      {/* Actual property listings rendered after fetching data */}
      {propertyListings.map((property) => (
        <div key={property.id}>
          <p>{property.name}</p>
          {/* Additional property details */}
        </div>
      ))}
    </div>
  );
};

export default PropertySearch;

Next.js Example: SEO​

Next.js, on the other hand, supports server-side rendering (SSR) out of the box, making it more SEO-friendly. The server pre-renders the HTML on the server, providing a fully formed page to the browser.

import React from 'react';

const PropertySearch = ({ propertyListings }) => (
  <div>
    <h1>Property Search</h1>
    {/* Rendered server-side, no placeholders or loading indicators */}
    {propertyListings.map((property) => (
      <div key={property.id}>
        <p>{property.name}</p>
        {/* Additional property details */}
      </div>
    ))}
  </div>
);

export async function getServerSideProps() {
  // Simulating server-side API call to fetch property listings
  const response = await fetch('https://api.example.com/propertyListings');
  const propertyListings = await response.json();

  return {
    props: {
      propertyListings,
    },
  };
}

export default PropertySearch;

In the Next.js example, the getServerSideProps function ensures that the property listings are fetched on the server side before rendering, providing a fully populated HTML page directly to the browser. This server-side rendering approach enhances SEO as search engines can easily index the content without relying on client-side JavaScript execution.

Google rendered and indexed the page before the property listings loaded. Not only is the listing content invisible, but Google doesn’t see the links to individual listing pages either.

To mitigate these SEO challenges, you can implement server-side rendering manually with React, but this requires additional configurations and server setup. Another popular solution is to use static site generators like Gatsby, which pre-renders React apps into static pages, enhancing their SEO friendliness.

On the other hand, Next.js offers server-side rendering by default, making it a go-to choice for developers prioritizing SEO.

Additionally, Google can also index Client Side Rendered (CSR) pages. However, it does so slower compared to Server Side Rendered (SSR) pages because it needs to render the page in a headless browser. Let's conclude by sharing this piece of information and for more details, you can refer to this link.

Winner: Next.js

Next.js is the clear winner​

Even though Next.js and React share a common origin, when it comes to delivering top-notch performance, Next.js stands out as the ultimate champion. If you prioritize performance and desire a straightforward solution, Next.js should be your preferred choice.

To emphasize this point, React has updated its"Start a New React Project" documentation, suggesting, "If you're starting a fresh app or website entirely with React, we advise selecting one of the widely adopted React-powered frameworks," and it places Next.js at the forefront of the list.

Are you a developer working with Next.js for your web projects? If so, it's time to elevate your performance! 💪 As fellow developers, we recognize the critical role high-performing websites play in crafting an exceptional user experience. But how can we ensure we deliver the very best performance every time?

Introducing Ddosify: a high-performance load testing tool explicitly designed to directly confront such challenges. 🚀 It's time to monitor the response time of your Next.js websites and ensure that your users consistently receive high-performance sites with every interaction they have. ✅🌐

Why wait any longer? Ensure your Next.js websites are delivering the ultimate user experience by using Ddosify today. We've got you covered for any queries or support; our friendly and vibrant Discord community is always ready to lend a hand. Join us on Discord and be part of our continuously evolving and learning community. 🎓👥

Keep in mind, in the finest theaters, the best stagehands operate the show behind the scenes. Let Ddosify take on that role for you. 🎭⭐ Let's ensure together that your website performance is always in the spotlight!

Share on social media: