H-Studio
Обсудить проект
Оптимизация React и Next.js — H-Studio
Услуга · React performance

Оптимизация React и Next.js — инженерный процесс⁠.

Не «накрутим Lighthouse ради скриншота» — конкретные цели на реальных мобильных пользователях.

Формат
Аудит и оптимизация фронтенда
Подходит для
Next.js · React · SaaS · Сайты · Кабинеты · Дашборды
Срок до аудита
1–2 недели
Подход · Core Web Vitals на 75-м перцентиле

LCP < 2.5 с, INP < 200 мс, CLS < 0.1 — на реальных мобильных пользователях.

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

Senior frontend без джуниоров. От 100 000 ₽ за аудит, 1–10 недель оптимизации.

От 100 000 ₽ за аудит, 1–10 недель оптимизации. Senior frontend без джунов.
01 · Сигналы что фронтенд пора оптимизировать

К нам приходят в одной из четырёх стадий.

У каждой стадии — свой корень проблемы и свой формат работ. На первой встрече фиксируем стадию и предлагаем тариф под неё.

Scenario · 01

“Сайт на Next.js медленный, хотя стек современный”

Страницы открываются 5–10 секунд, изображения грузятся тяжело, Core Web Vitals показывают красный (LCP > 2.5 с, INP > 200 мс или CLS > 0.1), пользователи уходят до заявки. Обычно проблема не в самом Next.js — а в том, как его использовали: «use client» везде, тяжёлые зависимости, неправильная стратегия рендеринга, отсутствие оптимизации изображений, блокирующие сторонние скрипты. Что мы делаем: аудит Web Vitals на реальных страницах, анализ бандла, ревью рендеринга (CSR vs SSR vs SSG баланс), оптимизация изображений и шрифтов, разделение кода, удаление лишних зависимостей.

Scenario · 02

“React-приложение зависает при работе”

Дашборды, таблицы, фильтры, формы или админ-панели работают медленно — особенно на реальных данных (от 1000 строк) и слабых устройствах (mid-range мобильные). Прокрутка тормозит, ввод в форму отстаёт, фильтры срабатывают с задержкой. Что мы делаем: профилирование компонентов через React DevTools, поиск лишних повторных рендеров, оптимизация границ состояния, виртуализация длинных списков, debouncing форм и фильтров, мемоизация там где она реально нужна.

Scenario · 03

“Каждая новая функция увеличивает бандл”

Проект растёт, команда добавляет библиотеки и фичи, но никто не контролирует вес JavaScript. Начальный бандл был 200 КБ, через год стал 800 КБ, ещё через год — 1.5 МБ. Загрузка ухудшается с каждым релизом, особенно на мобильном. Что мы делаем: анализ бандла через @next/bundle-analyzer или webpack-bundle-analyzer, выявление тяжёлых зависимостей, динамические импорты для тяжёлых частей, правила для команды (лимит бандла в CI), документирование гайдлайнов.

Scenario · 04

“После редизайна или миграции упали скорость и SEO”

Новый сайт красивый, но стал тяжелее: хуже Web Vitals, медленнее страницы, нестабильная вёрстка (CLS), больше JavaScript, проблемы с индексацией. Поисковики начали понижать в выдаче. Что мы делаем: сравнение старая vs новая версия, проверка стратегии рендеринга (часто SPA без SSR — это причина), анализ sitemap и ключевых страниц, оптимизация страниц по приоритету. Если это восстановление после неудачной миграции — см. также страницу «SEO-миграция и перезапуск».

02 · Что оптимизируем

Восемь направлений с конкретными метриками⁠.

На 75-м перцентиле реальных мобильных пользователей (полевые данные из Search Console и PageSpeed Insights), а не на dev-машине разработчика.

01

Core Web Vitals и скорость загрузки

Конкретные цели по рейтингу «Good»: LCP (Largest Contentful Paint) < 2.5 с; INP (Interaction to Next Paint) < 200 мс; CLS (Cumulative Layout Shift) < 0.1; TTFB (Time to First Byte) < 800 мс. Что оптимизируем: LCP — оптимизация hero-изображений, загрузка шрифтов, время ответа сервера, блокирующие ресурсы. INP — тяжёлые обработчики событий, длинные задачи, блокировка JavaScript. CLS — размеры изображений, font swap, динамическое позиционирование контента, поздняя загрузка рекламы. TTFB — ответ сервера, стратегия кэширования, edge-деплой.

02

Размер бандла и лишний JavaScript

Анализ бандла с детализацией по чанкам. Выявление тяжёлых зависимостей (часто moment.js, lodash, библиотеки графиков). Разделение кода по маршрутам и фичам. Динамические импорты для контента ниже первого экрана. Tree shaking. React.lazy + Suspense для условных фич. Замена тяжёлых библиотек на легче (date-fns вместо moment, recharts вместо chart.js когда применимо). Удаление мёртвого кода. Цель: начальный JS-бандл < 200 КБ в gzip, чанки на маршрут < 50 КБ.

03

Рендеринг React и компоненты

Профилирование через React DevTools Profiler. Поиск лишних повторных рендеров. Оптимизация границ состояния (поднимание состояния вниз). Context API без глобального состояния. Мемоизация (React.memo, useMemo, useCallback) только там, где она реально помогает (часто она не нужна или вредит). Серверные vs клиентские компоненты — правильный баланс. Виртуализация длинных списков (react-window, TanStack Virtual). Suspense-границы для потоковой передачи.

04

Рендеринг и загрузка данных в Next.js

Аудит стратегии рендеринга (SSG / SSR / ISR / CSR). Статическая генерация где возможно (наибольший выигрыш для скорости). ISR для динамического контента с кэшем. Ревью серверных vs клиентских компонентов. Разделение кода на уровне маршрутов. Паттерны загрузки данных (параллельная vs водопад, потоковая передача). next/image для всех изображений. next/font для шрифтов с правильным fallback. Edge Runtime где применимо.

05

Управление состоянием и поток данных

React Query или SWR для состояния сервера (кэширование, инвалидация, предзагрузка). Zustand или Jotai для состояния клиента когда нужно (вместо тяжёлого Redux). Оптимистичные обновления для воспринимаемой производительности. Предзагрузка для предсказуемой навигации. Паттерны stale-while-revalidate.

06

Изображения и медиа

Конфигурация next/image с правильными точками перелома. WebP и AVIF с fallback. Ленивая загрузка с правильными приоритетами. Приоритетная загрузка LCP-изображения. Адаптивные размеры изображений. Настройка CDN для изображений (Vercel, Hetzner, Yandex Object Storage).

07

Шрифты и CSS

next/font для самостоятельного хостинга Google Fonts. Font display: swap или optional. Извлечение критического CSS. PurgeCSS и Tailwind purge для удаления неиспользуемого CSS. Баланс CSS Modules и Tailwind.

08

Сторонние скрипты

Аудит всех внешних скриптов. next/script с правильной стратегией (afterInteractive, lazyOnload, beforeInteractive). Собственный хостинг аналитики где возможно (Plausible self-hosted). Defer и async для некритических скриптов. Ленивая загрузка для виджетов (чат, соцсети).

03 · Три ключевых решения до старта оптимизации

Самые дорогие ошибки performance принимаются до первой строчки кода⁠.

  1. 01

    Точечные оптимизации или архитектурный рефакторинг — с чего начинать?

    Точечные оптимизации (1–3 недели) — оптимизация изображений (next/image, WebP), оптимизация загрузки шрифтов (next/font), оптимизация сторонних скриптов, размер бандла через простые динамические импорты, меньше клиентских компонентов где можно. Типичный эффект: LCP −30–50%, INP −20–40%, CLS −50%. Подходит когда сайт работает, но медленный, архитектура в целом OK. Архитектурный рефакторинг (4–10 недель) — миграция стратегии рендеринга (CSR → SSG/SSR), реструктуризация управления состоянием, переход на серверные компоненты (App Router), редизайн паттернов загрузки данных. Типичный эффект: полная трансформация, может улучшить все метрики в 2–5 раз. Подходит когда фундаментальные проблемы: SPA без SSR, монолитное состояние, нет разделения на уровне маршрутов. Правильная последовательность: точечные оптимизации → измеряем → если ещё не достаточно → архитектурный рефакторинг. Не начинаем с рефакторинга если точечные не пробовали.

  2. 02

    Стратегия рендеринга — где какая?

    CSR (рендеринг на клиенте) — только для авторизованных app-страниц где SEO не критичен (внутренние инструменты, дашборды). SSR (серверный рендеринг) — динамические страницы, где контент меняется на каждый запрос (персонализация, real-time данные); когда нужен SEO + персонализация одновременно. SSG (статическая генерация) — наш выбор по умолчанию для публичных страниц: маркетинг, лендинг, блог, документация. Лучшие Core Web Vitals (LCP < 1.5 с типично), edge-кэширование из коробки. ISR (инкрементальная статическая регенерация) — динамические каталоги с регулярными обновлениями, маркетплейс-листинги, страницы товаров. Лучшее из статики и динамики. Потоковая SSR (App Router) — долгие серверные операции с частичным рендерингом. Не выбираем «что модно» — выбираем по характеристике контента и пути пользователя.

  3. 03

    Серверные vs клиентские компоненты — какой баланс?

    App Router в Next.js 13+ дал новое измерение: каждый компонент явно серверный или клиентский. Серверные компоненты (наш выбор по умолчанию) — без JavaScript в бандле, прямой доступ к БД, файлам и переменным окружения, лучше SEO (HTML рендерится на сервере), без интерактивности (нельзя onClick, useState). Клиентские компоненты («use client») — с JavaScript в бандле, интерактивность, хуки, браузерные API. Должно быть минимально. Правильный баланс: листья (интерактивные части) — клиент, всё остальное — сервер. Реальный пример из наших проектов: My Office Asia — 400+ компонентов, только 83 клиентских (остальные серверные). Это правильное соотношение для продакшен-сайта. Анти-паттерн: «use client» на корневом макете — всё приложение становится CSR.

04 · Открытые цены · Без скрытых пунктов

От performance-аудита до архитектурного рефакторинга⁠.

Шесть форматов с гибкой комбинацией. Можно начать с любого и остановиться после него. Срок до аудита и плана — 1–2 недели независимо от тарифа.

Аудит

Performance-аудит

Полный аудит: замеры Web Vitals (лабораторные + полевые), анализ бандла, ревью рендеринга, аудит изображений, шрифтов, сторонних скриптов, профилирование React ключевых страниц. Документ с рекомендациями и приоритетами. Можно остановиться — план остаётся у вас.

от 100 000 ₽
├1–2 недели┤
  • Замеры Web Vitals (лабораторные + полевые)
  • Анализ бандла и зависимостей
  • Ревью стратегии рендеринга
  • Аудит изображений, шрифтов, сторонних скриптов
  • Профилирование React ключевых страниц
  • План работ с приоритетами
Запустить аудит
Точечные

Точечные оптимизации

Реализация рекомендаций аудита по приоритету: оптимизация изображений, загрузка шрифтов, сокращение бандла (low-hanging fruit), критический CSS, сторонние скрипты. Типичный результат — рейтинг «Good» по Core Web Vitals на ключевых страницах.

от 200 000 ₽
├2–3 недели┤
  • Оптимизация изображений с next/image
  • Загрузка шрифтов с next/font
  • Сокращение бандла на 30–50%
  • Извлечение критического CSS
  • Оптимизация сторонних скриптов
  • Замеры до/после
Обсудить точечные
Чаще выбирают
Стандартная

Стандартная оптимизация

Точечные оптимизации + архитектурный рефакторинг узких мест: оптимизация рендеринга React, реструктуризация управления состоянием, стратегия разделения кода, паттерны загрузки данных, оптимизация тяжёлых компонентов.

от 500 000 ₽
├4–6 недель┤
  • Всё из точечных оптимизаций
  • Профилирование и оптимизация рендеринга
  • Реструктуризация управления состоянием
  • Стратегия разделения кода
  • Оптимизация загрузки данных
  • Виртуализация длинных списков
Обсудить стандарт
Рефакторинг

Архитектурный рефакторинг

Глубокая работа с архитектурой: миграция CSR → SSG/SSR где применимо, переход на App Router (серверные компоненты), полная пересборка управления состоянием, переписывание тяжёлых компонентов, настройка бюджета производительности.

от 1 000 000 ₽
├6–10 недель┤
  • Всё из стандартной оптимизации
  • Миграция CSR → SSG/SSR
  • Переход на App Router и серверные компоненты
  • Полная пересборка управления состоянием
  • Переписывание тяжёлых компонентов
  • Настройка бюджета производительности в CI
Обсудить рефакторинг
Восстановление

Восстановление после редизайна

Экстренный тариф: восстановление производительности после неудачного редизайна или миграции. Аудит что произошло, план восстановления, реализация исправлений, мониторинг 4–6 недель.

от 300 000 ₽
├4–8 недель┤
  • Аудит причин падения скорости
  • План восстановления с приоритетами
  • Реализация исправлений
  • Мониторинг 4–6 недель
  • Документация для команды
Обсудить восстановление
Постоянный

Постоянный мониторинг производительности

Постоянный мониторинг Web Vitals на реальном трафике, оперативное реагирование на регрессии, регулярный аудит бандла (раз в 4–8 недель), оптимизация новых фич команды, документирование performance-гайдлайнов.

от 50 000 ₽/мес
├помесячно┤
  • Ежедневный мониторинг Web Vitals
  • Еженедельный обзор бандла
  • Месячный комплексный аудит
  • Оповещения при регрессиях
  • Performance-ревью для крупных фич
  • Квартальные рекомендации
Обсудить мониторинг
05 · Почему H-Studio для performance

Сначала измеряем, потом правим⁠.

  1. 01

    Сначала измеряем, потом правим

    Большинство «performance-экспертов» начинают с совета «добавьте React.memo везде» или «лучше используйте такую-то библиотеку». Это путь к добавленной сложности без измеримого улучшения. Сначала измеряем: Web Vitals на реальном трафике (Search Console, полевые данные PageSpeed Insights); состав бандла через webpack-bundle-analyzer; паттерны рендеринга через React DevTools Profiler; сетевой waterfall в Chrome DevTools. После измерений — явные рекомендации с приоритетами по влиянию.

  2. 02

    Оптимизируем причину, а не симптом

    Медленный фронтенд редко связан с одной картинкой или библиотекой. Обычно проблема архитектурная (SPA без SSR, тяжёлый клиентский рендеринг, структура состояния); в управлении состоянием (лишние повторные рендеры, злоупотребление Context, prop drilling); в загрузке данных (водопады, нет кэширования, нет предзагрузки); в границе серверных и клиентских компонентов (серверные компоненты не используются). Заменить одну картинку = видимая точечная победа. Но если не починить корневую причину — производительность вернётся к плохой через 1–2 месяца разработки.

  3. 03

    Знание React и Next.js на уровне 2026 года

    Знаем актуальное состояние: React Compiler (стабилен с React 19) — автоматическая мемоизация, многие ручные React.memo стали ненужными. App Router + Server Components (Next.js 13+) — правильный паттерн для 2026, не Pages Router. INP заменил FID как Core Web Vital. Server Actions для мутаций форм. Streaming SSR и Suspense boundaries. Partial Prerendering (PPR) — гибридный подход Next.js 15. Не используем устаревшие паттерны (HOC, ручная мемоизация везде, getServerSideProps когда не нужно, useEffect для каждой задачи загрузки данных).

  4. 04

    SEO и производительность работают вместе

    Для сайтов и систем привлечения клиентов производительность — это прямой SEO-сигнал. Google использует Web Vitals как фактор ранжирования с 2021 года. В 2026 ещё критичнее с AI-обзорами. Что значит на практике: LCP > 4 с = понижение в выдаче; высокий CLS = понижение в выдаче; плохая мобильная производительность = понижение в mobile-first индексации; медленное выполнение JS = плохая обходимость. Не делаем performance-работу без учёта влияния на SEO для публичных страниц.

  5. 05

    Senior-команда без джунов плюс документация

    Та же senior-команда от аудита до production: основатель и стратегия, проектный лид, инженерный лид, дизайн-лид. Performance — это inherently senior работа: архитектурные решения, профилирование, анализ корневых причин. Джун может прочитать «оптимизируйте изображения» в гайде, но не может решить «ваше дерево состояния вызывает повторный рендер всего дерева на каждый символ в форме». После оптимизации остаётся документация: бюджет производительности (max bundle size, max LCP), правила для команды, чек-лист для код-ревью, опционально — CI-проверки (Lighthouse CI, лимит размера бандла).

06 · Что мы не делаем · Анти-паттерны

Чего у нас не бывает в performance-работе⁠.

Двенадцать решений, которые встречаются в performance-практике чаще, чем хотелось бы, и из-за которых «оптимизация» оборачивается косметикой без реального эффекта. У нас — нет.

  • «Накрутить Lighthouse ради скриншота» — Lighthouse полезен как один из инструментов, но лабораторные данные ≠ полевые данные. Реальные пользователи на mid-range мобильных получают другие числа
  • Мелкие оптимизации без архитектурного подхода — React.memo на всё подряд, useCallback везде, useMemo на простых вычислениях. Это добавленная сложность без эффекта (часто негативный эффект)
  • Замена библиотек на «более быстрые» без анализа — «выкиньте Redux, возьмите Zustand» без понимания, что Redux не был причиной проблемы
  • Оптимизация изображений без разделения кода — если бандл 1.5 МБ, оптимизация изображений даст +10–15% улучшения. Без архитектурной работы — это lipstick on a pig
  • Performance-работа без замеров — «сделаем быстрее» без чисел до и после — это маркетинг, а не инженерия
  • «Перепишем на новый стек» вместо оптимизации существующего — обычно существующее Next.js приложение можно ускорить в 3–5 раз без переписывания. Переписывание — крайний случай, не дефолт
  • Оптимизация SPA без миграции на SSR — если у вас CSR React-приложение и нужны SEO или performance, единственный серьёзный путь — миграция на SSR/SSG (Next.js)
  • Performance-театр («Lighthouse Score 100/100!») без реального влияния на конверсии и SEO
  • React.memo как ответ на все проблемы — часто это не помогает или вредит. Profile first, optimize second
  • Преждевременная оптимизация для нового продукта — для новых сборок сначала пишем ясный код, потом замеряем и оптимизируем только узкие места
  • Передача джунам после первого месяца — performance это inherently senior работа
  • «Чёрный ящик» — бюджет производительности, документация и правила у вас с первого дня
07 · Где мы на спектре · Самоопределение

Между самостоятельной оптимизацией
и корпорат-консалтингом⁠.

Самостоятельно с ChatGPT — для простых случаев (оптимизация изображений, базовые твики webpack). Если архитектурная проблема — не справится. Фриланс-React-разработчик — для отдельной задачи (одна страница, один компонент), не покрывает системный подход. Дешёвые студии обычно делают косметику без архитектурной работы. Под нами — оптимум для продакшен-проектов с реальными performance-проблемами. Корпоративный консалтинг (Cetera, DevOps-консалтинговые) — для крупных корпоратов со сложной инфраструктурой, часто избыточно для SaaS и B2B-сайтов.

 
 
Самостоятельно
DIY + ChatGPT
Дешёвая студия
Косметика
H-Studio
Архитектурный подход
Корпорат-консалтинг
Cetera · DevOps-консалтинговые
Цена
0 ₽ + время
часть редизайна
100 тыс. – 2 млн ₽
2–10 млн ₽+
Срок
Недели
Часть проекта
1–10 недель
2–6 месяцев
Подход
Lighthouse
Косметика
Архитектура
Комплексный enterprise
Замеры
Lighthouse
Lighthouse
Лабораторные + полевые
Лабораторные + полевые + RUM
Архитектурная работа
Маловероятно
Не делается
По умолчанию
По умолчанию
Знание React 2026
Частичное
Часто 2022 (Pages Router)
Актуальное
Актуальное
Документация
Нет
Минимум
Полная (правила + CI)
Полная
Постоянный мониторинг
Нет
Нет
От 50 тыс. ₽/мес
Часть договора

Самоопределение · выберите свой формат

08 · Кейсы performance-инжинирингаОткрыть полный архив→

Четыре проекта с правильным балансом серверных и клиентских компонентов⁠.

Каждый проект — реальное приложение в продакшене с измеримыми Core Web Vitals. Тариф и архитектурные акценты — внутри карточки.

Тариф · Архитектурный рефакторинг · Гонконг

My Office Asia — server-first архитектура

PropTech-маркетплейс. 400+ компонентов, из них только 83 клиентских (остальные — серверные). Статическая генерация 71 публичной страницы, edge-кэширование, fluid-вёрстка. Рейтинг Core Web Vitals «Good» на всех публичных страницах. Стек: Next.js App Router, TypeScript, Supabase.

Открыть кейс→
Тариф · Стандартная оптимизация

Forschungsmittel.com

B2B-платформа для грантового консалтинга. Смешанный рендеринг: SSG для публичных страниц, SSR для авторизованной панели, потоковая передача для тяжёлых операций. Быстрая первая загрузка + отзывчивый авторизованный опыт. Стек: Next.js, TypeScript, Neon/PostgreSQL.

Открыть кейс→
Тариф · Стандартная оптимизация

Benjamin C. Wenzel

Цифровая платформа адвокатской практики. Публичный слой авторитета на статической генерации + авторизованный кабинет клиента с правильной стратегией гидрации. Работа с чувствительными данными без компромиссов в скорости. Стек: Next.js, TypeScript, Neon, Prisma.

Открыть кейс→
Тариф · Архитектурный рефакторинг · SaaS

Web Page Generator

SaaS-платформа для динамических QR-страниц. Публичный слой рендеринга обслуживается со стабильных URL для постоянно быстрой загрузки. Edge-кэширование с миллисекундной задержкой. Стек: Next.js, TypeScript, Supabase.

Открыть кейс→
FAQ · Четырнадцать вопросов про performance

  1. Нет. Lighthouse — это лабораторные данные, замер в контролируемом окружении с throttled-соединением. Реальные пользователи на разных устройствах получают другие числа. Мы оптимизируем под полевые данные — то, что измеряет Google в Search Console через CrUX (Chrome User Experience Report). Это данные от реальных пользователей, которые влияют на SEO-ранжирование. Lab Score 100/100 + Field «Poor» rating = ничего не сделали. Lab 75/100 + Field «Good» rating = реальная победа.

Дальше · Поехали

Замеряем скорость,
находим причину и правим архитектуру⁠.

Соберём понятный план: какие страницы и сценарии анализируем первыми, что критично для пользователей, что блокирует SEO, какие правки дадут быстрый эффект — performance-аудит, точечная оптимизация или системная работа с архитектурой фронтенда. Архитектурный созвон — 30 минут, без обязательств.

30-минутный архитектурный созвонОценить проект
Студия
H-Studio
Senior-поставка · Москва · Россия
Контакт
+7 (982) 666-66-80
Офис
ул. Октябрьская д. 80 стр. 6
117593 Москва