🤔 Какие есть альтернативы ssr?
В современном веб-разработке существует несколько подходов к рендерингу веб-страниц, и помимо SSR (Server-Side Rendering), есть альтернативы, каждая из которых имеет свои особенности, преимущества и недостатки.
🚩CSR (Client-Side Rendering)
Вся логика рендеринга страницы осуществляется на стороне клиента (браузера) с помощью JavaScript. Сервер отправляет минимальный HTML (обычно пустой <div> с ID), а приложение загружается, рендерится и управляется на стороне клиента. Сервер отправляет статический HTML (например, через index.html), а JavaScript (чаще всего — библиотека/фреймворк, например React, Vue или Angular) загружает необходимые данные и динамически создает интерфейс. <div id="app"></div> <script src="bundle.js"></script>
🚩Плюсы
➕Быстрая работа после загрузки Приложение становится очень интерактивным после инициализации. ➕Меньшая нагрузка на сервер Основная работа выполняется на клиентской стороне. ➕Гибкость и модульность Легко добавлять сложные интерактивные компоненты.
🚩Минусы
➖Медленная первая загрузка (Time to First Byte, TTFB) Пользователь видит пустую страницу, пока загружается JavaScript и данные. ➕Проблемы с SEO Поисковым системам сложнее индексировать страницы, так как контент рендерится только в браузере. ➖Требования к устройствам Больше ресурсов требуется на стороне клиента.
🚩SSG (Static Site Generation)
Сайт полностью генерируется на этапе сборки (build time) и сервер отдает готовые HTML-страницы. Это популярный подход в JAMstack-приложениях (JavaScript, APIs, Markup). HTML генерируется один раз (обычно через фреймворк вроде Next.js, Gatsby, Nuxt.js) во время сборки. Сайт раздается пользователям как готовый статический контент. npm run build
🚩Плюсы и минусы
➕Молниеносная загрузка HTML статичен и отдается сервером без обработки. ➕SEO-дружелюбность Поисковые системы могут легко индексировать готовый HTML. ➕Уменьшение нагрузки на сервер Все вычисления выполняются заранее (во время сборки). ➖Ограничения при частых обновлениях контента Для обновления нужно заново пересобирать сайт, что может занимать много времени. ➖Не подходит для динамических данных Если страница сильно зависит от данных пользователя или часто меняется, SSG становится менее удобным.
🚩ISR (Incremental Static Regeneration)
Это гибрид между SSG и SSR. Вы создаете статический контент во время сборки, но некоторые страницы могут обновляться динамически при запросе, а сервер сохраняет их для следующих пользователей. Фреймворк (например, Next.js) генерирует страницы на этапе сборки, но для определенных страниц вы можете указать интервал обновления (revalidate). После этого сервер пересоберет страницу и кэширует ее. export async function getStaticProps() { return { props: { data: fetchData(), }, revalidate: 60, // Обновлять страницу каждые 60 секунд }; }
🚩Плюсы и минусы
➕Лучшая производительность Страницы отдаются как статические, но обновляются при необходимости. ➕Гибкость Удобно для контента, который редко обновляется. ➕SEO Поисковики видят статические страницы. ➖Сложнее настроить Нужно управлять кэшированием и интервалами обновления. ➖Не подходит для полностью динамических страниц Если обновления контента слишком частые, ISR может не подойти.
🚩DPR (Dynamic Rendering / Hybrid Rendering)
Это подход, при котором разные версии страницы рендерятся для разных пользователей. Например, для пользователей с обычными браузерами вы используете CSR, а для поисковых ботов — SSR. Запросы от поисковых ботов обрабатываются сервером, который генерирует готовый HTML. Запросы от обычных пользователей обрабатываются через CSR. Этот подход используется с инструментами, такими как Prerender.io или встроенными решениями фреймворков.
🚩Плюсы и минусы
➕Оптимально для SEO Боты получают готовый HTML. ➕Гибкость Пользователи получают интерактивные страницы через CSR. ➖Усложнение архитектуры Нужно отслеживать запросы и разделять их. ➖Задержки для ботов Генерация страницы на сервере может занять время.
Ставь 👍 и забирай 📚 Базу знаний