В какой-то момент мы поняли, что дальнейшая оптимизация svoivit.ru дает всё меньше результата.
Мы пробовали оптимизировать динамическую версию сайта, но стабильно получить время ответа сервера меньше 300–400 мс не удавалось.
При этом сам характер проекта подсказывал другое решение: большая часть контента на сайте меняется относительно редко.
Возник простой вопрос:
Зачем динамически генерировать страницу при каждом запросе, если большую часть времени ее содержимое остается тем же?
Так мы решили изменить архитектуру svoivit.ru: перейти с динамической генерации страниц на SSG, используя Astro.
Было → стало
До миграции:
≈ 300-400 мс - время ответа сервера.
После перехода на SSG:
≈ 60-70 мс.
То есть сайт стал отвечать примерно в 5-6,5 раз быстрее.
Если взять 350 мс как среднее значение до миграции, ускорение составляет примерно x 5,6.
И это уже не проценты оптимизации, а заметное изменение производительности за счет самой архитектуры.
Как теперь устроен сайт
У нас два основных источника данных:
Каталог «Свои в ИТ» → данные о сервисах, категориях и альтернативах
Konso.CMS → управляемый контент сайта через headless CMS
Во время сборки данные из этих источников превращаются в готовые статические страницы:
Каталог + Konso.CMS → Собираем все вместе → Статический веб сайт → CDN → Пользователь
В результате при открытии страниц пользователю больше не нужно ждать, пока серевер получит данные, обработает их и сформирует страницу.
Она уже готова.
Что мы имели до миграции
До миграции сайт работал как динамическое приложение на ASP.NET Core. При каждом обращении сервер участвовал в обработке запроса: выполнял необходимую бэкэнд-логику, получал данные в основном из кэша и формировал ответ. Сам по себе ASP.NET Core быстрый и производительный, поэтому проблема была не во фреймворке — мы просто достигли точки, где дальнейшая оптимизация динамической архитектуры давала всё меньший эффект. Для контентного сайта, где большинство страниц меняется относительно редко, постоянная генерация ответа на каждый запрос оказалась просто избыточной.
Что мы оптимизировали до перехода на SSG
Перед тем как менять архитектуру, мы попробовали выжать максимум из динамической версии. В первую очередь внедрили кеширование, чтобы не выполнять одну и ту же работу при каждом запросе, а также оптимизировали запросы к базе данных — убрали лишние обращения, пересмотрели наиболее тяжелые запросы и сократили время получения данных. Это дало результат, но дальше мы уперлись примерно в 300–400 мс. Стало понятно, что следующего существенного прироста скорости нужно искать уже не в очередной оптимизации кеша или SQL-запросов, а в изменении самого подхода к формированию страниц.
Почему Astro
Для статической версии мы используем Astro — для нас это уже проверенный временем фреймворк, на котором мы реализовали немало проектов. Он хорошо подходит именно для контентных сайтов: позволяет генерировать страницы заранее, практически не отправлять лишний JavaScript в браузер и при этом не ограничивает нас, когда на отдельных участках нужна интерактивность (hybrid). Поэтому при переходе на SSG вопрос выбора технологии практически не стоял — мы использовали уже знакомый и проверенный в production инструмент.
Что было важно учесть при миграции
Первое требование — не менять существующие URL.
Для поисковых систем переход на другую архитектуру вообще не должен выглядеть как переезд сайта.
Все основные пути страниц сохранились, поэтому нам не пришлось превращать техническую миграцию в отдельный SEO-проект с массовыми редиректами.
Второе — автоматизировать обновление сайта.
Мы не хотели, чтобы после перехода на SSG публикация контента превратилась в ручной процесс.
Поэтому схема выглядит так:
Изменение данных → Webhook → Сборка → Развертка
Меняется сервис в каталоге или контент в CMS — webhook автоматически запускает новую сборку и обновленная версия публикуется.
Для человека, который работает с контентом, архитектурные изменения практически незаметны.
Что мы не учли
Главное изменение оказалось не техническим, а скорее психологическим — смена парадигмы.
В динамическом приложении всё привычно:
поменяли запись → обновили страницу → увидели результат.
В SSG даже минимальное изменение означает новую сборку:
поменяли одно поле → пересобрали сайт → опубликовали новую версию.
Поначалу идея пересобирать весь сайт из-за небольшого изменения кажется немного странной.
Но когда весь процесс автоматизирован и занимает немного времени, к этому быстро привыкаешь.
А взамен пользователь всегда получает уже готовую страницу.
Результат
Главные цифры миграции:
300–400 мс → 60-70 мс
или примерно
× 5–6,5 быстрее.
Но для нас важнее другое: мы перестали пытаться бесконечно оптимизировать динамическую архитектуру и выбрали архитектуру, которая лучше соответствует характеру проекта.
У svoivit.ru много страниц и данных, но большая часть контента меняется не каждую секунду.
Поэтому вместо:
запрос → backend → данные → генерация страницы → пользователь
мы получили:
запрос → готовая страница → пользователь
Иногда лучший способ ускорить backend — просто убрать его из пользовательского запроса.