Що таке CSR, SSR, SSG та ISR і в яких випадках вони використовуються?

1. Що таке rendering вебсторінки і що саме браузер або сервер повинен сформувати перед показом сторінки користувачу?

Рендеринг (rendering) — це процес перетворення вихідного коду програми (шаблонів, компонентів, даних) на візуально відображену, інтерактивну HTML-сторінку, з якою взаємодіє користувач.

У розробці розрізняють дві площини рендерингу:

Архітектурний рендеринг (на боці сервера чи збірки): це стратегічний вибір того, де і коли формується HTML-код — під час збірки проєкту, під час HTTP-запиту на сервері чи динамічно у браузері.

Браузерний рендеринг (на боці клієнта): це фізичний процес у браузері користувача, який приймає HTML, завантажує CSS/JavaScript, будує об'єктні моделі DOM і CSSOM, обчислює геометрію блоків (Layout) і розфарбовує пікселі на екрані (Paint).

Перед показом сторінки система повинна виконати маршрутизацію, зібрати необхідні дані з бази даних або API, зформувати підсумковий HTML-каркас (або заготовку), включити SEO-метадані та підготувати ресурси стилів і скриптів.

2. Що таке CSR — Client-Side Rendering — і що відбувається після завантаження сторінки у браузері?

Client-Side Rendering (CSR / Клієнтський рендеринг) — це підхід, за якого сервер надсилає браузеру мінімальний «покрив» або заготовку HTML (minimal HTML shell) разом із файлами JavaScript. Уся основна робота з побудови інтерфейсу, обробки логіки та рендерингу DOM відбувається безпосередньо в браузері користувача.

Що відбувається після завантаження у браузері:

Браузер отримує базовий порожній HTML-шаблон із посиланнями на скрипти.

Браузер завантажує, парсить та виконує JavaScript-бандли.

Запущений JavaScript виконує асинхронні API-запити до сервера або БД для завантаження контенту.

Отримані дані підставляються в компоненти, і браузер динамічно генерує та вставляє елементи в DOM-дерево.

3. Що таке SSR — Server-Side Rendering — і як сервер формує HTML для кожного запиту?

Server-Side Rendering (SSR / Серверний рендеринг) — це метод, за якого повний, контентно наповнений HTML-документ генерується на сервері під кожен окремий HTTP-запит користувача в режимі реального часу.

Як сервер формує HTML:

Сервер приймає HTTP-запит від браузера та обробляє маршрут.

Backend виконує код сторінки та запитує необхідні дані з бази даних чи API.

Отримані дані підставляються в шаблони або React/Vue-компоненти, і сервер рендерить підсумковий HTML-рядок.

Готовий HTML-документ разом із посиланнями на JS надсилається браузеру.

Користувач негайно бачить контент (First Paint). Після цього запускається процес гідратації (hydration) — виконання JavaScript у браузері для прикріплення обробників подій до вже наявного HTML-дерева, роблячи сторінку інтерактивною.

4. Що таке SSG — Static Site Generation — і коли HTML генерується наперед?

Static Site Generation (SSG / Статична генерація) — це стратегія, при якій усі HTML-сторінки вебсайту попередньо рендеряться та створюються під час збірки проєкту (build time), ще до того, як сайт буде опубліковано або відвідано користувачем.

Коли та як генерується HTML: Генерація відбувається один раз під час запуску команди збірки (наприклад, next build) на сервері розробки або CI/CD сервісі. Готові статичні HTML-файли розгортаються на мережах доставки контенту (CDN). Коли відвідувач відкриває сторінку, CDN миттєво віддає готовий файл із кешу без додаткових обчислень на сервері.

5. Що таке ISR — Incremental Static Regeneration — і як він дозволяє оновлювати вже згенеровані статичні сторінки?

Incremental Static Regeneration (ISR / Інкрементальна статична регенерація) — це гібридний підхід, який поєднує надшвидку віддачу статичних сторінок (SSG) із можливістю оновлювати або створювати нові статичні сторінки у фоновому режимі (runtime) без повного перезбирання всього сайту.

Як працює оновлення сторінок:

При запиті користувач миттєво отримує раніше згенеровану статичну сторінку з CDN-кешу.

Якщо з моменту останнього створення минув заданий час (наприклад, параметр revalidate: 60 секунд), поточний користувач все одно отримує кешовану сторінку, але сервер паралельно запускає фонове перезбирання цієї конкретної сторінки.

Як тільки нова версія сторінки успішно згенерована, вона замінює стару в кеші для всіх наступних відвідувачів.

Також підтримується On-demand revalidation (повторна генерація за вимогою) через API-вебхуки під час зміни даних у CMS чи БД.

6. Чим CSR, SSR, SSG та ISR відрізняються за швидкістю, навантаженням і актуальністю?

7. Як різні способи rendering впливають на crawling, indexing, JavaScript rendering і SEO?

SSG та SSR (Gold Standard для SEO): Найкращі рішення для пошукових систем. Googlebot та інші сканери негайно отримують повністю сформований HTML-код із метатегами, Open Graph та текстом без необхідності виконувати JavaScript. Це забезпечує найшвидшу індексацію та стабільні позиції.

ISR (Відмінно для масштабованого SEO): Поєднує високі бали Core Web Vitals (завдяки CDN) з наявністю готового HTML, що робить його ідеальним для SEO великих сайтів.

CSR (Ризиковано для SEO): Не рекомендований для публічного контенту, який має ранжуватися. Хоча Google вміє виконувати JS, такі сторінки потрапляють у вторинну чергу рендерингу (secondary rendering queue). Це спричиняє затримки в індексації, витоки crawl budget та ризик того, що бот побачить порожню заготовку.

8. Для яких сторінок краще підходять CSR, SSR, SSG та ISR?

SSG: Портфоліо, візитки компаній, документація, лендинги та невеликі блоги (де контент оновлюється рідко).

ISR: Каталоги товарів, великі e-commerce лістинги, каталоги нерухомості, новинні стрічки та дошки оголошень (тисячі сторінок із періодичними змінами).

SSR: Картки товарів із живими залишками/персоналізованими цінами, адмін-звіти, сторінки пошукової видачі з динамічними фільтрами та детальні публічні профілі.

CSR: Інтерактивні панелі (SaaS Dashboards), особисті кабінети користувачів, налаштування профілю, чати, кошик покупок та UI терміналів (де контент закритий авторизацією і SEO не потрібне).

9. Чи може один сайт одночасно використовувати CSR, SSR, SSG та ISR для різних сторінок і компонентів?

Так, і це є сучасним стандартом розробки (Hybrid Rendering).

Сучасні метарівневі фреймворки (Next.js, Nuxt, SvelteKit, Astro) дозволяють обирати стратегію рендерингу на рівні кожного окремого маршруту (per-route decision). Наприклад, у межах одного коду Next.js App Router із використанням React Server Components (RSC) можна встановити:

Головну сторінку та блог — на SSG.

Каталог товарів із мільйоном SKU — на ISR.

Особистий кабінет клієнта — на SSR.

Інтерактивну аналітичну панель чи чат всередині кабінету — на CSR Client Components.

10. Як правильно вибрати спосіб rendering на основі контенту, оновлень, SEO, персоналізації та навантаження?

Для вибору оптимальної стратегії використовується покрокова схема прийняття рішень (Decision Flow):

1. Чи повинен цей URL індексуватися в Google для залучення трафіку?
├── НІ ──> Використовуйте CSR (інтерактивні панелі, кабінети, чати)
└── ТАК ──> Переходьте до питання 2

2. Чи змінюється контент/HTML індивідуально для кожного користувача (персоналізація/сесія)?
├── ТАК ──> Використовуйте SSR (або статичний каркас + CSR-острівці)
└── НІ ──> Переходьте до питання 3

3. Як часто змінюються дані на сторінці?
├── Вкрай рідко (лише під час деплою) ──> Використовуйте SSG
├── Періодично (раз на хвилину, годину, або за вебхуком) ──> Використовуйте ISR
└── У реальному часі під кожний клік ──> Використовуйте SSR

4. Які обмеження бюджету та сервера?
└── Якщо потрібно витримати мільйонний трафік із мінімальними витратами на сервери —
максимально зміщуйте архітектуру у бік SSG та ISR з CDN-кешуванням.