Исследование фудтеха: React, Битрикс и готовые решения в доставке еды

React или Vue для сайта доставки

Оба фреймворка решают одну задачу: быстрый интерфейс, где меню, корзина и оформление заказа работают без перезагрузки страницы. Разница — в экосистеме и в том, кого проще нанять.

Для доставки важен SEO-трафик по запросам вроде «пицца с доставкой» в своём городе. Поэтому React обычно используют вместе с Next.js, а Vue — с Nuxt: оба фреймворка отдают поисковику готовый HTML.

Сам выбор фреймворка редко решает судьбу проекта. Важнее, кто будет его поддерживать через три года. Если в городе проще найти React-разработчика, это аргумент сильнее любого сравнения производительности.

Почему лидеры чаще выбирают React

Моё объяснение — мобильное приложение. У крупной доставки приложение часто приносит больше заказов, чем сайт. React Native позволяет одной команде вести и сайт, и приложение, переиспользуя логику корзины и авторизации.

Готовые решения: когда хватает коробки

Ниже в рейтинге мы видели WordPress, Joomla и готовые решения. Это не ошибка владельцев. Одной пиццерии на 20 заказов в день не нужен самописный бэкенд за несколько миллионов.

Коробка закрывает базовые потребности: меню, корзина, оплата, форма заказа. 1С-Битрикс даёт больше: модули из Маркетплейса, интеграции с кассами, развитую админку. У лидеров он встречался на 12% сайтов.

У коробки есть и скрытая цена. Каждый плагин обновляется отдельно, и через пару лет сайт превращается в набор модулей, которые нельзя обновить без риска что-то сломать. Мы видели это в исследовании: чем ниже сайт в рейтинге, тем чаще он собран из старых плагинов.

• одна-три точки и одна зона доставки;
• меню меняется редко;
• основной поток заказов идёт из агрегаторов;
• нет планов на своё мобильное приложение.

Своя доставка еды: когда нужна разработка

Свой код окупается, когда процессы перестают помещаться в шаблон. Например, у сети 30 точек с разными меню и стоп-листами, зоны доставки пересекаются, а лояльность должна работать одинаково на сайте, в приложении и в зале.

Ещё один повод — скорость. Коробочный сайт с десятком плагинов на WordPress часто грузится 4–6 секунд на мобильном интернете, и часть клиентов уходит до корзины.

Скорость сайта и мобильный трафик

Еду заказывают с телефона, часто на ходу. Поэтому скорость мобильной версии влияет на выручку напрямую. Google считает хорошим показателем LCP до 2,5 секунды — за это время должен появиться главный блок страницы.

Готовые темы на WordPress и Joomla тащат лишние скрипты, слайдеры и шрифты. Самописный фронтенд на React или Vue с серверным рендерингом проще держать лёгким. Но и он может тормозить, если на главную вывалить всё меню с фотографиями.

• сжимать фото блюд в WebP или AVIF;
• подгружать меню частями;
• кешировать каталог на CDN;
• убрать с первого экрана тяжёлые слайдеры.

Что живёт в бэкенде доставки

Самописный бэкенд у лидеров — это не прихоть. В нём собирается логика, которую сложно повторить готовыми плагинами.

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

• меню с модификаторами и стоп-листами из кассовой системы;
• зоны доставки на карте с разной минимальной суммой;
• расчёт времени доставки с учётом загрузки кухни;
• промокоды, бонусы и персональные предложения;
• интеграция с iiko или r_keeper;
• приложение для курьеров и трекинг заказа.

Как выбрать стек для доставки

Я бы шёл от бизнеса, а не от технологий. Сначала ответить на вопросы, потом выбирать фреймворк.

Ответы на эти вопросы часто сами подсказывают решение. Одна точка без приложения — коробка или Битрикс. Сеть с приложением и своей кассой — React с Next.js и самописный бэкенд. Между ними — Битрикс с доработками.

• Сколько точек и городов будет через два года?
• Нужно ли мобильное приложение?
• Какая кассовая система стоит в ресторанах?
• Кто будет поддерживать сайт: штатная команда или подрядчик?
• Какую долю заказов вы хотите забрать у агрегаторов?

Типичные ошибки при выборе

Самая дорогая — сразу заказывать сложную систему без проверенного спроса. Обратная ошибка — годами латать коробку плагинами, когда бизнес уже вырос. Переезд в этом случае обходится дороже, чем своевременная разработка.

Сайт или мобильное приложение

Многие стартуют с приложения, потому что так делают лидеры. Это дорого: две платформы, публикация в App Store, Google Play и RuStore, отдельные релизы.

Моя позиция — сначала сайт, который хорошо работает на телефоне. Приложение имеет смысл, когда есть постоянная аудитория, которая заказывает каждую неделю, и программа лояльности, ради которой его стоит установить.

Когда переходить с коробки на свою разработку

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