SSR, CSR, SSG та ISR: реальна різниця
SSG створює HTML до request, зазвичай під час build. SSR створює HTML на сервері для кожного request. CSR формує значну частину інтерфейсу після виконання JavaScript у браузері. ISR зберігає статичний результат, але дозволяє регенерацію після deployment. [6][9][16]
Тому важливіше за назву стратегії знати, коли виникає HTML, як довго він кешується і скільки роботи залишається браузеру.
SEO: Google рендерить JavaScript, але CSR не дорівнює prerendering
Google описує обробку JavaScript у трьох фазах: crawling, rendering та indexing. Якщо початковий HTML не містить реального контенту, Web Rendering Service має виконати JavaScript, а сторінка потрапляє до черги rendering. [1]
Google водночас рекомендує server-side rendering або prerendering, бо це пришвидшує сторінку для користувачів і crawler, а не всі bot виконують JavaScript. [1]
CSR може працювати, але змістовний HTML у першій відповіді надійніший для важливого публічного контенту.
SSG: хороший старт для контенту, що змінюється рідко
При SSG HTML створюється під час build і може віддаватися як статичний файл із CDN. Next.js рекомендує Static Generation, якщо сторінку можна підготувати до request. [9][12]
Landing pages, документація, статті, help, portfolio і частина продуктових каталогів є типовими випадками. [10][16]
Обмеження з'являється при дуже частих змінах або надто довгих build.
SSR: коли контент має бути свіжим або залежить від request
SSR створює HTML для конкретного request і може використовувати актуальні дані, headers, cookies, локалізацію чи параметри. [6][10][11]
Для SEO контент одразу є в HTML, але кожен request додає серверну роботу, а повільний rendering може збільшити TTFB. [6]
Стабільні частини можна кешувати.
ISR: статичний HTML із контрольованою свіжістю
ISR зберігає переваги статичного HTML і дозволяє регенерацію після deployment. Next.js документує оновлення статичних сторінок після build, а Nuxt 4 пропонує подібні механізми через `isr` і `swr`. [9][13][16]
Це підходить для каталогів, статей, документації та категорій, що змінюються періодично, але не потребують real-time точності.
При stale-while-revalidate перший відвідувач після expiration може отримати старішу версію, поки нова генерується у фоні. [13][16]
CSR: підходить для застосунків без потреби в індексації
При CSR браузер має завантажити, розібрати й виконати JavaScript до побудови значної частини DOM. web.dev зазначає, що великі JavaScript bundles можуть погіршувати INP, особливо на мобільних пристроях. [6][7]
Nuxt наводить SaaS, back-office, ігри та інші сильно інтерактивні інтерфейси без SEO-потреб як відповідні випадки. [13]
Для публічного контенту CSR збільшує залежність від JavaScript rendering у crawler. [1][2]
Порівняння SEO та продуктивності
| Режим | Коли генерується HTML | Контент у початковому HTML | Свіжість | Вартість request | SEO |
|---|---|---|---|---|---|
| SSG | Build | Так | До наступного build | Дуже низька | Дуже добре |
| ISR | Build або revalidation | Так | Залежить від revalidation | Низька | Дуже добре |
| SSR | Кожен request | Так | Дуже висока | Вища | Дуже добре |
| CSR | У браузері | Часто обмежений | Висока після fetch | Сервер низький, клієнт вищий | Можливо, менш оптимально |
Універсального рейтингу немає. SSG та ISR часто мають переваги кешу і вартості, SSR свіжості, CSR гнучкості в браузері. [6][9][13]
Для SEO SSG, ISR та SSR можуть одразу повернути змістовний HTML. CSR може бути проіндексований Google, але потребує додаткового rendering. [1][9]
Core Web Vitals: rendering є лише одним фактором
| Метрика | Добре | Погано | Що вимірює |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Завантаження головного контенту |
| INP | ≤ 200 ms | > 500 ms | Швидкість реакції на взаємодію |
| CLS | ≤ 0.1 | > 0.25 | Візуальну стабільність |
Google використовує Core Web Vitals у ranking systems, але хороші показники не гарантують високої позиції. Поточні метрики це LCP, INP і CLS. [4][5]
Рекомендовані хороші значення: LCP ≤ 2,5 s, INP ≤ 200 ms та CLS ≤ 0,1 на 75-му percentile. [4][8]
SSG може швидко доставити HTML і мати слабкий INP через надлишок JavaScript. SSR може покращити перший render, але повільний backend погіршить TTFB. [6][7]
Hydration: SSR не завершується після відправки HTML
Багато framework гідратують SSR або SSG output, підключаючи стан і event handlers після отримання HTML. web.dev попереджає, що повна rehydration може збільшити TBT і погіршити INP. [6]
Сторінка може виглядати готовою, але ще короткий час не реагувати.
Допомагають менший JavaScript, code splitting, lazy loading і часткова або відкладена hydration. Nuxt 4 документує майже статичні сторінки з мінімумом JavaScript. [7][14]
Кеш і свіжість: ключова різниця
SSG використовує результат до наступного build. ISR додає revalidation. SSR може рендерити кожен request, але також використовувати server або CDN cache. [6][13][16]
Вибір має починатися з максимально допустимого віку даних. Кілька хвилин можуть бути прийнятними для продуктового опису, але не для балансу рахунку.
Invalidation кешу варто, якщо можливо, прив'язувати до реальних змін контенту.
SEO не обмежується rendering
HTML не замінює правильні HTTP status, crawlable links, canonical, sitemap, title і metadata. Google рекомендує окремі URL та crawlable links для важливого контенту. [1][2]
Погано реалізований SSR все одно може повертати неправильні 200, дублікати або некоректні metadata. Rendering є лише частиною technical SEO.
Google не рекомендує Dynamic Rendering як довгострокове рішення і віддає перевагу SSR, static rendering або hydration. [3]
Що обрати для різних типів сторінок
Landing pages, блоги та документація зазвичай добре підходять для SSG. Великі каталоги або періодичні новини для ISR. Публічні request-dependent сторінки можуть потребувати SSR. Приватні dashboard можуть залишатися CSR. [9][13]
E-commerce може поєднувати статичну категорію, ISR для продуктів, SSR для session data і CSR для інтерактивних фільтрів.
Рішення варто приймати за route.
Реальність 2026: гібридні моделі стають детальнішими
Next.js 16.3.4 документує Cache Components, `use cache`, revalidation даних та UI, статичну shell і streaming request-time даних. Поточну документацію кешування оновлено 25 серпня 2026 року. [11]
Nuxt 4 дозволяє `prerender`, `ssr`, `swr` та `isr` за route через Route Rules. [13][14]
Чотири терміни залишаються корисними, але вже не описують кожен сучасний компонент точно.
Як покращити CSR для SEO без великого rewrite
Спочатку визначте публічні route, які справді мають отримувати органічний трафік. Приватний dashboard не потрібно переводити на SSR лише заради єдності.
Потім перенесіть критичний контент, title, metadata і links у HTML, згенерований до клієнтського JavaScript. Google рекомендує SSR або prerendering замість Dynamic Rendering. [1][3]
Нарешті перевірте Search Console, rendered HTML і field data Core Web Vitals.
Практичне правило вибору
Якщо сторінку можна підготувати заздалегідь і контент однаковий для всіх, починайте з SSG. Якщо він змінюється періодично, розгляньте ISR. Якщо результат залежить від request і має бути в HTML, використовуйте SSR. Для приватного застосунку без SEO-цілі часто достатньо CSR. [9][13]
Потім перевірте TTFB, LCP, INP, CLS, серверні витрати, частоту змін, кількість сторінок і персоналізацію.
- Чи має головний контент індексуватися?
- Чи можна створити HTML до request?
- Наскільки свіжими мають бути дані?
- Чи залежить результат від cookies, session або request?
- Скільки route треба генерувати?
- Чи можна безпечно кешувати сторінку?
- Скільки JavaScript має виконати браузер?
- Які реальні LCP, INP, CLS і TTFB у production?
