Симуляция медленной сети для отдельных запросов
• devtools
Вступление
Уже долгое время в браузерных инструментах разработчика есть симуляция медленной сети (или вовсе оффлайна) для запросов. Оставим за скобками, насколько оно близко к реальной медленной сети, и поговорим о том, чего не хватало.
В случае проработки оптимальной загрузки страницы долгое время у нас не было возможности симулировать необходимый порядок запросов. Это особенно важно, если используется не один монолитный JS чанк с синхронной загрузкой, а большое количество зависящих друг от друга кусков кода вместе с <script async>.
В подобных случаях лучшее, что можно было придумать – прокси по типу Fiddler (если не изменяет память, там была возможность выставлять задержки на конкретный запрос). Но путь этот был очень нетривиальным и требующем дополнительного времени.
Именно для таких задач я вижу главный профит недавней новинки – возможности симуляции сети для каждого запроса в отдельности.
Симуляция медленной сети через инструменты разработчика
Начиная с Хрома 145, появилась возможность настраивать симуляцию сети для отдельных запросов:
Думаю, подробно рассказывать об интерфейсе нет никакого смысла – во-первых, он очевиден, а во-вторых, он вполне может измениться уже завтра и эта информация устареет.
Советы при разработке
Всегда проверяйте механизм асинхронной загрузки
Грузите код асинхронно? Проверьте разные варианты, что в каком порядке сработает.
Грузите асинхронно и JS, и CSS? Помните, что на момент выполнения JS стили могут не успеть загрузиться. Или, например, шрифты, и ваши вычисления размеров выйдут некорректными.
Есть картинка, которая влияет на лейаут? Проверьте, что будет, если она загрузится позже.
Ваш код рассчитывает на наличие DOM-элементов? Дождитесь их появления, из-за стриминга HTML и асинхронной загрузки может получиться так, что скрипты выполнятся до готовности документа. Этот сценарий не проверить новым инструментом.
Проверьте ответ с ошибкой
Помимо симуляции медленной сети, уже давно есть возможность полностью заблокировать запрос. Это позволяет протестировать состояние ошибки.
Что покажется пользователю? Будет ли ошибка обработана? Есть ли корректное логирование?
На все эти вопросы у вас должен быть ответ, всё это можно протестировать блокировкой запросов.
Сделайте пресет с большой задержкой сети
Помимо встроенных пресетов можно создать свои собственные, и тут могу порекомендовать пресет с большой скоростью и с большой задержкой. Обычно я использую задержку в 3 секунды, это позволяет решить большинство вопросов.
Зачем нужен такой пресет?
- Проверьте “водопад” из запросов на критическом пути загрузки вашей страницы, кто во что упирается
- Легко раздебажить, что грузится параллельно
- Можно поймать “середину” загрузки вашей страницы, когда загружена только часть ваших ресурсов (и не ловить нужный вам просвет в 50 мс между запросами)
Помимо прочего, можно сделать пресеты с определённой потерей пакетов, длиной очереди и симуляцией изменения порядка пакетов. Здорово, что такие настройки есть, но примеров применения (особенно двух последних) у меня нет.
Что до сих пор не решено
Оба инструмента (и симуляции медленной сети, и блокировки) не работают с ифреймами. Это неприятно – именно ифреймы с других доменов могут отваливаться, быть недоступны и так далее, поэтому хочется верить, что это доработают.
Также всё ещё не решён сценарий запросов, которые отличаются только дополнительными параметрами. Например, если есть механизм ретрая через перезапрос со случайным параметром, у вас не получится заблокировать первый запрос и не заблокировать второй – оба сматчатся на шаблонное правило.
Итого
Для меня инструмент появился ровно в тот момент, когда он был мне нужен. И это то, что ждали годами.
Какие ещё инструменты всё ещё ждут реализации? Напишите в комментариях.
Обсудить в Telegram
