> Что такое серверный рендеринг в Next.js (JavaScript, Next.js)

Короткий ответ

Серверный рендеринг (SSR) в Next.js - это механизм генерации HTML-кода страницы на сервере при каждом запросе пользователя. В отличие от клиентского рендеринга, сервер отправляет готовый HTML с данными, что улучшает SEO и время до первого контента (FCP). SSR реализуется через getServerSideProps или опцию 'server' в App Router.

Подробное объяснение

Серверный рендеринг в Next.js означает, что страница собирается на сервере для каждого входящего запроса. Процесс выглядит так: пользователь делает запрос к серверу, Next.js выполняет код на сервере (включая получение данных из API или базы данных), генерирует полный HTML-документ и отправляет его клиенту. Браузер получает готовую разметку с данными, что позволяет сразу отобразить контент, а затем гидратирует страницу для интерактивности.

SSR решает проблемы клиентского рендеринга: плохую индексацию поисковиками (поисковые роботы видят пустой HTML) и медленный первый рендер (пользователь ждёт загрузки JavaScript). Однако SSR увеличивает нагрузку на сервер и время ответа (TTFB), так как каждый запрос требует полной генерации страницы.

В Next.js Pages Router SSR реализуется через экспорт асинхронной функции getServerSideProps, которая выполняется на сервере перед рендерингом. В App Router используется опция dynamic = 'force-dynamic' или 'server' в fetch для принудительного SSR. Next.js также поддерживает Streaming SSR, отправляя части HTML по мере готовности.

На практике

SSR применяется для страниц, где критичны SEO и быстрый первый контент: лендинги, блоги, новостные сайты, интернет-магазины (страницы товаров). Не подходит для дашбордов с частыми обновлениями данных - там лучше использовать клиентский рендеринг или ISR.

В Pages Router:

• getServerSideProps выполняется на сервере при каждом запросе
• Возвращает props, которые передаются в компонент страницы
• Можно использовать context для доступа к req, res, params, query

В App Router:

• По умолчанию компоненты - серверные, но кэшируются
• fetch({ cache: 'no-store' }) или dynamic = 'force-dynamic' включает SSR
• Streaming SSR через loading.js и Suspense

Важно помнить про производительность: каждый запрос к серверу генерирует страницу заново, поэтому нужно кэшировать данные на уровне API или использовать CDN.

Пример кода

JSX
// Pages Router
export async function getServerSideProps(context) {
  const res = await fetch('https://api.example.com/posts', {
    cache: 'no-store' // принудительный SSR
  });
  const posts = await res.json();
  
  return {
    props: { posts }
  };
}

export default function Posts({ posts }) {
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

JSX
// App Router (app/posts/page.js)
export const dynamic = 'force-dynamic';

async function getPosts() {
  const res = await fetch('https://api.example.com/posts');
  return res.json();
}

export default async function Posts() {
  const posts = await getPosts();
  
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

Как отвечать на собеседовании

Начни с определения SSR и его цели - генерация HTML на сервере для каждого запроса. Объясни, как это отличается от статической генерации (SSG) и клиентского рендеринга. Приведи примеры, когда SSR оправдан (SEO-страницы) и когда нет (админки). Упомяни реализацию в Pages Router (getServerSideProps) и App Router (dynamic: 'force-dynamic'). Добавь про trade-off: лучше SEO и FCP, но выше нагрузка на сервер и TTFB. Если спросят про гидрацию - объясни, что после загрузки HTML браузер подключает React, делая страницу интерактивной.

Что проверяет интервьюер

• Понимание разницы между SSR, SSG и CSR
• Знание, как SSR реализован в Next.js (getServerSideProps, App Router)
• Осознание плюсов (SEO, FCP) и минусов (нагрузка, TTFB)
• Умение выбирать подходящий метод рендеринга под задачу
• Понимание гидрации и потокового рендеринга (Streaming SSR)

Типичные ошибки

• Путают SSR с SSG: SSR генерирует на каждый запрос, SSG - один раз при сборке
• Думают, что SSR решает все проблемы производительности - на самом деле увеличивает TTFB
• Используют SSR для страниц, где данные редко меняются (лучше ISR)
• Забывают, что getServerSideProps не имеет доступа к браузерным API (window, document)
• Не учитывают, что SSR-страницы нельзя кэшировать на CDN (кэшируется только HTML, но данные всегда свежие)