Сайт тормозит только у части посетителей: что сравнить

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

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

Попросите описать действие, а не оценить весь сайт

Фраза «всё тормозит» может означать долгое открытие страницы, появление картинки, реакцию поля или ожидание ответа формы. У этих случаев разные точки наблюдения. Попросите указать полный адрес, действие перед задержкой и то, что должно было появиться. Если проблема возникает после входа, отметьте этот факт без просьбы сообщить пароль или передать действующую сессию.

Запишите приблизительное время случая и его повторяемость. «Сегодня около 15:20 при открытии каталога» полезнее общего «последнюю неделю». Уточните, наблюдается ли проблема на всех страницах либо на одной операции. Не превращайте опрос в длинную техническую анкету: сначала достаточно одного конкретного сценария, который человек готов повторить безопасным способом.

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

Соберите небольшой набор контролируемых сравнений

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

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

Не сравнивайте первый заход с уже открывавшейся страницей

Успешный повтор может использовать ранее полученные ресурсы. В Chrome DevTools предусмотрено отключение браузерного кеша для проверки поведения первого посещения. Запишите, применялся ли такой режим, и не смешивайте его результаты с обычным повторным открытием без отметки. Сам факт существования двух разных условий не делает одно из них неправильным: они отвечают на разные вопросы.

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

Не очищайте клиенту все данные браузера как обязательный первый шаг. Такое действие может изменить состояние и убрать полезные признаки, а также повлиять на его работу. Начните с контролируемой проверки на своём окружении и безопасного сбора наблюдений. Изменения пользовательского устройства следует отдельно объяснить и согласовать, а не прятать в общей просьбе «попробуйте ещё раз».

Найдите конкретный участок ожидания

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

Resource Timing позволяет получать сведения об этапах загрузки ресурсов. При этом, как поясняет MDN, часть показателей для запросов к другому источнику ограничена без соответствующего Timing-Allow-Origin. Поэтому нулевое значение отдельного поля нельзя автоматически читать как отсутствие ожидания. Сначала установите, доступно ли это измерение в выбранном способе сбора. Пробел в данных не является доказательством быстрой загрузки.

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

Как собрать запись и не передать лишнего

В Chrome DevTools есть экспорт HAR с удалением некоторых чувствительных заголовков, включая Cookie, Set-Cookie и Authorization. Это полезная возможность, но не основание считать любой полученный файл безопасным для открытой публикации. Адреса, параметры и содержимое запросов требуют проверки по конкретному сценарию. Предпочитайте учебную сессию, в которой изначально нет настоящих клиентских сведений.

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

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

Проверьте одну гипотезу на одинаковых условиях

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

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

Если гипотеза не подтвердилась, зафиксируйте это. Отрицательный результат сужает поиск и защищает от повторения той же работы. Не объявляйте общую причину «плохой интернет» или «слабый телефон», пока данные показывают лишь отличие двух запусков. Дальнейший шаг выбирают по оставшейся неопределённости: иногда нужен другой набор наблюдений, а не ещё одна настройка сервера.

Что считать решённым обращением

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

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