DEV Community: Giorgi Parunov

Static Site Generation (SSG) vs Server-Side Rendering (SSR) in Next.js: A Deep Dive

Giorgi Parunov — Mon, 26 May 2025 17:49:26 +0000

As modern web applications demand high performance, excellent SEO, and real-time interactivity, Next.js emerges as a full-stack React framework that empowers developers to choose the right rendering strategy for each page. Two of its core rendering modes—Static Site Generation (SSG) and Server-Side Rendering (SSR)—offer distinct advantages depending on the application's requirements.

In this advanced guide, we’ll dissect SSG and SSR in Next.js with technical explanations, use cases, code examples, performance insights, and a decision framework.

What is Static Site Generation (SSG)?

SSG pre-renders pages at build time, generating static HTML, JSON payloads, and assets that can be deployed to a CDN for ultra-fast global delivery.

How it Works:

The getStaticProps() function is executed during the build process.
For dynamic routes, getStaticPaths() is also called to determine which paths to generate.
Output is stored as .html and .json files in .next/ and deployed to static hosting.

Example:

// pages/blog/[slug].tsx

export async function getStaticPaths() {
  const data = await fetchAll();
  return {
    paths: data.map(slug => ({ params: { slug } })),
    fallback: 'blocking'
  };
}

export async function getStaticProps({ params }) {
  const post = await fetchPostBySlug(params.slug);
  return {
    props: { post },
    revalidate: 60
  };
}

Use Cases:

Marketing pages
Documentation
Product listings (when content updates infrequently)
Blog posts

Benefits:

🏎️ Blazing Fast Load Times via CDN
🔒 Reduced Server Load (no backend rendering per request)
✅ Reliable SEO since HTML is pre-rendered
💸 Low Operational Cost using platforms like Vercel or Netlify

Limitations:

🐢 Slow Builds for Large Sites
⚠️ Content Can Be Stale without frequent rebuilds or ISR
❌ Difficult to Personalize (e.g., per-user content or auth logic)

What is Server-Side Rendering (SSR)?

SSR pre-renders HTML on each request. Every time a user visits a page, Next.js executes the page’s getServerSideProps() on the server.

How it Works:

The HTML is dynamically generated at runtime.
Data fetching, auth checks, and conditional logic are done per request.
Useful for personalized, real-time, or data-sensitive content.

Example:

// pages/dashboard.tsx

export async function getServerSideProps(context) {
  const session = await getSession(context.req);

  if (!session) {
    return {
      redirect: { destination: '/login', permanent: false }
    };
  }

  const dashboardData = await fetchDashboardData(session.user.id);

  return {
    props: {
      user: session.user,
      dashboardData
    }
  };
}

Use Cases:

User dashboards
Admin panels
Search results
Authenticated pages
Real-time financial data or inventory

Benefits:

🔁 Always Up-to-Date content
🔐 Supports Auth & Personalization
✅ SEO-Friendly with server-rendered HTML
🧠 Rich Contextual Logic possible per request

Limitations:

🐢 Slower Time-to-First-Byte (TTFB) compared to SSG
💰 More Server Resources and higher cloud costs
📉 Poorer Performance Under Load without caching
🧩 Higher Operational Complexity (handling failures, retries, etc.)

Hybrid Rendering with Next.js

Next.js allows per-page rendering strategies, enabling hybrid architectures that combine SSG and SSR.

ISR: Incremental Static Regeneration
You can update statically generated pages after deployment using ISR:

export async function getStaticProps() {
  const data = await fetchData();
  return {
    props: { data },
    revalidate: 300 // Regenerates page every 5 minutes
  };
}

Use Case: Updating product prices, blog comments, event schedules without full rebuilds.

** Middleware + Edge + SSR**
You can combine SSR with Next.js Middleware and Edge Functions for lower-latency personalization at the CDN level.

Performance Comparison

Metric	SSG	SSR
TTFB	~10-50ms (from CDN)	300ms–2s (depends on backend)
SEO Support	✅ Excellent	✅ Excellent
Personalization	❌ Limited (via JS)	✅ Native support
Content Freshness	❌ Stale unless ISR	✅ Always fresh
Complexity	✅ Simple	❌ More complex
Scalability	✅ Global CDN	❌ Needs backend scaling

Decision Framework

Question	If YES, Use
Does your content update in real-time or per-user?	SSR
Can you precompute pages ahead of time?	SSG
Do you need both speed and freshness?	ISR
Are you building a marketing or blog site?	SSG
Does your app rely on authentication or session?	SSR
Is your site large (10k+ pages)?	Mix of SSG + ISR + SSR

Conclusion

Next.js doesn't force you to pick just one rendering method—instead, it enables composability. Use SSG for static, high-performance pages. Use SSR where dynamic, personalized content matters. Use ISR to scale the benefits of both.

Modern Next.js apps often mix these strategies intelligently across routes, and even at the component level using React Server Components, Edge Functions, and streaming responses.

The real power of Next.js lies not in choosing SSG or SSR—but in knowing when and where to use them together

How I’m Still Managing State in React with Just Context (and Why It Still Works in 2025)

Giorgi Parunov — Sun, 11 May 2025 10:13:45 +0000

If you've been working with React for a while, you know the state management landscape can get overwhelming fast. Zustand, Jotai, Recoil, Redux Toolkit, atoms, proxies, signals—you name it.

But here’s the thing:

I’m still using React’s built-in Context API with useReducer—and it’s working just fine.
I want to show you how I structure it, why it still holds up in 2025, and what I’ve learned by keeping things simple.

Why I Haven’t Switched to Zustand, Redux, or Jotai

I’ve played around with a lot of state management libraries over the years. They’re impressive in their own ways. Zustand is sleek. Jotai is elegant. Redux (especially with Toolkit) has matured a lot.

But at the end of the day, my projects just haven’t needed the extra overhead.
Context and useReducer give me:

Full control and transparency
No new dependencies or mental models
Easy debugging and testing
Just enough flexibility for most app-scale needs

For example, here’s exactly how I manage my shopping bag state in a React app:

import {
  createContext,
  Dispatch,
  FC,
  ReactNode,
  useContext,
  useEffect,
  useMemo,
  useReducer,
} from "react";

interface BagItem {
  id: string;
  name: string;
  quantity: number;
  price: number;
}

interface BagState {
  bag: BagItem[];
  checkoutIsOpen: boolean;
}

interface BagContext {
  state: BagState;
  setState: Dispatch<Partial<BagState>>;
}

const initialState: BagState = {
  bag: [],
  checkoutIsOpen: false,
};

export const BagContext = createContext<Partial<BagContext>>({});

export const useBag: () => Partial<BagContext> = () => useContext(BagContext);

interface BagProviderProps {
  children: ReactNode;
}

const BagProvider: FC<BagProviderProps> = ({ children }) => {
  const [state, setState] = useReducer(
    (oldState: BagState, newState: Partial<BagState>) => ({
      ...oldState,
      ...newState,
    }),
    initialState
  );

  useEffect(() => {
    const localBag = localStorage.getItem("bag");
    if (localBag) {
      const payload: BagItem[] = JSON.parse(localBag);
      setState({ bag: payload });
    }
  }, []);

  const api = useMemo(
    (): BagContext => ({
      state,
      setState,
    }),
    [state]
  );

  return (
    <BagContext.Provider value={api}>
      {children}
    </BagContext.Provider>
  );
};

export default BagProvider;

This setup gives me:

A globally accessible bag state
A clean useBag() hook
Persisted state via localStorage
No external libraries

So Why Not Reach for Something Else?

If I ever find myself dealing with complex derived state, undo/redo functionality, or shared state across iframes/tabs—then sure, I might reach for Zustand or Redux.
But most apps don’t need that.
React’s built-in tools have improved, especially with features like:

useOptimistic (React 19)
Server Actions (Next.js)
React Server Components

And as React continues to shift work to the server, I think we’ll rely less on big client-side state tools—not more.

Final Thoughts

You don’t always need to chase the next hot library.
If Context + hooks do the job—and they often do—stick with them.
This setup has worked for me across a bunch of apps, and until I feel real pain, I’m happy keeping things simple and transparent.

What about you? Are you managing state the old-fashioned way, or have you gone all-in on Jotai, Zustand, or Signals?
Let’s chat—drop a comment with your current stack 👇

One of the ways to use Context API

Giorgi Parunov — Thu, 17 Nov 2022 06:44:32 +0000

As you know a lot of developers replaced redux with react context feature. So I want to show you how I am using it in my products.

We will create a Todo list using context API (based on typescript).

I will use bootstrap for design._
_

Final view of our code.

Let's get started!

At first, we must create our context in the contexts folder.

TodoContext.ts

import { createContext } from "react";

export interface ITodo {
    name: string;
    completed: boolean;
}

interface ITodoContext {
    data: ITodo[];
    updateData: Function;
}

export const TodoContext = createContext<ITodoContext>({
    data: [],
    updateData: (data: ITodo[]) => {
        throw new Error('updateData not implemented')
    }
})

Here we can see that we are creating an interface for todo items, and also for todo context.

My context has two values, the first one is the data that it must contain and the second one is the function that will update the data.

After creating context we must create a provider for it.
We are creating it in the providers folder.

TodoProvider.tsx

import {FC, ReactNode, useState} from "react";
import {ITodo, TodoContext} from "../contexts/TodoContext";

interface ITodoProvider {
    children: ReactNode
}

export const TodoProvider:FC<ITodoProvider> = ({children}) => {

    const [data, setData] = useState<ITodo[]>([]);

    const updateData = (data: ITodo[]) => {
        setData(data);
    }

    return (
        <TodoContext.Provider value={{data, updateData}}>
            {children}
        </TodoContext.Provider>
    )
}

In our todo provider, we will create and append the initial state for todo data. Also, we must create a function for handling data updates and appending it to our state.

Now we can start to use our created context API in our product.

What we must do:

Render Todo List.
Create Todo Item.
Delete Todo Item.

So let's do it step by step

Render Todo List
Idea is to render the table with our todo data.

We will create a TodoList.tsx file in the components folder.

export const TodoList = () => {
  const {data: todoData} = useContext(TodoContext);

  return (
    <div className="container">
      <div className="d-flex justify-content-between" >
        <div className="py-3">
          <h3>Todo List</h3>
        </div>
      </div>
      <table className="table table-striped table-dark">
        <thead>
          <tr>
            <td>Name</td>
            <td width="200">Status</td>
            <td width="150" align="right">Action</td>
          </tr>
        </thead>
        <tbody>
        {
          todoData?.map((item: ITodo, index) => (
            <tr key={`todo-${index}`}>
              <td>{item.name}</td>
              <td>
                {item.completed 
                  ? <span className="badge badge-info">Completed</span> 
                  : <span className="badge badge-secondary">Not Completed</span>
                }
              </td>
            </tr>
          ))
        }
        </tbody>
      </table>
    </div>
  )
}

Here you can see that we are using reacts useContext hook for getting our data from context.

const {data: todoData} = useContext(TodoContext);

So we will have always up-to-date data that we are getting from
TodoContext.

Of course, it will be always empty, so we must add create functionality for it.

Lets create a simple form.

<form ref={formRef} className="py-3 d-flex justify-content-between" onSubmit={handleCreate}>
    <input type="text" name="name" className="form-control" />
    <button type="submit" className="btn btn-primary mx-1">Add</button>
</form>

We must create handleCreate function in our component for detecting submitting in form.


const {data: todoData, updateData: updateTodoData} = useContext(TodoContext);

const handleCreate = (event: React.SyntheticEvent) => {
  event.preventDefault();
  const {target} = event as typeof event & {target: {name: { value: string };}}
  const name = target.name.value;
  updateTodoData([
    ...todoData,
    {
      name: name,
      completed: false
    }
  ])
  formRef?.current?.reset();
}

Here you can see that we added updateData which we are taking from our context, and using it as updateTodoData for creating and saving new todo item.

Thats it. Now on submitting form it will create and render new item in our todo list.

By the same logic we can create delete functionality also.

const handleDelete = (name: string) => {
  const payload = todoData.filter(item => item.name !== name)
  updateTodoData(payload);
}

We are taking the name and filtering our array by it.
After it, we are using our updateTodoData function and update our array.

You can check the repository here

And how you are using Context API in your applications?