PrepBro
← Назад к вопросам

Для каких клиентов важно использовать SSR

2.0 Middle🔥 211 комментариев
#Браузер и сетевые технологии

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI2 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

SSR (Server-Side Rendering): для каких клиентов это критично

SSR (Server-Side Rendering) — это подход, при котором HTML страница генерируется на сервере и отправляется клиенту уже готовой, а не создаётся в браузере с помощью JavaScript. Это решает ряд проблем, критичных для определённых категорий пользователей.

Главные преимущества SSR

1. Более быстрая первоначальная загрузка (Initial Page Load)

При SSR пользователь видит содержимое страницы сразу, без ожидания загрузки и выполнения JavaScript:

// Без SSR (CSR - Client-Side Rendering)
// 1. Браузер загружает пустой HTML
// 2. Загружает bundle.js (100+ кб)
// 3. Выполняет React hydration
// 4. Делает API запрос
// 5. Рендерит контент
// Время до первого контента: 2-5 сек

// С SSR
// 1. Браузер получает готовый HTML с контентом
// 2. Пользователь видит контент сразу
// 3. Параллельно загружается JS для интерактивности
// Время до первого контента: 0.3-0.5 сек

2. Лучшая индексация поисковыми системами (SEO)

Поисковые боты (Googlebot, Yandex Bot) требуют готовый HTML. CSR приложения часто индексируются плохо:

<!-- Без SSR (видит бот) -->
<div id="root"></div>
<!-- Контент загружается JavaScript-ом, которого бот не выполняет -->

<!-- С SSR (видит бот) -->
<main>
  <h1>Заголовок статьи</h1>
  <p>Полный текст контента...</p>
  <meta property="og:title" content="Заголовок" />
</main>
<!-- Всё есть в HTML, бот легко индексирует -->

3. Работа с медленными интернет-соединениями

Для пользователей с 3G, медленным WiFi или мобильных сетей SSR критичен:

// CSR на медленной сети (2G/3G):
// - Скачать HTML (1 сек)
// - Скачать JS bundle 500кб (5-10 сек)
// - Выполнить JS (2-5 сек)
// - Загрузить API данные (2-5 сек)
// Итог: 10-25 сек до интерактивности

// SSR на медленной сети:
// - Скачать готовый HTML с контентом (1-2 сек)
// - Пользователь может начать читать сразу
// - Параллельно скачивается JS для интерактивности
// Итог: контент виден за 1-2 сек

Для каких клиентов SSR особенно важен

1. Пользователи с медленным интернетом

Это часто люди из развивающихся стран, сельских регионов, или использующие мобильный интернет:

// Статистика использования интернета (2024):
// - 3G: ещё 15-20% пользователей в мире
// - Медленный WiFi (1-2 мбит/с): 25-30%
// - Высокоскоростной интернет: только 50% пользователей

// Если твое приложение ориентировано на глобальную аудиторию,
// SSR — это NOT опционально

2. Мобильные пользователи

Мобильные браузеры имеют ограниченные ресурсы (память, процессор, батарея):

// Проблемы мобильных браузеров с CSR:
// - Ограниченная оперативная память (2-4 ГБ)
// - Слабый процессор (большой overhead от JS выполнения)
// - Потребление батареи (процессор работает дольше)
// - Перегрев устройства (при обработке больших bundles)

// С SSR:
// - Нет необходимости выполнять React на слабом устройстве
// - Пользователь видит контент и может начать взаимодействие
// - JS гидратация проходит в фоне

3. Пользователи с отключённым JavaScript

Хотя редко, но такие пользователи существуют:

// Причины отключения JavaScript:
// - Корпоративная безопасность (на рабочих ПК)
// - Privacy-режимы в браузерах
// - Некоторые пожилые пользователи
// - Браузеры с ограничениями (некоторые мобильные браузеры)

// С CSR: страница полностью неработающая
// С SSR: хотя бы статический контент доступен

4. Пользователи с браузерами более старшего поколения

Разработка должна быть доступна для старых браузеров:

// Статистика браузеров (2024):
// - Internet Explorer 11: ещё ~5% пользователей
// - Старые версии Safari (iOS 12-13): 10%
// - Старые версии Chrome: 15%

// IE 11 не поддерживает:
// - ES6 modules
// - Async/await
// - Promise (нужен полифилл)
// - Современный JavaScript

// С SSR: базовый функционал работает без JS

5. Бизнес-критичные приложения (e-commerce, новостные порталы)

Для e-commerce и контент-сайтов каждая секунда задержки = потеря пользователей:

// Исследования показывают:
// - 100ms задержки = 1% потеря конверсии
// - 1 сек задержки = 7% потеря конверсии
// - 3 сек задержки = 40% пользователей уходит

// Для сайта с 1 млн пользователей в месяц:
// - Улучшение загрузки на 1 сек = доп. 70 тыс. конверсий
// - SSR часто даёт улучшение на 2-5 сек

Практическое сравнение: CSR vs SSR vs ISR

// CSR (Client-Side Rendering)
// Пример: Сложное веб-приложение (Figma, Gmail)
const examples = {
  CSR: {
    «First Contentful Paint»: "2-5 sec",
    «Time to Interactive": "4-10 sec",
    SEO: "Плохо (нужен предрендеринг)",
    «Мобильные устройства": "Медленнее",
    «Мобильная интернет": "Очень медленно",
    сервер: "Минимальная нагрузка"
  },
  // ---
  SSR: {
    «First Contentful Paint": "0.5-1.5 sec",
    «Time to Interactive": "1-3 sec",
    SEO: "Отлично",
    «Мобильные устройства": "Быстро",
    «Мобильная интернет": "Быстро",
    сервер: "Средняя нагрузка"
  },
  // ---
  ISR: { // Incremental Static Regeneration (Next.js специально)
    «First Contentful Paint": "0.1-0.5 sec",
    «Time to Interactive": "0.5-2 sec",
    SEO: "Отлично",
    «Мобильные устройства": "Очень быстро",
    «Мобильная интернет": "Очень быстро",
    сервер: "Минимальная нагрузка (статика из CDN)"
  }
};

Реальный пример с Next.js

// pages/posts/[slug].tsx
import { GetStaticProps, GetStaticPaths } from next;

interface Post {
  id: string;
  title: string;
  content: string;
  publishedAt: string;
}

interface Props {
  post: Post;
}

// SSR: каждый запрос генерируется на сервере
export const getServerSideProps: GetServerSideProps<Props> = async (context) => {
  const { slug } = context.params as { slug: string };
  
  const response = await fetch(`https://api.example.com/posts/${slug}`);
  const post = await response.json();
  
  return {
    props: { post },
    revalidate: 60 // ISR: переgenerate через 60 сек
  };
};

// ISR: статическое генерирование с периодическим обновлением
export const getStaticProps: GetStaticProps<Props> = async (context) => {
  const { slug } = context.params as { slug: string };
  
  const response = await fetch(`https://api.example.com/posts/${slug}`);
  const post = await response.json();
  
  return {
    props: { post },
    revalidate: 3600 // Обновляй каждый час
  };
};

export const getStaticPaths: GetStaticPaths = async () => {
  const response = await fetch(https://api.example.com/posts);
  const posts: Post[] = await response.json();
  
  const paths = posts.map(post => ({
    params: { slug: post.id }
  }));
  
  return {
    paths,
    fallback: blocking // Новые посты генерируются при первом запросе
  };
};

export default function PostPage({ post }: Props) {
  return (
    <article>
      <h1>{post.title}</h1>
      <time>{new Date(post.publishedAt).toLocaleDateString()}</time>
      <div>{post.content}</div>
    </article>
  );
}

Когда SSR может быть ИЗБЫТОЧЕН

  • Приложения только для авторизованных пользователей (SaaS, админ-панели) — здесь SSR не помогает SEO
  • Высоконагруженные приложения (миллионы запросов в сек) — SSR может перегрузить сервер
  • Очень динамичный контент (чат, real-time данные) — каждый запрос даёт разные результаты
  • Нишевые приложения для опытных пользователей с современными браузерами

Итог

SSR критичен для:

  • Контент-сайтов, блогов, e-commerce
  • Приложений с глобальной аудиторией (включая развивающиеся страны)
  • Мобильного трафика
  • SEO-зависимых проектов

Выбор между CSR, SSR и ISR зависит от твоего use case:

  • ISR (Next.js) — лучший выбор для большинства проектов
  • SSR — когда контент часто меняется
  • CSR — только для нишевых приложений без SEO требований

В 2024 году тренд очевиден: большинство успешных фронтенд приложений используют SSR или ISR, потому что это даёт лучший пользовательский опыт для максимального количества пользователей.