• на каждом фреймворке было сделано тестовое приложение, с 3 вариантами экранов
  • default - обычный экран с базовыми компонентами
  • burn (list) - экран с большим списком однотипных интерактивных элементов (500)
  • modals - экран с несколькими открытыми модалками
• VKUI по показателям +/- на одном уровне с другими библиотеками, сильных просадок, как и сильного превосходства нет
• Одно из явных проблематичных мест — вложенные Tappable протестированы на большом списке, единственная библиотека в которой есть аналогичный кейс это Material-UI, и VKUI сильно обходит ее по производительности (детали)

Замеры проводятся в LH с конфигурацией по-умолчанию, desktop preset: CPU throttling: 1x slowdown (Simulated) Network throttling: 40 ms TCP RTT, 10,240 Kbps throughput (Simulated) ~ сопоставимо с уровнем флагманского Android устройства

В сторонних приложениях был упор на использование максимально схожих компонентов как у VKUI.

Последний отчёт

Библиотеки использованные для сравнения:

list: ant не имеет схожего по сложности компонента для отрисовки сложных списков

list: Framework7 не позволяет вложить одновременно checkbox и radio в компонент списка (List)

modals: Разница на уровне погрешности

list: Fluent не имеет схожего по сложности компонента для отрисовки сложных списков

list: Lightning не имеет схожего по сложности компонента для отрисовки сложных списков

default и modals: Разница незначительная, из-за более длительного First Contentful Paint.

list: При примерно одинаковой загруженности списков в material-ui и VKUI, Average Render Time выигрывает в нашу пользу почти в три раза.

(~1328,6ms в material-ui vs ~476,4ms в VKUI)

list: Spectrum не имеет схожего по сложности компонента для отрисовки сложных списков

В первую очередь кажется, что yandex-ui не предназначен для сторонних разработчиков и этому способствует плохая документация. default: Разница на уровне погрешности

list: Yandex-UI не имеет схожего по сложности компонента для отрисовки сложных списков

В репортах у нас имеется показатель CPU/Memory Power, который не разительно, но отличается в зависимости от воркеров, которые нам может дать GitHub. Из-за этого имеются погрешности в пределах 0,01-0,03, о них нам известно и планируем их устранить.

При 4x slowdown:

• Мы местами обыгрываем и равняемся по показателям на material-ui;
• В странице с модальными окнами уделываем yandex-ui;
• Проигрываем/примерно равны Framework7, у него меньше элементов в DOM списков, но разницу создает невозможность корректно вложить в List одновременно radio и checkbox.

CPU/Memory power может в этом кейсе весомо влиять на результаты

Почему Lighthouse?

Lighthouse - официальный инструмент для измерения Web Vitals и де-факто является стандартом индустрии для оценки производительности в вебе.

• LH ругается на styles.css из VKUI из-за большого количества неиспользуемых стилей и они-же замедляют First Contentful Paint

Два CSS чанка, один из которых весит 27,5 Кб

Related: #1335

• Напрягает показатель Performance в списке с Cell из-за высокой нагруженности Tappable. В примере используется 500 одинаковых по сложности Cell: selectable, в before Avatar, в after IconButton, не disabled.

Важно отметить - CPU throttling при бенчмарке выкручен на 4x slowdown. ~ На уровне бюджетно-среднего Android устройства.

4,2s до возможности использовать приложение. В реальных условиях 500 Cell не нужны, но для каких-нибудь приложений с бесконечными списками это может иметь явное значение (Юла, Работа ВК и пр.)

Related issues: #816, #1442, #1443

• Можно добавить в наш template упаковку с помощью compress-create-react-app, большинство хостингов статики должны поддерживать передачу gzip, в Ubuntu 20.04 (nginx.conf) она включена по-умолчанию. Это довольно сильно влияет на показатель Performance в LH.

Output после выполнения compress-cra

Github Pages поддерживает gzip

"@vkontakte/icons": "^1.82.0",
"@vkontakte/vk-bridge": "^2.4.0",
"@vkontakte/vk-bridge-mock": "^2.1.0",
"@vkontakte/vkjs": "^0.20.0",
"@vkontakte/vkui": "4.3.0",
"react": "^17.0.1",
"react-dom": "^17.0.1",
"react-scripts": "4.0.2"

На момент тестирования брались свежие версии библиотек

Production-profiling сборка, без троттлинга. Замеры проводились с помощью react-devtools, среднее арифметическое из 5 замеров.