Одна жалоба может означать разные задержки
«Сайт тормозит» — не технический диагноз. У одного посетителя долго отвечает сервер, у другого сразу появляется пустой экран, у третьего всё видно, но кнопка не реагирует. Перед обращением к ИИ воспроизведите конкретный сценарий: URL, устройство, браузер, скорость сети, состояние кэша и время наблюдения. Запишите, что именно пользователь ждёт: первый текст, главный блок, интерактивную карточку или ответ после нажатия. Если страница работает нормально на локальной машине и медленно через VPN, это тоже часть гипотезы, а не доказательство ошибки фронтенда. Модель без этих данных обычно выдаёт общий список оптимизаций.
Соберите базовую трассу
Откройте инструменты разработчика и сохраните сетевой журнал и профиль производительности. Для проверки повторите загрузку три раза в одинаковых условиях. Измерьте время ответа HTML, размер CSS и JavaScript, время получения главной картинки, количество запросов и момент появления нужного блока. Не смешивайте прогретый кэш и первый визит в одной таблице. Если на сервере есть логи, сверьте время запроса с тем, что видит браузер. Задержка перед первым байтом и задержка после получения HTML требуют разных исправлений. Не отправляйте модели журнал с токенами, cookie и персональными URL-параметрами.
Дайте ИИ ровно те данные, которые нужны
После очистки трассы сформулируйте задачу: «Список карточек появляется через четыре секунды; HTML пришёл за 180 мс, изображения занимают 8 МБ, один запрос каталога длится 2,7 секунды. Назови три проверяемые гипотезы и данные, которые отличат их друг от друга». Такой запрос ограничивает простор для фантазии. Не просите сразу «ускорить всё». Для каждой гипотезы модель должна указать наблюдение в логе и возможный тест. Если объяснение ссылается на несуществующую библиотеку или функцию, откройте исходный код и уберите его из плана.
Разделите сеть, вычисление и ожидание данных
Медленная картинка решается не тем же способом, что блокирующий скрипт. Если сеть долго скачивает изображение, проверьте размеры, формат, кэширование и то, не загружается ли оригинал вместо нужного разрешения. Если JavaScript удерживает главный поток, смотрите длительные задачи и объём исполняемого кода. Если блок появляется только после API-ответа, измерьте маршрут запроса и подумайте, может ли пользователь увидеть полезную часть страницы раньше. Серверная задержка требует проверки приложения и базы. Не соглашайтесь на предложение отключить функции или удалить содержимое ради красивой цифры в тесте.
Пример с каталогом
Представим, что шапка видна почти сразу, а карточки приходят поздно. Трасса показывает быстрый HTML и шесть больших картинок, но API-ответ каталога задерживается на несколько секунд. Первой гипотезой становится запрос данных, а не шрифт. Повторите API-вызов отдельно и посмотрите серверное время. Если он быстрый, проверьте, не ждёт ли клиент лишней загрузки перед отрисовкой. Если медленный, исследуйте выборку, индекс и объём ответа. ИИ поможет прочесть план запроса или последовательность обещаний, но изменение делайте только после воспроизведения. Следующая ошибка часто в том, что ускоряют локальный стенд, а проблема живёт в боевой базе.
Меняйте по одной причине
Создайте небольшую ветку и исправьте одну подтверждённую узкую часть. После изменения запустите сборку, функциональные тесты и тот же профиль загрузки. Сравните медиану нескольких запусков, а не лучший случай. Проверьте медленную сеть и мобильный экран: оптимизация на мощном компьютере может не помочь пользователю телефона. Смотрите размер переданных файлов и число дополнительных запросов. Если скорость улучшилась, но карточки показывают старые данные или сломался поиск, результат нельзя принимать. В <a href="/material/kod-revyu-zavisimosti">разборе новой зависимости</a> объяснено, почему пакет ради одной оптимизации нужно проверять отдельно.
Следите за кешем и версиями
Кэш способен скрыть проблему при повторном визите и создать её после релиза, если браузер получает старый HTML с новым набором скриптов. Проверьте заголовки ответа и имена файлов после сборки. Не очищайте весь кэш пользователей как первый способ ремонта: определите, какой ресурс должен обновляться и как приложение обрабатывает несовпадение версий. Если сайт статический, удостоверьтесь, что новые файлы действительно находятся в docroot и сервер не отдаёт прежнюю сборку. Локальный успешный билд ничего не говорит о реальном URL, пока не проверен HTTP-ответ и содержимое опубликованной страницы.
Вывод и FAQ
ИИ полезен как помощник в чтении трассы и выборе следующего измерения. Он не знает причину задержки без данных, а случайный рефакторинг может сделать ситуацию хуже. **Какой замер важнее?** Тот, который соответствует жалобе пользователя, а не просто красивой оценке. **Нужны ли три прогона?** Повтор уменьшает влияние случайной сетевой задержки. **Можно ли слать HAR-файл целиком?** Сначала удалите секреты и персональные сведения. **Когда правка готова?** После повторного замера и проверки функции. Для отладки конкретного сбоя отдельно посмотрите <a href="/material/kod-otladka-importa">приём минимального воспроизведения</a>.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.