Сайт медленный и теряет заявки: что проверить до редизайна

На сайте уже кто-то ждёт. Форма висит недозаполненной. Поиск крутится. Менеджер запускает выгрузку и уходит в другое окно. В том же месяце заявок меньше, и в почте лежит предложение: новая вёрстка, новые страницы, может быть, новая платформа. Деньги в этом предложении уходят на то, что видно. А тормозит чаще всего одно: запрос к базе, слишком большой ответ или колонка без индекса. Заявка теряется не из-за старого шрифта. Она теряется, когда шаг, который её создаёт, так и не заканчивается.

Сначала назовите экран и засеките, сколько длится действие. Только потом решайте, менять ли страницу. Медленная страница и тихий ящик заявок могут совпасть по времени. Это ещё не значит, что одно из другого следует. Цифры ниже — про одну операцию на одном продукте. Для вашего сайта это не прогноз.

1. Назовите то, чего люди уже ждут

На совещании это звучит одной фразой: сайт медленный, заявки теряем. С такой фразой нечего делать. Нельзя починить ожидание, которое никто не назвал. И нельзя списать заявки на страницу, которую никто не засекал.

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

До макетов запишите вот это:

• Точный экран и кто ждёт: посетитель, менеджер или партнёр.
• Один замер до любых правок. День, какое действие, сколько секунд.
• Две отдельные строки: «эта страница тормозит» и «хотим новый вид». Обе могут быть правдой. Задачи разные.
• Шаг, на котором заявка реально появляется: отправка формы, звонок, бронь. Засекайте его, а не страницу сверху.
• Когда заявок стало меньше: до тормозов, после, или этого никто не знает. Процент не выдумывайте.

Заметка должна быть узкой. На одной учебной платформе фраза «платформа медленная» ничего не объясняла. Цикл запросов к базе заменили одним агрегирующим запросом. Эта операция сократилась с 12,41 до 2,451 секунды, память упала на 1,5 ГБ. Другая критическая операция — с 23 937 мс до 48 мс. Один ответ API — с 912 КБ до 2,1 КБ. Средняя нагрузка CPU за неделю снизилась с 82,2% до 2,75%, когда разобрали узкие места, в том числе поиск без индексов. Каждая цифра про свою операцию. Ни одна не значит, что весь продукт стал быстрее в сколько-то раз. Ваша заметка выглядит так же: этот экран, это действие, столько секунд. Разговор о новом виде — после.

2. Обычно тормозит одна операция

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

Время сидит в знакомых местах. Запрос внутри цикла. Колонка поиска без индекса. Ответ, который отдаёт всю запись, хотя на экране нужны несколько полей. На той же учебной платформе сокращение с 912 КБ до 2,1 КБ касалось одного ответа API. Остальное экрану было не нужно. Новый дизайн этого экрана отдал бы тот же объём, если бы никто не спросил, что лежит в ответе.

Бывает и другое. Отчёт, выгрузка или вызов чужого сервиса держат вкладку, пока работа не кончится. Увести это в фон — не то же самое, что перерисовать страницу. Отдельный процесс на Node здесь не первый вопрос. Сначала назовите операцию. Где проходит граница, разобрано в заметке когда очередь на Node стоит рядом с Laravel.

Прежде чем согласиться с причиной, спросите:

• Медленный шаг — это запрос, тяжёлый ответ или ожидание внешнего сервиса? Медленный лог или человек, который ведёт сервер, обычно может начать ответ.
• Если одну и ту же таблицу читают по разу на строку экрана, запишите одной фразой: «запрос в цикле».
• Если тормозит поиск, спросите, есть ли индекс по этой колонке. Без индекса поиск часто и кажется сломанным.
• Если ответ большой, сравните его размер с тем, что реально видно на экране.

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

3. Что проверить до заказа редизайна

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

Сайт, который выглядит устаревшим, иногда как раз и принимает заказы. Сначала стоит увидеть, что реально работает, и стабилизировать это. «Старый, значит, меняем продукт» можно обсудить потом.

Перед подписью пройдитесь по списку:

• Замерьте шаг заявки и один внутренний шаг, на который уже жалуются. Выгрузку или отчёт. Оба числа сохраните.
• Запишите фреймворк, язык и базу. Вы проверяете, можно ли ещё чинить текущую систему, а не выбираете новый стек.
• Выясните, есть ли отдельная среда. Если правку можно пробовать только на живом сайте, редизайн и ускорение становятся одним рискованным релизом.
• Подтвердите, что резервная копия хотя бы раз восстанавливалась. Или восстановите её сами в этой отдельной среде.
• Если сайт передал другой разработчик, до дизайн-работы подтвердите доступ к репозиторию, какая ветка выкатана и есть ли письменная инструкция. Этот проход — чек-лист приёмки Laravel.

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

4. Чего редизайн не чинит

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

В объёме дизайна страницы, шрифт и компоненты. Медленный путь — доступ к данным. Если поиск клиента соединяет большие таблицы без индекса, новая строка поиска вызывает тот же путь. Если выгрузка собирает файл внутри запроса, новая кнопка ждёт так же. У тех, кто утвердил картинки, в брифе не было строки: этот поиск возвращается за время, которое мы замерили, или быстрее.

Зафиксируйте ограничение письменно:

• Замеренные операции кладите в бриф редизайна вместе с секундами.
• Старые числа сохраните. Честное сравнение — тот же экран, тот же тип данных, до и после.
• Если редизайн заодно меняет базу или хостинг, это второй проект со своей проверкой.
• Если клиенты живут в одном приложении, запишите, как данные одного аккаунта отделены от другого, до того как новые страницы покажут их больше.

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

5. Из заметок получается короткий план

Документ, который заканчивается фразой «рассмотреть редизайн» и никого не называет, планом не является. Разложите заметки. Сразу: шаг заявки, если он падает или упирается в таймаут, и восстановление из копии, которое вы ещё не проверили. Дальше: операция, которую замерили, и гипотеза — цикл, индекс, размер ответа или работа, которой место в очереди. Потом: визуальная правка, которую всё ещё стоит делать, когда ожидание уже понятно.

У списка должен быть ответственный:

• У каждой строки есть человек и проверка, по которой видно, что дело сделано: повторный замер, восстановленная копия, поиск по индексу.
• Договоритесь, какая визуальная работа может подождать, пока эти проверки есть.
• Редизайн не начинается, пока у шага заявки нет числа и гипотезы, почему так.

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

Когда звать специалиста

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

Такую диагностику я беру, и разработку после неё тоже, на той системе, которая у вас уже есть. Услуги — скорость, SaaS и backend, интеграции с ИИ. Проекты — те же ситуации: операция со своим замером и результат рядом с ней. Если хотите второй взгляд на экран, который вы засекли, напишите мне в LinkedIn. Пришлите адрес, действие и секунды.