Що таке SSR і чому не всі сторінки завантажуються однаково

Відкрий будь-який сучасний сайт — і ти побачиш текст, картинки, кнопки. Все на екрані. Але якщо заглянути під капот, виявляється, що одні сайти приходять до тебе вже готовими — з текстом і структурою. А інші приходять як порожня сторінка з набором інструкцій: «а тепер, браузер, зроби те, зроби це, і користувач щось побачить».

SSR (Server-Side Rendering) — це коли сервер збирає HTML-сторінку до того, як відправити її тобі. Ти отримуєш готовий контент одразу — браузеру не треба нічого будувати з нуля.

Протилежність — CSR (Client-Side Rendering), коли браузер отримує порожню HTML-сторінку і JavaScript-код, який потім будує весь інтерфейс сам.

Проблема / контекст: чому SPA не завжди добре

Останні 10-15 років модно було робити SPA (Single Page Application). Ідея красива: один раз завантажуєш застосунок, а потім все працює швидко, без перезавантажень сторінки. React, Vue, Angular — всі вони про це.

Але є три проблеми, які SPA не вирішує:

1. Повільне перше завантаження. Коли користувач заходить на SPA-сайт, спочатку він бачить порожній екран або лоадер. Браузер завантажує JavaScript-бандл (іноді кілька мегабайт), потім виконує його, тільки потім будує DOM, і тільки тоді з’являється контент. На швидкому інтернеті це секунда. На мобільному 3G — 5-10 секунд.

2. SEO. Пошукові боти не завжди добре розуміють JavaScript. Google стає кращим, але Bing, Yahoo, поширення в соцмережах — не завжди. Якщо контент генерується на клієнті, пошуковий бот може буквально нічого не побачити.

3. Доступність. Люди з повільними пристроями, старими телефонами, або ті, хто вимкнув JavaScript з міркувань безпеки/батареї — отримують порожню сторінку.

SSR вирішує всі три: сервер відправляє готовий HTML, контент видно одразу, SEO працює з коробки, навіть найслабший телефон показує текст.

Як це працює простими словами

SSR — сервер збирає HTML

  1. Ти відкриваєш сайт.
  2. Браузер посилає запит на сервер.
  3. Сервер збирає повну HTML-сторінку з контентом.
  4. Відправляє її тобі.
  5. Ти бачиш текст і картинки миттєво.
  6. Потім JavaScript «гідратує» (hydration) — додає інтерактивність: кліки, форми, анімації.
Браузер → запит → Сервер → генерує HTML → Браузер показує → JavaScript додає інтерактивність

Приклад того, що приходить з сервера:

<html>
  <body>
    <h1>Привіт, ITAcademy!</h1>
    <p>Це сервер згенерував цей текст.</p>
  </body>
</html>

CSR — браузер збирає HTML

  1. Ти відкриваєш сайт.
  2. Браузер завантажує порожній HTML і великий JS-файл.
  3. JavaScript виконується в браузері.
  4. JavaScript будує HTML-структуру.
  5. Нарешті ти бачиш контент.
Браузер → запит → Сервер відправляє HTML-шаблон + JS-файл →
JavaScript завантажується → виконується → будує DOM → користувач бачить контент

Приклад того, що приходить з сервера:

<html>
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>  <!-- тут живий весь сайт -->
  </body>
</html>

SSG — сторінки збираються заздалегідь

Є ще третій підхід — Static Site Generation: сторінки збираються один раз під час білду і зберігаються як звичайні HTML-файли. Коли хтось запитує сторінку, сервер просто віддає готовий файл. Це найшвидший варіант, але підходить не для всього (наприклад, для персональних кабінетів не підійде).

Порівняння: коли що обирати

SSRCSR (SPA)SSG
Перший рендерШвидкий (готовий HTML)Повільний (чекає JS)Миттєвий (готовий файл)
SEO✅ відмінний⚠️ залежить від бота✅ відмінний
Інтерактивність✅ після гідратації✅ зразу✅ після гідратації
Навантаження на серверВище (генерує кожний запит)Нижче (тільки віддача JS)Мінімальне (віддає файли)
Персоналізація✅ (кожен користувач — своя сторінка)✅❌ (сторінка одна для всіх)
Особисті кабінети✅✅❌
Блоги / документація✅✅✅ (найкращий варіант)

Коли SSR — найкращий вибір

SSR ідеально підходить коли:

Коли SSR — не треба

SSR не варто обирати коли:

Типові помилки при роботі з SSR

1. Гідратуція ламається

Якщо HTML від сервера відрізняється від того, що JavaScript будує сам, React (або інший фреймворк) скидає все і будує з нуля. Це називається hydration mismatch. Результат: контент блимає або інтерактивність не працює.

2. Занадто багато API-запитів на сервері

Сервер генерує сторінку для кожного користувача. Якщо для цього треба зробити 20 запитів до різних API — сторінка буде повільною. Вирішення — кеш, агрегування даних або SSG з перегенерацією.

3. Плутати SSR з SSG

SSG генерує сторінки наперед (під час білду). SSR генерує при кожному запиті. Якщо контент не змінюється часто SSG швидший і дешевший.

4. Ігнорувати помилки на сервері

У SPA помилка JavaScript показується користувачу. У SSR помилка сервера може повернути порожню сторінку або серверну помилку. Потрібно правильно обробляти помилки в server-коді.

Висновок / план дії

SSR — це не магія і не обов’язок. Це інструмент, який робить сайт швидшим і доступнішим для тих, кому це важливо.

Що зробити найближчим часом:

  1. Подивись на свій сайт: чи є у тебе SSR, чи тільки CSR, чи SSG?
  2. Перевір швидкість через PageSpeed — зверни увагу на LCP (коли з’являється головний контент).
  3. Якщо сайт потребує кращого SEO або швидшого першого рендеру — спробуй Next.js (для React) або Nuxt (для Vue).
  4. Для контентних сторінок (блог, документація, пости) розгляни SSG — це ще швидше за SSR.
  5. Не перебудовуй все одразу почни з однієї сторінки і порівняй метрики.

Не кожному сайту потрібен SSR. Але якщо контент важливий і має бути знайдений через пошук — SSR може бути найпростішим способом зробити сайт кращим без повного переписування.