Размер загружаемых на страницы ресурсов из года в год растёт, догоняя рост качества и скорости сети, а также производительности устройств. Лишние килобайты ресурсов точно не способствуют быстроте сайта.
Если цель — разработать сайт, который будет быстро загружаться у реальных пользователей, а не у разработчиков, менеджеров и тестировщиков с топовыми конфигурациями, стоит подумать о бюджетах производительности.
Алекс Рассел анализирует общее состояние производительности в вебе и предлагает бюджеты производительности. Они должны рассчитываться исходя из данных по конкретному проекту, но Алекс предлагает хорошую стартовую точку.
Тестовые устройства, которые отражают 75й перцентиль пользовательского опыта:
Смартфоны:
- Samsung Galaxy A24 4G
- Samsung Galaxy A16 4G
- Samsung Galaxy A07 4G
- Xiaomi Redmi Note 13 Pro 4G
- Samsung Galaxy A51
- Motorola Moto E15
Ноутбуки:
- HP 14 dq3500nr
- Или аналоги в пределах 250$, на процессоре Celeron, c модулем eMMC и работающий на WIndows.
(сравните их характеристики со своим рабочим сетапом)
Тестовые параметры сети:
- Входящая скорость 9 Мбит/с;
- Исходящая скорость 3 Мбит/с;
- Задержка (RTT) 100 мс.
Эти устройства и параметры сети — базовый уровень, на который стоит ориентироваться при анализе производительности. Бюджеты рассчитаны на загрузку страницы за 3 и 5 секунд. Это приемлемые показатели для данных условий.
Из-за разных подходов к разработке выделяются две категории сайтов для формирования бюджетов:
- Сайты с «лёгким JS», где JS составляет 15% от объёма всех ресурсов на критическом пути. Это традиционные MPA с точечным JS для прогрессивного улучшения или подходы с островной архитектурой;
- Сайты с «тяжёлым JS», где JS составляет 50% от объёма всех ресурсов на критическом пути. Это соответствует подходам SPA и SSR с гидратацией на стороне клиента.
Ресурсы критического пути — это те, которые необходимы для первоначальной отрисовки и функционирования страницы. Сюда не входят лениво-загружаемые и отложенные ресурсы. Бюджеты отражают именно ресурсы критического пути.
Разделение ресурсов на JS и всё остальное обусловлено тем, что JS — самый тяжёлый с точки зрения производительности ресурс. 500 кб JS не то же самое, что 500 кб изображения. «Остальное» включает в себя HTML, CSS, изображения и данные.
Теперь, когда все пояснения даны, собственно, сами бюджеты:
Загрузка за 3 секунды сайтов с «лёгким JS»:
- 0.3 мб JS
- 1.7 мб остальные ресурсы
- 2.0 мб всего ресурсов
Загрузка за 3 секунды сайтов с «тяжёлым JS»:
- 0.62 мб JS
- 0.62 мб остальные ресурсы
- 1.2 мб всего ресурсов
Загрузка за 5 секунд сайтов с «лёгким JS»:
- 0.57 мб JS
- 3.2 мб остальные ресурсы
- 3.7 мб всего ресурсов
Загрузка за 5 секунд сайтов с «тяжёлым JS»:
- 1.15 мб JS
- 1.15 мб остальные ресурсы
- 2.3 мб всего ресурсов
Как трактовать эти бюджеты? Если речь о сайте электронной коммерции (отрисовка HTML на сервере, точечный прогрессивный JS для интерактивности, категория «лёгкий JS»), то для загрузки за 3 секунды на целевом устройстве и сети нужно:
- чтобы HTML страницы, блокирующие стили и LCP-изображение в сумме составляли 1.7 мб;
- чтобы весь блокирующий JS (не
defer или async) в сумме составлял 0.3 мб.- чтобы общий вес этих ресурсов не превышал 2 мб.
Если речь о SPA, то для загрузки за 3 секунды нужно:
- чтобы начальный HTML, стили и LCP-изображение в сумме составляли 0.62 мб;
- чтобы весь JS приложения с данными в сумме составляли 0.62 мб.
- чтобы общий вес ресурсов не превышал 1.2 мб.
Это более чем реально, но требует определённой дисциплины в команде и контроля размера ресурсов и укладывания в бюджеты. С контролем помогут инструменты, а дисциплину и инженерную культуру нужно развивать.
#js #performance