Производительность Next.js за пределами интерфейса

Контекст

После перехода проекта от внешней команды к внутренней разработке требовалось разобраться в существующей кодовой базе и составить план рефакторинга. Отдельной задачей была производительность Next.js-приложения с серверным рендерингом.

Мой вклад

Я провёл аудит приложения и выстроил план рефакторинга. В клиентской части внедрил Flux-архитектуру с Redux и вынес бизнес-логику в middleware.

Для работы с нагрузкой написал Node.js-прокси, кэширующий готовые SSR-ответы перед Next.js. Также работал над пропускной способностью бэкенд-инфраструктуры: Redis, кластеризацией и оптимизацией Docker-сети.

Два отдельных направления

Кэширование готового ответа и оптимизация бэкенда решали разные задачи. Первый механизм позволял повторно использовать результат серверного рендеринга. Второе направление касалось обработки запросов в серверной части и её инфраструктуре.

Разделять эти изменения важно и при оценке результата: пропускная способность слоя выдачи страниц не равна пропускной способности API.

Проверка и эксплуатация

В проекте я настраивал CI/CD, feature flags, Sentry и Loki, unit- и интеграционные тесты. Этот опыт связал для меня изменения в приложении с проверкой и эксплуатацией системы.

Результат

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

Точные показатели нагрузки будут добавлены после уточнения сценария и условий измерения.