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

Соберите цифру за четыре шага

1. Разбейте данные реальных пользователей по устройствам и типу соединения. Полевые данные, а не лабораторные баллы: ваш медианный мобильный пользователь — не ваш ноутбук.
2. Сгруппируйте сессии по времени загрузки и посмотрите конверсию в каждой группе. Кривая почти всегда крутая на отрезке от одной до четырёх секунд.
3. Оцените, сколько сессий поднимется на группу выше, если починить три главных узких места.
4. Умножьте на средний чек или стоимость лида. Это и есть ваша заявка на бюджет — со ссылкой на источник.

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

За какой метрикой идти первой

• Largest Contentful Paint обычно та, что связана с выручкой. Именно её пользователь переживает как «страница пришла».
• Interaction to Next Paint важнее в интерактивных приложениях и длинных формах — там тяжёлый JavaScript превращается в раздражение.
• Cumulative Layout Shift редко напрямую меняет конверсию, но порождает промахи по кнопкам и обращения в поддержку, а чинится дёшево.

Исправления, которые действительно двигают цифры

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

Нельзя оптимизацией кода выбраться из четырёхсот килобайт аналитических тегов. Сначала проверьте, что скачивает браузер, и только потом переписывайте то, что делает сервер.

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