Троттлинг и кэш в DevTools: проверка на медленной сети
На офисном интернете всё работает. На мобильном в метро — рассыпается. Разберём, как воспроизвести плохие условия за два клика и что там обычно находится.
Зачем это нужно
Разработчик пишет код на быстрой машине с быстрым интернетом, и всё отрабатывает мгновенно. Пользователь открывает продукт с телефона в дороге, где страница грузится восемь секунд. В этом промежутке живёт целый класс дефектов, который иначе не увидеть.
Хорошая новость: воспроизвести плохие условия можно за два клика, и никакого специального оборудования не нужно.
Троттлинг сети
DevTools → вкладка Network → выпадающий список No throttling. Готовые профили:
| Профиль | Что моделирует |
|---|---|
| Fast 3G | Мобильный интернет среднего качества |
| Slow 3G | Плохая связь: край зоны, метро, толпа |
| Offline | Полное отсутствие сети |
| Custom | Свои значения скорости и задержки |
Начинайте со Slow 3G — на нём вылезает больше всего. Offline проверяйте отдельно: это не то же самое, что медленно, там другое поведение.
Что находится на медленной сети
- Нет индикатора загрузки. Интерфейс просто замирает, и человек не понимает, нажалась ли кнопка.
- Двойные отправки. Не увидев реакции, пользователь нажимает ещё раз — и создаётся два заказа.
- Гонки данных. Экран отрисовался раньше, чем пришли данные: пустые блоки, нули вместо сумм, «undefined» в тексте.
- Необработанные таймауты. Запрос не дождался ответа, а интерфейс об этом молчит.
- Кнопка не блокируется на время отправки — то же, что и двойные отправки, но заметно только при задержке.
- Порядок ответов. Быстрый запрос обгоняет медленный, и на экране оказываются данные не того элемента.
Включите Slow 3G и нажмите кнопку отправки формы дважды подряд. Если создались две записи — это дефект уровня Critical, и на быстрой сети вы бы его не увидели: там окно между кликом и ответом слишком короткое, чтобы успеть нажать второй раз.
Режим офлайн
Отдельный сценарий, который проверяют реже, а он важен: продукт должен вести себя понятно, а не показывать белый экран или бесконечный индикатор.
- Включите Offline и обновите страницу: есть ли внятное сообщение.
- Включите Offline в середине заполнения формы и нажмите отправить: данные не должны потеряться.
- Верните сеть: продукт должен восстановиться сам или предложить повторить.
- Проверьте, что после восстановления не отправились дубли накопившихся запросов.
Троттлинг процессора
Менее известная возможность, а она нужна: у пользователя телефон вчетверо медленнее вашего ноутбука. Вкладка Performance → CPU → 4x или 6x slowdown.
Что там находится: тормоза при прокрутке длинных списков, задержка отклика на нажатия, анимации, которые дёргаются, тяжёлые вычисления, блокирующие интерфейс. На быстрой машине этого не видно вовсе.
Кэш: почему правки «не приезжают»
Классическая ситуация: разработчик выкатил исправление, у него всё работает, у вас — старое поведение. В большинстве случаев виноват кэш браузера.
Что с этим делать:
- Disable cache в Network — работает, пока DevTools открыт. Включите один раз и забудьте.
- Жёсткое обновление Ctrl+Shift+R (Cmd+Shift+R) — перезагрузка без кэша.
- Инкогнито — чистое состояние без кэша, куки и расширений.
- Application → Clear site data — полная очистка, если что-то залипло совсем.
Проверять всё исключительно с отключённым кэшем — тоже ошибка. Пользователь придёт с кэшем, и дефекты кэширования (старая версия скрипта рядом с новым стилем) вы так не увидите. Правило: разработку и разбор — с отключённым кэшем, финальную проверку — как у пользователя.
Что проверять по кэшированию
После выката новой версии пользователь должен получить её без ручной очистки кэша. Это обеспечивается тем, что файлы получают новые имена при сборке, а HTML-страницы не кэшируются надолго.
Практическая проверка: откройте продукт, дождитесь выката новой версии, обновите страницу обычным способом (не жёстким) — должна прийти новая. Если для этого нужен Ctrl+Shift+R, это дефект, и он затронет всех пользователей.
Ответы с личными данными кэшироваться не должны вовсе — заголовки Cache-Control у таких запросов стоит проверять отдельно. Где их смотреть — в разборе вкладки Network.
Насколько точно троттлинг моделирует реальную сеть?
Приблизительно: он задаёт скорость и задержку, но не воспроизводит потери пакетов и скачки качества. Для поиска дефектов интерфейса этого достаточно, для точных измерений — нет.
Обязательно ли проверять на Slow 3G?
Если у продукта есть мобильные пользователи — да, хотя бы основные сценарии. Это десять минут, а находит дефекты, которые иначе всплывут у реальных людей.
Почему на телефоне работает иначе, чем в эмуляции?
Эмуляция моделирует сеть и процессор, но не саму мобильную платформу. Финальную проверку всё равно делают на устройстве — см. тестирование мобильных приложений.