Commerce performance — это не про «быстрее сайт», а про меньше потерь в оплате

Commerce performance — это не про «быстрее сайт», а про меньше потерь в оплате

Если трафик уже куплен, то прирост дают не мегабайты фронта сами по себе, а узкие места в цепочке: первый байт, рендер первого экрана, загрузка медиа, работа корзины и шаги checkout. Убирать надо то, что мешает пользователю дойти до оплаты без пауз и сюрпризов.

Проверьте 4 вещи:
— hero-блок и ключевой CTA появляются без тяжелых скриптов;
— изображения отдаются в нужном размере, а не «на всякий случай»;
— корзина не пересчитывается на каждый чих и не дергает API лишний раз;
— платежный шаг не грузит 10 сторонних тегов до момента, когда пользователь уже готов платить.

Если у вас headless, ускорение часто ломается не в React или GraphQL, а в лишней логике вокруг них: персонализация до первого клика, тяжелые виджеты, бесконечные аналитические пиксели. В D2C это особенно больно: каждая лишняя секунда на checkout бьет по ROAS сильнее, чем «красивый» стек.

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