Редакция Romanov Lab · Опубликовано
Проверка медленной сети нужна не только для оценки секунд до первого экрана. Она обнаруживает гонки запросов, исчезновение введённых данных, преждевременные сообщения об успехе и бесконечные индикаторы. Сайт может быстро показать оболочку и при этом не позволить выбрать товар. Поэтому тест строят вокруг задачи посетителя и наблюдаемых состояний.
Опишите условия так, чтобы тест можно было повторить
Запишите браузер, устройство, сборку, URL, состояние входа и кэша. У сетевого профиля важны скорость загрузки, скорость отправки и задержка. Отдельно фиксируйте ограничение CPU: медленная сеть и слабый процессор вызывают разные симптомы. Эмуляция в DevTools полезна для повторяемости, но не воспроизводит все особенности радиосети и настоящего устройства.
Network в Chrome DevTools позволяет ограничивать сеть, отключать кэш и исследовать запросы. Уточняйте, к какому прогону относится запись: первый визит, повторное открытие или переход внутри уже загруженного приложения. Если используется service worker, проверьте и его кэш, иначе отметка «без кэша» в протоколе окажется неточной.
Учебный сценарий: выбор услуги и отправка заявки
Представим форму, где список услуг приходит из API. В первом прогоне задерживаем этот ответ. Ожидаем, что название раздела и инструкция уже читаются, а пустой список не выглядит как отсутствие услуг. Во втором прогоне запрос завершается ошибкой: появляется возможность повторить загрузку. В третьем посетитель меняет город до получения предыдущего ответа. Старый список не должен перезаписать услуги нового города.
Для каждого шага фиксируем ожидаемый исход: «выбранный город сохранён», «устаревший ответ проигнорирован», «повтор доступен». Формулировка «форма не тормозит» непроверяема. Задержку в тесте выбирают как условие эксперимента, а не выдают за типичный опыт всех посетителей.
Разведите задержку, ошибку и неизвестный результат
Долгий запрос ещё не является отказом. HTTP-ошибка означает, что ответ получен, но операция не завершилась ожидаемым способом. Разрыв связи после отправки создаёт более сложное состояние: сервер мог принять данные, а браузер не получил подтверждение. Нельзя в каждом случае очищать форму или уверенно сообщать «ничего не отправлено».
AbortController позволяет прервать связанный fetch на стороне клиента. Это полезно для устаревшей выдачи или закрытого экрана. Однако прерывание ожидания не является подтверждением отмены серверной операции. В тесте отправки заявки отдельно проверяйте неизвестный результат и безопасный повтор; подробная защита относится к приёмному API, а не к настройке сети.
Сеть «есть» не означает, что сервис доступен
navigator.onLine даёт ненадёжный для бизнес-решений сигнал о соединении: доступ к локальной сети не гарантирует доступ к конкретному серверу. Используйте его как подсказку, а не единственное условие блокировки формы. Решающее наблюдение — исход нужного запроса и состояние операции.
Проверьте несколько отказов по отдельности: основной API, шрифтовый домен, аналитика, карта и изображение. Если блокировка аналитики ломает отправку формы, выявлена архитектурная зависимость, а не просто «плохой интернет». Бизнес-действие не должно ожидать успешного ответа необязательного измерительного сервиса.
Что смотреть в записи
- Очередность запросов: не зависит ли начало главной операции от необязательного виджета.
- Состояние текста и кнопок до получения данных: пользователь понимает, что уже доступно.
- Сохранность введённого после ошибки, ухода назад и повторной попытки.
- Конкурирующие запросы: ответ для старого фильтра не заменяет новый результат.
- Переход между вкладками и возврат: таймеры и сообщения не создают ложного успеха.
- Отмена и повтор: нет бесконечного цикла, скрытой повторной отправки и дублирования действий.
При сохранении HAR или видеозаписи проверьте наличие токенов, персональных данных и введённого содержимого. Для воспроизводимого отчёта лучше использовать тестовую учётную запись и синтетические данные. Передача полной трассы внешнему подрядчику не должна происходить автоматически.
Как оформить дефект и закончить проверку
Хорошая карточка дефекта содержит условия, точные шаги, фактический результат, ожидаемое состояние и доказательство. Например: «При смене города с A на B ответ A приходит последним и заменяет список B». Разработчику нужны порядок ответов и идентификаторы запросов, а не только скриншот неправильного списка.
После исправления повторите исходный сценарий, обратный порядок ответов и обычную сеть. Отложенная загрузка или новая блокировка может исправить медленный профиль, но ухудшить обычное взаимодействие. Готовность означает, что выбранные пользовательские задачи сохраняют понятный результат во всём согласованном наборе условий. Общий мониторинг производительности дополняет этот сценарный тест, но не заменяет его.
Официальные источники
Нужен план для вашего проекта? Напишите нам в Telegram или по электронной почте. Обсудим разработку, продвижение или поддержку сайта.
