Как SPA снижает нагрузку на сервер

Что проверяют

Понимаете ли вы, что SPA не убирает нагрузку, а перераспределяет её: рендеринг уходит в браузер, статика на CDN, сервер отвечает только данными. Следом почти всегда спрашивают про обратную сторону: первую загрузку, SEO и почему публичные страницы снова рендерят на сервере.

Как отвечать

Разложите по механизмам:

• HTML не собирается на каждый переход: сервер отдаёт один index.html и бандл, дальше навигация идёт через History API на клиенте, а с бэкенда запрашивается только JSON. Шаблонизатор уходит из горячего пути;
• статика кешируется: файлы сборки с хешем в имени отдаются с Cache-Control: max-age=31536000, immutable через CDN, повторный визит почти не доходит до origin;
• клиентский кеш данных: TanStack Query, SWR или RTK Query держат ответы в памяти, склеивают одинаковые запросы и обновляют данные по схеме stale-while-revalidate;
• условные запросы: ETag и ответ 304 экономят трафик на неизменившихся данных;
• ленивая загрузка: import() и React.lazy подтягивают код раздела только при заходе в него.

Затем честно назовите, где SPA нагрузку не снижает. Первая загрузка тяжелее из-за бандла. Болтливое API с десятком запросов на экран даёт больше обращений, чем одна серверная страница, это лечат агрегирующим эндпоинтом или BFF. Поисковым ботам и превью в мессенджерах нужен готовый HTML, поэтому публичные страницы делают через SSR или статическую генерацию в Next.js, Nuxt, Astro, а чистое SPA оставляют для личного кабинета и админки.

Где спотыкаются

Говорят, что SPA вообще не ходит на сервер после загрузки. Данные всё равно запрашиваются, просто без HTML-обёртки.

Не упоминают CDN и хеши в именах файлов, хотя кеширование статики снимает с origin заметную часть трафика.

Выдают улучшение UX за снижение нагрузки. Быстрая навигация сама по себе запросов не убирает, их убирает кеш и продуманное API.