Статика, SSR чи CSR: вибір моделі рендерингу

Коротка відповідь

Статична генерація готує HTML до запиту, SSR — під час запиту, CSR — у браузері. Вибирайте для маршрутів, а потім для окремих областей. Публічна стаття може бути згенерованою, а пошук — працювати в браузері. Сторінка кабінету потребує авторизації конкретного запиту навіть зі спільним оформленням.

Рендеринг, кешування та межа Server/Client Components — різні рішення. Server Component може виконуватися під час збірки чи запиту. Client Component може входити до початкового HTML, після чого гідратація приєднає обробники. Директива use client не доводить винятково браузерний рендеринг маршруту.

Практичні кроки реалізації

1. Визначте зміст першої відповіді

Визначте, що користувач має отримати до завантаження JavaScript: опис товару, заголовок статті, контакти. Приватний dashboard може починатися зі стану завантаження, якщо API сам перевіряє доступ. Перевіряйте прямий запит URL, не лише переходи в уже відкритому застосунку.

2. Відокремте свіжість від персоналізації

Часто змінювана публічна сторінка може використовувати перевалідацію кешу. Рідко змінюваний приватний запис усе одно потребує авторизації. Для джерел визначте допустиму застарілість і залежність від користувача. Не кладіть персональний HTML у спільний кеш і не додавайте сесію до спільного layout без потреби.

3. Перевірте контракт розгортання

У статичному експорті немає сервера застосунку під час відвідування. Параметри шляхів готують при збірці, операції запиту виконують через зовнішній API. SSR потребує runtime й обробки відмов backend. CSR потребує fallback для прямих посилань і коректних заголовків кешу ресурсів.

Приклад реалізації

Приклад Next.js використовує модель без Cache Components, як конфігурація цього репозиторію. Відомі шляхи статей створюються під час збірки. Дані ілюстративні; production потребує валідації й правил для відсутніх та нових slug. Експорт файлів не створює невідомий маршрут під час запиту.

// app/articles/[slug]/page.tsx
import { notFound } from "next/navigation";

const articles = [
  { slug: "rendering", title: "Rendering choices", body: "Start with the route." },
];

export function generateStaticParams() {
  return articles.map(({ slug }) => ({ slug }));
}

export default async function Page({
  params,
}: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const article = articles.find((entry) => entry.slug === slug);
  if (!article) notFound();
  return <article><h1>{article.title}</h1><p>{article.body}</p></article>;
}

Дані кабінету отримують іншим шляхом: перевірена сесія та дозволене серверне читання. Браузерний фільтр можна додати малим Client Component лише з публічними полями. Не потрібно переводити весь сайт на один режим.

Компроміси та альтернативи

Згенерований HTML зменшує залежності запиту, але потребує публікації й інвалідації. SSR персоналізує першу відповідь, але залежить від затримки backend. CSR підтримує складну взаємодію, проте великий bundle і послідовні запити затримують контент. Вимірюйте реальні сторінки з холодним кешем.

Поширені помилки

Плутанина RSC із SSR змушує очікувати виконання async-компонента для кожного відвідувача. Плутанина Client Components із CSR призводить до window під час пререндерингу. Перевірка лише клієнтських переходів пропускає порожні відповіді чи помилки прямих URL. Ціна зі збірки не є авторитетною для прийняття замовлення.

Перевірка перед випуском

• ☐ Прямі URL повертають правильний HTML і статус.
• ☐ Публічні та персональні відповіді мають окреме кешування.
• ☐ Вимоги до свіжості містять шлях оновлення.
• ☐ Невідомі маршрути повертають належну помилку.
• ☐ Взаємодія переживає повільні й невдалі запити.
• ☐ Хост підтримує потрібні функції запиту.

Поширені запитання

Чи можливі форми на статичному сайті?

Так, якщо дані отримує окремий сервер чи сервіс з валідацією і зберіганням. Статичний хост не виконує Server Action. Успіх означає прийняття системою, не анімацію чи припущення про доставку пошти.

Чи гарантує SSR індексацію?

Ні. Рендеринг визначає відповідь; виявлення, доступність індексації, canonical, якість і обробка пошуковиком — окремі питання. Корисний початковий HTML полегшує перевірку контенту й посилань, але не гарантує індексації чи позиції.

Наступний крок

Складіть таблицю маршрутів: початковий HTML, персоналізація, свіжість, розгортання. Почніть із найобмеженішого маршруту й перевірте пряме відкриття та переходи. Змінюйте режим за доказами; віджет сам собою не потребує SSR для публічних сторінок.

Первинні джерела

• Next.js: статичний експорт
• Next.js: рендеринг без Cache Components
• Next.js: Server і Client Components

Пов’язані матеріали та приклади

• Архітектура вебсайтів
• Як вибрати технологічний стек для вебсайту
• Next.js чи React із Vite для нового вебсайту
• Headless CMS чи традиційна CMS
• Публічний каталог проєктів