Профиль мобильной сети
На localhost ресурсы малы и получают короткий путь доставки. Поэтому полезный механизм может почти не менять видимый результат. Чтобы исследовать другие ограничения, нужен профиль сети и устройства. В этом уроке научимся разделять ожидание обмена, передачу байтов и работу процессора, сохраняя один сценарий страницы.
Используем уже подготовленный advanced/resource-lab и пустую форму manual-matrix.md. Автор не выполнял сетевую эмуляцию и не измерял ProfessorWeb. Все числовые условия ниже придуманы для объяснения. Результат урока — матрица, по которой читатель сможет провести своё ручное сравнение и назвать границы полученного вывода.
Мобильность состоит из разных условий
Узкое окно меняет композицию, но не превращает процессор компьютера в телефон. Низкая пропускная способность ограничивает передачу, но не обязательно означает большую задержку первого ответа. Медленный CPU влияет на выполнение и подготовку кадра, хотя Network может показывать завершённые файлы. Эти параметры нужно задавать и читать раздельно.
Представим маленький скрипт, который обнаруживается через несколько зависимых файлов. Если обмены начинаются последовательно, цена ожидания может быть существеннее размера последнего файла. В другой ситуации большой растр обнаруживается сразу, но долго передаётся. Уменьшение байтов и сокращение зависимой цепочки обращаются к разным ограничениям.
Для карты условий отдельно запишите viewport, DPR, профиль CPU, задержку и скорость передачи. Добавьте способ навигации и состояние кеша. Название «мобильный» без этих сведений слишком неопределённо. Через неделю другой разработчик не сможет восстановить смысл результата, если в протоколе осталось только имя предустановки.
Размер и пропускная способность
Рассмотрим выдуманный ресурс размером 120 КиБ и учебный канал 1 Мбит/с. В упрощённой модели передачи получаем около 0,98 секунды: байты переводятся в биты и делятся на скорость. Это арифметическое условие, не замер файла нашего стенда. Реальная доставка включает другие расходы и может отличаться.
Обратите внимание на единицы. КиБ содержит 1024 байта, а мегабиты в таком обозначении скорости считаются миллионами битов. Смешивание байтов и битов создаёт большую ошибку до всякого исследования. В таблице должны быть явно названы переданный размер и единица скорости, иначе расчёт выглядит убедительно, но отвечает на другой вопрос.
Уменьшение файла меняет только часть цепочки. Если основное ожидание находится до первого байта или после готовности ресурса, пропорционального изменения всего результата не будет. Для этого мы ранее разделяли фазы сетевого водопада и пути отображения. Профиль помогает проявить ограничение, а не отменяет эту модель.
Задержка не равна времени каждого запроса
В учебной схеме можно показать зависимые обращения и задержку между ними. Но нельзя автоматически умножать число всех запросов на одну величину RTT. Соединения переиспользуются, запросы перекрываются, а протокол и путь доставки меняют картину. Нужна фактическая последовательность начала и завершения, а не только счётчик файлов.
Именно поэтому preload прошлого урока исследовался по обнаружению. В условии с заметной задержкой зависимая цепочка может проявиться сильнее, чем на localhost. Но если ресурсы уже обнаружены вовремя, новая подсказка не устранит ожидание ответа сервера. Выберите гипотезу по фазе, которую показывает ваша запись.
Сохраните несколько повторов одного условия. Канал, устройство и браузер могут иметь изменяющуюся нагрузку, а один результат легко окажется необычным. Сначала исследуйте повторяемость цепочки и её разброс, затем делайте вывод. Не выбирайте лучшую попытку одной версии и обычную другой как доказательство ускорения.
Матрица вместо одной предустановки
Начните с двух самостоятельных осей: небольшая или большая задержка, высокая или низкая пропускная способность. Названия категорий замените своими явными учебными параметрами. CPU на этом этапе оставьте одинаковым. Так появятся четыре условия, которые помогают различить обнаружение ресурса и цену передачи.
| Условие ручной матрицы | Что помогает исследовать |
|---|---|
| Небольшая задержка, быстрый канал | Путь обнаружения и работа после получения |
| Большая задержка, быстрый канал | Зависимые обращения и начало ответа |
| Небольшая задержка, медленный канал | Переданный объём и конкуренция ресурсов |
| Большая задержка, медленный канал | Сочетание цепочки и передачи |
Таблица не утверждает, что настоящие сети делятся только на четыре класса. Она задаёт ограниченный эксперимент. Внутри каждой строки сравните одинаковые версии страницы и один способ перехода. Не меняйте одновременно кеш и загрузку виджета: эти действия добавят другие различия к сетевой гипотезе.
В Chrome Network можно выбирать предустановки и создавать собственные профили. Запишите фактические параметры и состояние инструмента перед серией. Интерфейс и его возможности описаны в документации Network throttling. Названия предустановок могут меняться, поэтому параметры полезнее запоминания одной кнопки.
Добавим CPU отдельным шагом
После сетевой матрицы выберите одно условие и исследуйте CPU. Например, действие кнопки виджета создаёт много строк. При завершённой доставке разница может проявляться в исполнении и размещении. Тогда исправление сети не является полным ответом на медленный пользовательский результат.
Замедление CPU в DevTools относится к возможностям текущего компьютера. Оно не воспроизводит точно архитектуру, память, нагрев и поведение выбранного телефона. Такое ограничение указано в документации Chrome Performance. Полученный эксперимент нужно называть эмуляцией определённого условия, а не измерением всех мобильных посетителей.
Проверка настоящего устройства дополняет матрицу. Сохраняйте браузер, состояние питания и сценарий, чтобы наблюдение было объяснимым. Узкий viewport на мощном компьютере остаётся полезным для композиции, но не заменяет эту проверку. Не переносите вывод о времени обработки автоматически только потому, что интерфейс визуально похож.
Что сообщает Network Information
При наличии поддержки можно посмотреть ориентировочную категорию соединения:
console.table({
effectiveType: navigator.connection?.effectiveType ?? "unknown",
downlink: navigator.connection?.downlink ?? null,
rtt: navigator.connection?.rtt ?? null
});Эти сведения являются оценками API и доступны не во всех распространённых браузерах. effectiveType относится к характеристикам соединения, а не гарантированному названию радиотехнологии. Назначение и ограниченная доступность описаны в MDN: NetworkInformation и effectiveType.
Не отключайте обязательное содержимое только из-за одной такой категории. Она может отсутствовать или меняться, а задача читателя остаётся. Для наших примеров сведения не отправляются и не определяют загрузку автоматически. Они показывают ещё один источник контекста, который нельзя выдавать за точное измерение каждого запроса.
Завершите урок матрицей с отдельно названными сетью, CPU, навигацией и кешем. Для каждого условия сохраните задержанную фазу и функциональный результат. Если больше всего стоит передача текста, следующим направлением может стать HTTP-сжатие. Его полезность тоже нужно проверить по фактически доставленному представлению, а не по расширению файла на диске.