Комментарии 12
Насколько я понял, с сервера приходит огромный JSON, описывающий все элементы интерфейса. Загружается он долго, и вы решаете проблему так:
Парсинг JSONа по кусочкам по мере загрузки и немедленный рендер полученных элементов.
Создание низкоуровневых
ReactElementвручную, в обход стандартных механизмов Реакта.
Если первое еще как-то можно оправдать безальтернативным и неизменяемым бэкэндом, то второе вряд ли даст вам что-то, кроме потенциальных проблем.
ИМХО, целесообразнее
Разделить запросы на каркас и контент
Загружать каркас первым, потом то, что above the fold, показывать скелетоны вместо единого спиннера и т.д.
Юзать HTTP/2 Push, 103 Early Hints и т.п.
В статье рассматривается концепция BDUI. Безусловно, подход спорный, но на практике многие компании в той или иной форме применяют его, что позволяет им существенно бустить производительность разработки.
Понятно, что если у вас чистая PWA без нативного мобильного приложения, то BDUI, скорее всего, вам не нужен. Однако в мультиплатформенной среде он может дать ощутимую выгоду.
Теперь по поводу вашего комментария. Могли бы вы подробнее рассказать, каким образом вы планируете реализовать описанную вами логику в рамках BDUI? Допустим, у вас есть JSON, описывающий интерфейс. Как именно вы собираетесь разделить этот JSON на каркас (skeleton/layout) и остальную структуру?
Обратите внимание, что этот же JSON используется и нашей мобильной командой. Унификация данных между платформами помогает нам существенно ускорять внедрение новых фич и снижать дублирование логики.
А каким тут боком тэг Си++ тут стоит?
Нам, плюсовикам, немного чуждый ваш мир фронт-энда. Хотя, прочитав статью, нашёл нечто похожее, что делали в играл, которые на С/С++, чтобы грузить уровень не целиком, ожидая полминуты, а по ходу пьесы.
Настораживает, что в «стало» нет ни одного числа. А в «было» числа есть. Подозреваю, что не так хорошо получилось, как автор нам рассказывает.
На демо-стенде показало 30% прирост к скорости. Точных цифры могут варьироваться в зависимости от реальных условий и объёма данных на живом проекте. Плюс по перфоманс профайлу есть видимость, что сборщик мусора срабатывает реже, что тоже ускоряет загрузку.
Извините, но 30% это по сути ни о чем. Оно было так плохо, что нужен прирост скорости в 300% (уменьшение время отклика на 66%), (из 15с до 5с) чтобы стало «просто плохо». Чтобы стать «хорошо» время реакции нужно меньше чем 2с, а 1с – «прекрасно». А это уже 1500% ускорения.
Так что статью надо понимать как руководство как делать не надо.
.
Как я понял, вы ориентируетесь на замеры в локальной среде без сетевых ограничений. 15 секунд закладывается на загрузки с учётом условий мобильной сети у реальных пользователей. В таких условиях получить 1 секунду — невозможно. Указанные 30% — это показатели, снятые с мобильных устройств.
Обсуждать скорость загрузки в контексте статьи — всё равно что обсуждать сферического коня в вакууме. Всё, конечно, упирается в размер JSON и итогового JS-бандла: чем больше логики и кода, тем дольше загрузка.
Тем не менее, никого ни к чему не призываю и не пытаюсь переубедить. Было бы интересно узнать про ваш опыт с BDUI, если есть: какие цифры получались у вас и что для этого делали.
Для первой итерации я бы исходил из реальной потребности для первого рендера. Предполагаю что в большой JSONке есть ключи и при желании можно запрашивать с бэка нужный ключ, а не всю. А потрм можно сервис воркер подключить для префетча остального.
Куда мы катимся... Сотни килобайт ТЕКСТОВОГО содержимого, которое надо распарсить, а ещё js и прочее содержимое. Да-да, есть сайты ещё хуже, тянущие десятки и даже сотни мегабайт js-содержимого и это далеко не ноунеймы, я знаю, но... Эх, в какой момент всё стало настолько плохо? И люди, которые говорят, что загрузка страницы за 10 сек вместо 15 это хорошо - это как понимать? Вообще-то это катастрофа, знаете ли! Хотите обижайтесь, хотите нет, но не надо себе и нам пытаться втюхать, что это «нормально».
Как улучшить UX в PWA на React с помощью потокового Backend-Driven UI — личный опыт