SSR — server-side rendering — у 2026 році всюди. Next.js робить його за замовчуванням. Nuxt робить. Astro робить. SvelteKit. Remix. Кожен новий фронтенд-фреймворк впевнено каже: «SSR — це правильно». Але у моєму опитуванні 35 українських фронтенд-команд тільки 12 насправді отримують вигоду від SSR. Інші 23 платять його ціну, не отримуючи benefit.
Що SSR дає насправді
Три речі. SEO — пошукові боти бачать готовий HTML, не чекаючи JavaScript-render. Це важливо для контентних сайтів, де органічний пошук — основний канал трафіку. Initial load performance — користувач бачить першу осмислену верстку швидше, що покращує Time-to-First-Contentful-Paint метрику. Social sharing — Open Graph мета працює одразу, без додаткових proxy.
Що SSR коштує
Складність. Серверна частина, що не існує у чистих SPA, — це ще одна частина системи, яку треба моніторити, масштабувати, дебажити. Server-component patterns у React 18+ — це окрема ментальна модель, що потребує перенавчання команди.
Вартість інфраструктури. Запустити чистий SPA — це CloudFront/CDN за $10-50 на місяць. Запустити SSR — це Vercel за $200+ або Kubernetes-кластер за $300-500. Це різниця у тисячах доларів на рік для маленької команди.
Складність деплою. CDN-розгортання — це загрузка статичних файлів у S3. SSR-deployment — це rolling restart, health checks, версіонування серверних і клієнтських частин одночасно.
Коли SSR потрібен
Маркетинг-сайти, новини, лендінги, e-commerce продакт-сторінки. Усе, що індексується пошуковими ботами. Тут SSR (або статичний site generation) — обов’язковий вибір.
Контент, що шериться у соцмережах. Twitter, LinkedIn, Facebook, Telegram — усі парсять HTML для preview. Без SSR ви побачите свій сайт зі стандартним preview, що шкодить click-rate.
Коли SSR не потрібен
Внутрішні дашборди, адмін-панелі, СRM-системи, SaaS-додатки за логіном. У 99% випадків ці системи не індексуються пошуковими ботами, не шеряться у соцмережах. Користувач, що увійшов у систему, не помітить різниці у Time-to-FCP між SPA і SSR — він робить це після login, він готовий зачекати.
Real-time додатки (Slack-like, Trello-like). Тут initial render швидкий не критичний — користувач буде у додатку годинами. SSR додає складність без відчутного benefit.
Що з цим робити
Не використовуйте Next.js за замовчуванням. Подумайте 30 хвилин перед вибором фреймворку: чи дає вам SSR конкретні бізнес-переваги (SEO трафік, соцмережі) або ви просто наслідуєте моду. Якщо ви будуєте B2B SaaS за логіном — Vite + React (або SvelteKit без SSR, або Astro з мінімальним JS) дадуть вам в 2-3 рази простішу інфраструктуру при тих самих бізнес-результатах.
Це пов’язано з ширшим трендом, про який ми писали раніше: команди тікають від «дефолтних» фреймворків, що додають складність без віддачі. SSR — той самий патерн, тільки на рівні архітектури.
