У звичайному Vue-застосунку (SPA) сервер віддає майже порожній HTML, а сторінку будує JavaScript у браузері. SSR рендерить ті самі компоненти на сервері в готовий HTML, а в браузері Vue «оживляє» його - гідрує.
Як це влаштовано:
- на сервері (Node.js) створюється застосунок, завантажуються дані, компоненти рендеряться в рядок HTML (
renderToStringзvue/server-renderer); - браузер отримує готову сторінку - вміст видно одразу, ще до завантаження JavaScript;
- завантажується той самий код застосунку, Vue проходить по існуючому DOM і прив'язує до нього реактивність та обробники подій, не перестворюючи елементи;
- далі застосунок працює як звичайний SPA.
Що це дає:
- швидший перший показ вмісту (LCP), особливо на повільних пристроях;
- SEO й превью соцмереж: пошукові роботи й боти соцмереж бачать вміст без виконання JavaScript;
- кращий досвід на поганому з'єднанні.
Ціна:
- потрібен Node.js-сервер (або платформа з підтримкою SSR) і його навантаження - рендер на кожен запит;
- код має працювати в обох середовищах: на сервері немає
window,document,localStorage. Звертатися до них можна лише вonMountedчи з перевірками; - стан між запитами: на сервері один процес обслуговує всіх користувачів - глобальні змінні модулів (синглтон-стор) ділитимуться між запитами і можуть показати дані одного користувача іншому. Застосунок і стор треба створювати на кожен запит;
- помилки гідрації, коли серверний і клієнтський HTML не збігаються.
Як роблять на практиці:
- Nuxt - фреймворк над Vue, що бере на себе SSR, маршрутизацію, завантаження даних і розгортання;
- Inertia SSR у Laravel-проєктах - Laravel віддає дані, окремий Node-процес (
php artisan inertia:start-ssr) рендерить сторінку Vue; - статична генерація (SSG) - HTML генерується під час збирання, якщо вміст не змінюється на кожен запит (документація, блог).
Коли SSR не потрібен: внутрішні панелі й кабінети за авторизацією - SEO там не важливий, а SPA простіший в експлуатації.