Exploring next js rendering strategies : SSG, ISR,CSR, SSR With their Pros and cons

When it comes to building web applications with Next JS developers have a options of next js rendering strategies upon their use cases. Each strategy offers unique advantages and comes with its own set of Drawbacks. In this article we’ll explore four key rendering strategies provided by Next JS. Static Site Generation (SSG), Incremental Static Regeneration (ISR), Client-Side Rendering (CSR) and Server-Side Rendering (SSR).

next js rendering strategies : SSG, ISR,CSR, SSR

static Site Generation

Static site generation is a valuable technique for enhancing an application’s speed, security, and overall performance. Next.js is one of popular framework for static site generation, giving facilities of user-friendly way to achieve the advantages of static sites. Next.js comes with robust feature like including automatic code splitting and seamless routing and server-side rendering streamlining the development process. with this developers can easily make static websites that is focused with security, performance and search engine optimization (SEO) in next js

Static Site Generation (SSG) pros :

speed and performance

Static-site generation gives us top notch performance compared to both server-side and client-side rendring. In this way content created during application’s build process. So when user makes request the content is readily available and can be delivered instantly.

Considering Security and Consistency

Let’s talk about keeping things secure and reliable. In the client-side way you load up all the needed stuff and then ask for data. If there’s a problem with authorisation it shows an error but the data is already loaded. With the other way you get nothing on the client side. just an immediate error if something goes wrong. Now for Consistency if your page relies on data that doesn’t change much like blog posts the usual process involves getting things and data making content and showing it. But sometimes the data source (API) might not available. This isn’t a problem with the other way because the content is ready ahead of time and doesn’t need other services.

SEO Optimization

Creating websites with static-site generation makes them load quickly reduces the need to keep asking the server for things and allows for better organization and description of the content. Search engines really like these things when deciding which websites to show first.

user friendly

NextJS makes building websites really easy. When your site has stuff that doesn’t changes like titles or images. it handles automatically during the building process. For dynamic things from API. you have two functions to help out getStaticProps for getting data ready and if your route changes there’s also getStaticPaths. It just makes things a lot simpler

Static Site Generation (SSG) cons :

Build time

One big problem with this way of building websites is that if you have a lots of pages then it takes really long time to put them all together. But there are tricks like Incremental Static Regeneration (ISR) and using the fallback thing that can help speed things up. We’ll talk about those later in this artical

outdated Content and Pages

the information on your pages might get old because you set it all when you was building the site. To keep things up-to-date you have to regularly rebuild or update the site.

Difficulties in Scalability

Making a lot of pages on SSG websites can be hard because you have to get each page ready in advance and this can slow things down when you have a bunch of pages.

Limited interactivity

this types of websites are not as dynamic as websites created on the go. The reason is that SSG sites can’t interact with the user’s browser environment so they can’t respond instantly to what the user does.

here is simple exemple for setting up SSG pages in NextJS

function About() {
  return <div>About</div>
}
 
export default About

this exemple is shows exemple of static site generation without data

Keep in mind that this page doesn’t have to go fetch any information from outside to be prepared in advance. In situations like this Next.js makes one HTML file for each page when building the site.

export default function Blog({ posts }) {
  // Render posts...
}
 
// This function gets called at build time
export async function getStaticProps() {
  // Call an external API endpoint to get posts
  const res = await fetch('https://.../posts')
  const posts = await res.json()
 
  // By returning { props: { posts } }, the Blog component
  // will receive `posts` as a prop at build time
  return {
    props: {
      posts,
    },
  }
}

If you want to grab data during pre-rendering. Next.js lets you use an async function named getStaticProps in the same file. This function is triggered during the build allowing you to send the fetched data as properties to the page during pre-rendering.

Incremental Static Regeneration

In simple words Incremental Static Regeneration (ISR) in Next.js lets you create web pages that start off static. But can be updated after specific time without rebuilding the entire website. It’s like having a cake that you can add new toppings without baking whole cake again. This makes site fast and flexible combining the best of both worlds – quick initial loading and easy updates.

Incremental Static Regeneration (ISR) pros :

Static Pages with Updated Content

Incremental Static Regeneration (ISR) is great because it can automatically freshen up your web pages with the latest information. this will revalidate your pages stay current without you having to do anything. You can decide revalidation interval for updating content.So your users always see the updated content on your website!

customized content

Incremental Static Regeneration empowers you to create customized static pages that cater to individual users by incorporating their specific data. You have the ability to fetch and display content that is specially made for each user with help of utilizing information from request parameters or cookies. In simpler terms it means your website can create unique pages for different people showing them content that’s just right for them.

SEO Friendly

ISR is like a superhero for your website’s visibility on search engines. It makes special files that search engines really like making your site easier to find. This means your important pages are always ready and up-to-date helping your website show up more when people search for things online.

Programmers Experience

Next.js makes it really easy for developers to use ISR. They give you simple tools to decide how often your pages get updated so you can focus on making your website awesome without getting caught up in the nitty-gritty details. It’s like having a smooth path to build fast and cool websites!

Reduce little development cost and limited resources

By using ISR you can cut down on the resources needed when building your project. This cost-effectiveness makes ISR a great choice for projects with tight budgets or limited resources.

Incremental Static Regeneration (ISR) cons

Not Good for pages that need real-time data update

Incremental Static Regeneration is not good mehod for real-time data updates because it operates on a specific revalidation interval. ISR allows you update static pages only at specific intervals but these updates are not instant. The revalidation period determines how often Next.js regenerates and updates the static pages.

Understanding How ISR Build Time Can Affect Initial Responses in Next.js

Incremental Static Regeneration in Next.js typically involves a build-time delay because it generates and updates static pages during the build process. The delay arises from time it takes to fetch and process dynamic data before creating the updated static pages.This build-time delay can impact the initial response time of your application. During this delay the application may not have the most up-to-date information especially if the revalidation interval is set to a longer duration. When a user makes a request to a page that is undergoing regeneration they might be served an older version of the page until the regeneration process is complete.

Navigating Cache Challenges

Incremental Static Regeneration gets a bit tricky with cache management because it creates static pages that need to be updated over time. Imagine having different versions of a page hanging around in the cache and figuring out which one to show while a new version is being made. it’s like juggling multiple balls. There’s this strategy called “stale-while-revalidate” that lets the server show an old page while making a new one and handling this smoothly can be a bit like solving a puzzle. if lots of people want the same page at the same time things can get a bit tangled up. So while ISR is awesome for updating pages bit by bit making sure the right pages get shown without hiccups can be a bit of a head-scratcher for developers.

export async function getStaticProps() {
  // If this request throws an uncaught error, Next.js will
  // not invalidate the currently shown page and
  // retry getStaticProps on the next request.
  const res = await fetch('https://.../posts')
  const posts = await res.json()
 
  if (!res.ok) {
    // If there is a server error, you might want to
    // throw an error instead of returning so that the cache is not updated
    // until the next successful request.
    throw new Error(`Failed to fetch posts, received status ${res.status}`)
  }
 
  // If the request was successful, return the posts
  // and revalidate every 10 seconds.
  return {
    props: {
      posts,
    },
    revalidate: 10,
  }
}

To use ISR add the revalidate prop to getStaticProps, it take milliseconds as and time

Client-Side Rendering

Client-side rendering (CSR) is a method of displaying web page content where the browser takes the lead. Instead of the server creating the entire webpage and sending it over CSR relies on JavaScript to fetch the raw data from the server and assemble the final content directly in the user’s browser. with this method browser has power to dynamically update and display content without the need for reload entire page. it gives more seamless and interactive user experience compared to server-side rendering (SSR).

Client-side rendering (CSR) pros :

Effortless Browsing

Client-side rendering contributes to quicker website navigation by shifting the rendering process to the user browser. In CSR the initial HTML is sent to the browser and then browser run JavaScript to fetch and assemble content as needed. This means that when user clicks on link or interacts with elements on page only the required data is fetched and updated dynamically without reloading the entire page.

Put less load on server

In CSR the server sends the necessary data and the browser uses JavaScript to handle the rendering process locally. This means the server doesn’t have to perform resource-intensive rendering tasks for each user such as clicking on links or navigating in site. In Final result CSR reduces the server workload and improved scalability and more efficient use of server making it a lighter and faster way for certain types of web applications.

Updated Content Every time user Interact

Client-Side Rendering (CSR) proves high benefite for managing dynamic content on websites. Its real-time update capabilities are particularly advantageous for applications requiring immediate updated data such as live feeds. CSR interactive nature ensures a responsive user experience enabling dynamic content to be fetched and updated based on user interactions without full-page reloading. By offloading rendering tasks to the user’s browser CSR efficiently uses server resources contributing to a scalable and responsive dynamic content handling process.CSR’s ability to provide a faster initial page load enhances overall user satisfaction and engagement.

Very good for Progressive Web App

Client-Side Rendering (CSR) and Progressive Web Apps (PWA) make a fantastic team. CSR ensures content is accessible offline making PWA reliable even without a constant internet connection. They both prioritize a fast responsive user interface. CSR handles dynamic updates swiftly on the client side complementing PWA goal of a seamless and native app like experience. CSR’s efficient resource usage aligns perfectly with PWA focus on optimal performance. With CSR they deliver a powerful and user-friendly web application experience.

Client-side rendering (CSR) cons :

Slower Initial page Leadtime

Sometimes with CSR the first time you open a webpage it might take a bit longer to load. This is because the browser has to download and process a chunks of JavaScript code to show you the page. So in some cases especially if there’s a lot of dynamic stuff it can feel a bit slow at the beginning. But once everything is set up the website should work smoothly. Developers can do some tricks to speed things up but that’s the basic idea.

Poor SEO

If you don’t implement CSR correctly it can cause problems for SEO. Search engines may struggle to understand and index your content especially if most of it is loaded using JavaScript. To avoid make sure essential content is in the initial HTML use server-side rendering for critical parts and follow SEO best practices. This helps search engines find and display your site content effectively in search results.

Poor Performance on low end devices

Low-end devices struggle with CSR because they have less power and memory. When a website relies on heavy JavaScript it can slow down these devices. Slow internet on these devices makes downloading and processing JavaScript files take long time. Older browsers on low-end devices may not handle modern JavaScript efectively causing performance issues. The process of rendering content on the device browser can also be slower leading to delays. To fix this developer need to optimize their code use techniques like lazy loading and server-side rendering for a good and smooth experience on low-end devices.

security risks

CSR can bring security risks if not managed carefully. One common concern is cross-site scripting (XSS) vulnerabilities. This happens when attackers inject harmful scripts into the JavaScript code running on the client side. If the website doesn’t have proper security measures these scripts can get executed leading to potential security breaches. To avoid this developers need to implement strong security practices like input validation and sanitization to ensure that user input doesn’t become an avenue for harmful scripts.

In Next.js, there is ways you can implement client-side rendering

import React, { useState, useEffect } from 'react'
 
export function Page() {
  const [data, setData] = useState(null)
 
  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch('https://api.example.com/data')
      if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status}`)
      }
      const result = await response.json()
      setData(result)
    }
 
    fetchData().catch((e) => {
      // handle the error as needed
      console.error('An error occurred while fetching the data: ', e)
    })
  }, [])
 
  return <p>{data ? `Your data: ${data}` : 'Loading...'}</p>
}

Using React’s useEffect() hook inside your pages instead of the server-side rendering methods (getStaticProps and getServerSideProps).

Server Side Rendering

When we talk about SSR it’s like the server making a fresh copy of a webpage every time someone asks for it. This is super handy for pages where the information changes based on what someone is looking for. To make this happen we use a special function called “getServerSideProps” and it does its thing every time someone wants to see that page. So with SSR each request gets a dynamic webpage with content that can be different for each person asking for it. It’s like a personalized experience every time

Server Side Rendering (SSR) pros :

Faster Initial load time

When we talk about SSR it means the server does the heavy lifting by creating the webpage and sending it straight to the browser. users get to see the content quicker compared to CSR. In CSR the browser has to wait for JavaScript to load and do its thing before showing the page. But with SSR the HTML is ready to go so users can see the content without waiting as long. It’s like getting stuff faster!

Improved SEO

Search engines use the words and information on a webpage to figure out what it’s about and decide where to show it in search results. SSR makes it simple for search engines to read and understand your site because all the important info is in the webpage right from the start. This can make your site show up better in search results so more people can find it easily. It’s like giving your site a boost so that search engines really get what it’s about!

Improved performance on low-end devices

Some people don’t use high-end device or have super-fast internet. SSR helps out here because it lets even simpler devices load stuff faster. The server does the hard loading work making it easier for all kinds of devices to show the content quickly. This means people with not-so-good phones or slower internet can still have a smooth and fast experience. It’s like making sure everyone no matter their device gets to see things without waiting forever.

good security

When it comes to showing things on websites doing it on the client side can sometimes have security issues like the possibility of cross-site scripting attacks. However with SSR the server takes charge of creating the webpage which lowers the risk of these kinds of attacks. It’s like having a more secure system because the important stuff is handled by the server making it harder for bad attacker to mess with the webpage and your data.

Easier for Everyone

SSR makes things easier for everyone by having the server handle the webpage creation. This means quick access to content for all users no matter their device or internet speed. It’s like a smooth and easy experience for everyone.

Server Side Rendering (SSR) cons :

difficult to maintain and debug

SSR is hard to maintain and debug because it mixes server and client code making the code more complicated. Finding and fixing errors becomes challenging as issues can happen on both the server and client sides. Managing dynamic HTML generation and handling state on both ends adds to the complexity making it more challenging to work with compared to simpler approaches.

Large size of HTML

Large HTML files in SSR can be a problem. They take longer to load making the website slower and use more data which can be costly for users. it puts a strain on the server affecting how well the website can handle lots of people using it. To fix this developers try to make the HTML files smaller and load only what’s really needed.

Higher time to first byte

With SSR if pages take longer to start and respond it can affect SEO. Search engines like fast websites and delays may lead to lower rankings. When users leave quickly because of slow interactions it signals to search engines that the content might not be great impacting SEO. To keep SEO strong with SSR it’s important to optimize page speed and user experience.

Higher Server cost

SSR can cost more for servers because it requires extra processing power to generate HTML dynamically for each user. This increased workload may lead to higher infrastructure costs especially during periods of high traffic. Businesses need to consider these server costs while benefiting from SSR advantage.

To use Server-side Rendering for a page, you need to export an async function called getServerSideProps. This function will be called by the server on every request.

export default function Page({ data }) {
  // Render data...
}
 
// This gets called on every request
export async function getServerSideProps() {
  // Fetch data from external API
  const res = await fetch(`https://.../data`)
  const data = await res.json()
 
  // Pass data to the page via props
  return { props: { data } }
}

As you can see, getServerSideProps is similar to getStaticProps, but the difference is that getServerSideProps is run on every request instead of on build time.

Conclusion

We’ve looked at different ways to show things on websites using Next.js like Static Site Generation (SSG), Incremental Static Regeneration (ISR), Client-Side Rendering (CSR), and Server-Side Rendering (SSR). Each way has its good sides and challenges depending on what you need for your website.

• SSG : SSG excels in speed and security, and SEO optimization making it ideal for static content. However it may face challenges with build time for large websites and the need for regular updates.
• ISR : ISR introduces flexibility by allowing updates to static pages without rebuilding the entire site. It’s excellent for personalized content and SEO but may pose challenges in terms of build time delays and cache management.
• CSR : CSR provides seamless interactive user experiences with dynamic updates. It’s efficient for handling dynamic content and reduces server load and works well with Progressive Web Apps. However it may face slower initial page load times, SEO concerns and performance issues on low-end devices.
• SSR : SSR offers faster initial load times, improved SEO and enhanced performance on low-end devices. It ensures security by handling webpage creation on the server but may be challenging to maintain and debug. Larger HTML files and higher server costs are potential drawbacks.

FAQs