What is Server-Side Rendering (SSR)?

What is Server-Side Rendering?

SSR is the process of rendering a web page’s content on the server rather than in the browser. When a user requests a webpage, the server assembles and sends a fully rendered HTML page to the client, which the browser can display immediately. This contrasts with client-side rendering (CSR), where the server sends a minimal HTML shell and JavaScript code that runs in the browser to render the page content dynamically.

How SSR Works

1. A browser sends a request to the server for a web page.

2. The server processes application logic, fetches data as needed, and generates complete HTML for the page.

3. The fully constructed HTML page is sent back to the browser.

4. The browser displays the fully rendered page immediately, improving perceived performance and reducing the time to first meaningful paint

How does Next.js do SSR?

• You use a special function called getServerSideProps() in your page file.

• This function runs only on the server, never in the browser.

• It runs on every request and fetches the latest data.

• Whatever you return from it becomes props for your page component.

Benefits of SSR

• Improved SEO: Since search engines receive fully rendered HTML, SSR facilitates better indexing compared to CSR, where content is loaded through JavaScript.

• Faster Initial Page Load: Users see meaningful content sooner as the browser does not wait for client-side JavaScript to load and execute before rendering the page.

• Better Performance on Low-Powered Devices: Processing happens on the server, reducing the client’s computational burden.

• Enhanced Sharing and Link Previews: Social media and other platforms that generate previews use the server-rendered HTML content effectively.

Drawbacks of SSR

• Increased Server Load: The server must render pages on each request, which can demand more resources, especially with high traffic.

• Longer Time to Interactivity: Though content is visible quickly, client-side JavaScript still needs to load and hydrate the page to make it interactive, potentially delaying full interactivity.

• Complexity in Development: Combining SSR with modern client-side frameworks requires additional architecture such as hydration strategies and universal/isomorphic code sharing.

Common SSR Frameworks and Tools

• Next.js (React): Provides seamless SSR with React applications.

• Nuxt.js (Vue.js): Offers SSR capabilities and conventional routing with Vue.js.

• Angular Universal: Angular’s official SSR solution.

• Express with templating engines: Traditional SSR can also be achieved using Node.js frameworks and templating languages like EJS or Pug.

Practical Example — Live Weather Page

Imagine you want to show live weather on /weather.
You cannot use SSG because weather changes every minute.
So you use SSR to fetch fresh data each time someone visits.

pages/weather.js

export async function getServerSideProps(context) {

const city = context.query.city || 'Delhi'; // get city from query if provided

const res = await fetch(`https://api.open-meteo.com/v1/forecast?latitude=28.6&longitude=77.2&current_weather=true`);

const weather = await res.json();

return {

props: { city, weather }, // pass to page

};

}

export default function WeatherPage({ city, weather }) {

return (

<div>

<h1>Live Weather for {city}</h1>

<p>Temperature: {weather.current_weather.temperature}°C</p>

<p>Windspeed: {weather.current_weather.windspeed} km/h</p>

</div>

);

}

• If you go to /weather?city=Delhi, it fetches Delhi’s weather at request time.

• If you go to /weather?city=Mumbai, it fetches Mumbai’s weather at request time.

Use Cases for SSR

SSR is particularly beneficial for content-heavy websites, e-commerce platforms, blogs, and other sites where SEO and quick initial rendering are priorities. It is less common for highly dynamic single-page applications (SPAs) that require complex client-side interactions without frequent full page reloads.

Key Points to Remember

1. Runs only on server → Your API keys are safe.

2. Runs on every request → Slower than SSG, but always fresh.

3. Good for dynamic content → dashboards, stock prices, live feeds.

4. Use context → You can get query params, cookies, and request headers inside getServerSideProps(context).

When to use SSR vs SSG

• Use SSR: Data changes every request (e.g. stock prices, user dashboards).

• Use SSG: Data changes rarely (e.g. blog posts, product pages).