← Назад в блог

Переписать на Next.js? Сначала найдите, что именно болит

Rewrite звучит приятно, когда legacy уже всем надоел.

Но в e-commerce это почти никогда не техническое желание в чистом виде. Обычно за фразой "давайте перепишем на Next.js" прячется что-то конкретное:

  • каталог медленно открывается;
  • поиск не находит то, что люди реально вводят;
  • маркетинг не может быстро выпускать посадочные страницы;
  • интеграция с 1C или CRM ломает релизы;
  • разработчики боятся трогать старый Bitrix/PHP-код;
  • никто не понимает, где заканчивается CMS и начинается бизнес-логика.

Если начать с технологии, можно красиво промахнуться.

Я видел проекты, где Next.js действительно был правильным следующим шагом. И видел проекты, где 80% боли снимались без большого переписывания: профилированием, нормальной схемой кеша, поисковым индексом, API-адаптером или выносом одного участка в headless.

Разница не в модности стека. Разница в диагностике.

Что я проверяю до разговора про rewrite

Первый вопрос не "на чем переписывать?". Первый вопрос - "какой риск или бизнес-метрика сейчас неуправляемы?".

Обычно я смотрю на пять слоев.

  1. Трафик и скорость. Где реально тормозит: TTFB, LCP, SQL, API, CDN, шаблоны, тяжелые компоненты, сторонние скрипты.
  2. Каталог и поиск. Сколько SKU, какие фильтры, какие zero-result запросы, есть ли фасеты, как строится relevance.
  3. Контент и релизы. Кто меняет страницы, сколько времени занимает правка, где ломается CI/CD или ручной deploy.
  4. Интеграции. 1C, CRM, платежи, доставка, остатки, цены, личный кабинет, статусы заказов.
  5. Границы ответственности. Что можно вынести безопасно, а что пока должно остаться в монолите, потому что оно приносит деньги каждый день.

После этого rewrite часто превращается в более трезвую карту:

  • оставить рабочее ядро;
  • вынести публичный frontend;
  • закрыть catalog/search отдельным слоем;
  • добавить observability;
  • запускать staged rollout, а не "пятничный big bang".

Почему маленький pilot полезнее большого обещания

Большой rewrite до discovery плохо защищает обе стороны.

Клиент не понимает, за что платит и где закончится scope. Команда делает оценку по догадкам. Потом всплывают роли, статусы, старые акции, кривые свойства товаров, 1C-обмен, SEO-редиректы, кабинет юрлиц, ручные исключения в доставке.

Выглядит как "разработчики опять не попали в срок".

На практике это часто означает, что никто не описал систему до старта.

Мне больше нравится формат маленького work slice:

  • берем один реальный проблемный участок;
  • фиксируем текущие цифры;
  • делаем компактный technical audit;
  • отделяем базовое от optional;
  • показываем prototype или phased roadmap;
  • считаем следующий шаг уже не по ощущениям, а по фактам.

Это не отменяет большой проект. Просто большой проект становится менее слепым.

Где Next.js действительно помогает

Next.js хорошо ложится на legacy Bitrix/PHP, когда надо отделить скорость изменений на frontend от старой CMS.

Например:

  • маркетингу нужны быстрые страницы без постоянных правок PHP-шаблонов;
  • каталог можно отдавать через API и кешировать на frontend/CDN;
  • SEO-страницы нужно выпускать регулярно и контролируемо;
  • поиск и фасеты проще считать отдельным сервисом;
  • есть риск, что полный rewrite остановит продажи на месяцы.

Это и есть нормальный смысл headless: не "выкинуть legacy", а поставить между бизнесом и legacy управляемую границу.

Я подробнее писал про такие границы в статье про TypeScript API contracts между Next.js и Bitrix REST. Близкая тема по scope - разбор что оставлять в Bitrix, а что выносить в headless.

Мой простой фильтр

Если команда говорит "надо переписать все", я спрашиваю:

  • какой участок приносит деньги прямо сейчас;
  • где самая дорогая задержка;
  • что можно измерить за 2-3 дня;
  • что можно вынести без остановки продаж;
  • какой rollback будет, если гипотеза не сработает.

Ответы на эти вопросы обычно полезнее презентации на 40 слайдов.

Sometimes the best modernization plan is boring.

Оставить то, что работает. Измерить то, что болит. Вынести только то, что дает скорость, контроль или снижение риска.

Если вы смотрите на legacy Bitrix/Laravel проект и слово "rewrite" уже прозвучало - сначала посчитайте. Для таких случаев у WGP есть формат Catalog Probe: небольшой срез по реальному каталогу, поиску, API и рискам перед большим решением.