Surf 
Тендеры и лиды
Информация
Single Page Application давно перестало быть модным словом и стало дефолтом «по привычке». Разбираем, где эта привычка оправдана, а где превращается в дорогую ошибку — с SEO, первой отрисовкой и реальными устройствами пользователей.
Про SPA обычно пишут одно и то же: одна страница, контент подгружается без перезагрузки, примеры — Gmail и Trello, плюсы, минусы, конец. Всё верно и всё бесполезно, если вы стоите перед реальным вопросом: собирать новый продукт как SPA или нет. За последние годы фронтенд ушёл далеко вперёд, а рефлекс «делаем на React, значит SPA» остался. И именно этот рефлекс чаще всего оборачивается проблемами, которые всплывают уже после запуска.
Мы в Surf занимаемся веб-разработкой и держим в одной команде фронтенд и бэкенд, поэтому смотрим на SPA не как на способ по умолчанию, а как на один из вариантов доставки интерфейса — со своей областью применения и своей ценой. Ниже — как выбирать осознанно.
Классический SPA работает так: браузер один раз загружает почти пустой HTML и большой JavaScript-бандл, а дальше весь рендеринг происходит на клиенте. Переходы между «страницами» — это не запросы к серверу за новым документом, а перерисовка DOM силами JavaScript; данные подтягиваются отдельными запросами к API. Сервер при этом превращается в поставщика данных и не думает о том, как их показать.
Отсюда растут все свойства SPA — и хорошие, и плохие. Хорошие: после первой загрузки интерфейс отзывчивый, переходы мгновенные, бэкенд и фронтенд можно разрабатывать параллельно через API-контракт. Плохие начинаются там, где важен не «второй клик», а первый.
React, Vue и Angular по умолчанию собирают именно клиентский рендеринг (CSR), и для многих команд «сделать на React» автоматически означает «сделать SPA». Проблема в том, что клиентский рендеринг перекладывает всю работу на устройство пользователя и на его сеть. Пока пользователь — разработчик с MacBook и оптоволокном, всё летает. В реальности значительная доля аудитории заходит со среднего Android за 15 тысяч рублей по мобильному интернету, и там пустой экран висит, пока не скачается и не выполнится многомегабайтный бандл.
Три момента, которые SPA-рефлекс игнорирует, а потом они больно бьют:
Первая отрисовка. Пользователь видит белый экран до тех пор, пока не загрузился и не отработал JavaScript. Для контентного сайта или лендинга это прямая потеря пользователей и просадка Core Web Vitals.
SEO. Поисковику надо отдать контент, а не пустой <div id="root">.
Вес на клиенте. Бандл на 1–3 МБ JavaScript — обычное дело для выросшего SPA, и каждый мегабайт замедляет старт на слабых устройствах.
Самый частый провал, который мы разгребаем на аудитах, — контентный или e-commerce-сайт, собранный как чистый SPA, который плохо индексируется. Разберём, почему так происходит.
Googlebot умеет исполнять JavaScript и в итоге видит отрендеренную страницу, но делает это в два прохода и с задержкой: сначала индексирует голый HTML, а рендеринг откладывает в очередь, которая может разгребаться днями. Для новостей, карточек товаров и часто меняющегося каталога такая задержка означает, что свежий контент попадает в индекс с опозданием или не полностью. Яндекс с клиентским JavaScript традиционно справляется хуже Google, а это половина рынка в рунете.
Лечится это переносом рендеринга на сервер. Варианты по возрастанию сложности:
SSR (server-side rendering). Сервер отдаёт уже готовый HTML, а потом JavaScript «оживляет» страницу (гидрация). Поисковик и пользователь сразу получают контент. Так работают Next.js для React и Nuxt для Vue.
SSG (static site generation). Страницы собираются в статический HTML заранее, на этапе сборки. Идеально для контента, который меняется не каждую секунду: блог, документация, маркетинговые страницы.
Dynamic rendering. Костыль, когда поисковику отдают заранее отрендеренную версию, а людям — обычный SPA. Google сам называет это временным решением, и городить его стоит, только если переписать архитектуру нельзя.
Вывод простой: если странице нужен поисковый трафик, чистый клиентский SPA — плохая отправная точка. Нужен серверный рендеринг с самого начала.
В 2026 году выбор давно не бинарный «SPA или классический сайт». Есть спектр:
Чистый SPA (CSR). Всё на клиенте. Уместен там, где SEO не нужен вообще: интерфейсы за логином, внутренние панели, дашборды.
SSR (Next.js, Nuxt). Гибрид: первый экран приходит с сервера, дальше приложение ведёт себя как SPA. Дефолт для публичных продуктов, которым нужны и интерактивность, и индексация.
SSG. Статика для контентных проектов; при необходимости догружает динамику точечно.
Островная архитектура (Astro и подобные). Страница статична, а «острова» интерактивности подгружают JavaScript только там, где он реально нужен. Отличный вариант для контентных сайтов с вкраплениями интерактива, где тащить весь фреймворк на каждую страницу расточительно.
Практический ориентир: начинайте с вопроса «нужен ли этой странице поисковый трафик и быстрый первый экран». Если да — смотрите в сторону SSR или SSG, а не чистого SPA.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
SPA принято хвалить за скорость, но скорость эта наступает после первой загрузки. До неё пользователь ждёт, и метрики это показывают:
TTI (Time to Interactive) у тяжёлых SPA на среднем мобильном устройстве легко уходит за 5–10 секунд, пока парсится и исполняется бандл.
LCP (Largest Contentful Paint) страдает от того же белого экрана и часто не проходит порог «хорошо» в Core Web Vitals.
Память. SPA держит состояние и загруженные ресурсы в памяти вкладки; в долгих сессиях с тяжёлыми данными это приводит к разбуханию потребления ОЗУ и подтормаживаниям на слабых устройствах.
Лечится это не магией, а дисциплиной: разбиение бандла на части (code splitting), ленивая загрузка маршрутов, вынос первого экрана на сервер. Но всё это — работа, которую в момент выбора «а давайте SPA» обычно не закладывают.
Чтобы не сложилось впечатление, что SPA устарел, — вовсе нет. Есть класс задач, где он оптимален:
Интерфейсы за авторизацией. Личные кабинеты, админки, дашборды, CRM. SEO не нужен, зато нужна плотная интерактивность и мгновенные переходы.
SaaS и рабочие инструменты. Всё, что ближе к приложению, чем к сайту: таск-трекеры, редакторы, аналитические панели.
Сложные многошаговые сценарии. Конфигураторы, калькуляторы, интерфейсы с состоянием, которое живёт между экранами.
И когда SPA — плохая идея как единственное решение: контентные сайты, лендинги, блоги, витрины и каталоги интернет-магазинов, то есть всё, что живёт за счёт поиска и первого экрана.
Типичный сценарий из практики: приходит проект, где публичный каталог собран как чистый SPA, а трафик из поиска не растёт, хотя вложились в контент. На аудите выясняется, что карточки товаров индексируются с задержкой и не полностью, потому что поисковик видит их только после рендеринга JavaScript. Решение — не переписывать всё с нуля, а вынести на серверный рендеринг именно те разделы, которым нужен поиск: каталог и карточки. Личный кабинет и корзину при этом спокойно оставляем клиентским SPA — там SEO не при чём. Гибрид почти всегда честнее, чем религиозная приверженность одному подходу.
Второй частый случай — мобильная аудитория. Когда большая доля пользователей сидит со слабых устройств, мы сознательно режем бандл и выносим первый экран на сервер, потому что разница между «экран за секунду» и «белый экран на восемь секунд» — это разница в конверсии, а не в бенчмарках. Если продукту в принципе нужен телефон в кармане пользователя, стоит честно сравнить SPA-в-обёртке с полноценной мобильной разработкой.
Нужен поисковый трафик? Да — не чистый SPA, берите SSR/SSG.
Контент за логином? Да — SPA уместен.
Много слабых мобильных устройств в аудитории? Да — серверный рендеринг и жёсткий контроль веса бандла.
Первый экран критичен для конверсии? Да — рендерите на сервере.
Продукт ближе к приложению, чем к сайту? Да — SPA хорошо ложится.
SPA — не сайт «по умолчанию», а один из способов рендеринга со своей нишей.
Его сильная сторона (всё на клиенте) же становится слабой: белый первый экран, проблемы SEO, вес на слабых устройствах.
Для публичных продуктов с поисковым трафиком отправная точка — SSR или SSG, а не чистый клиентский рендеринг.
Чистый SPA уместен за авторизацией: кабинеты, админки, SaaS, сложные интерфейсы с состоянием.
Выбор в 2026 не бинарный: между «сайтом» и «SPA» лежит спектр — SSR, SSG, острова; почти всегда выигрывает гибрид.
SPA не хорош и не плох сам по себе — плоха привычка выбирать его не глядя. Правильный вопрос звучит не «делаем SPA?», а «что этой конкретной странице важнее: интерактивность за логином или контент и первый экран для поиска». Ответ на него и определяет архитектуру, а название технологии — уже следствие.
Владимир Макеев, генеральный директор Surf — компании по разработке и дизайну цифровых продуктов для крупного и среднего бизнеса.
