Comments 17
самое большое приложение состоит из 10 000 модулей и без оптимизаций собирается 28 минут. Мы смогли ускорить сборку до двух минут!Как часто и в каких случаях у вас запускается эта сборка?
Локально на машине разработчика проект собирается каждый день, но локальный запуск не такой ресурсоёмкий — в dev сборке нет оптимизаций и можно собирать только нужные для разработки части приложения. В CI проект собирается от нескольких раз до нескольких десятков раз за день.
У нас в N1.RU самое большое приложение состоит из 10 000 модулей
А это нормально в браузер столько модулей?
Можно пойти еще дальше и использовать Preact вместо React и date-fns вместо moment. Я еще использую ES6 / ES5 бандлы в зависимости от браузера — размер становится еще меньше. Полезная статья: https://github.com/GoogleChromeLabs/webpack-libs-optimizations
Можно кстати во многих случаях вообще обойтись нативным JS интерфейсом new Date. Пока что в текущем проекте так и работаем, и в целом всё нормально.
Вопрос в том, как часто его придется использовать. Для простого бложика будет проще написать функцию, которая будет форматировать дату публикации, чем тащить за собой весь moment.
А теперь к позитивному: сталкивались ли с FOUC при асинхронных стилях и как лечили?
сталкивались ли с FOUC при асинхронных стилях и как лечили?
Как я понимаю, вопрос про загрузку стилей при SPA переходе с одного чанка на другой. При SPA переходе мы загружаем стили и JS, если на момент загрузки JS стили еще не загружены, мы ждем не больше 300мс их дозагрузки и рендеримся. Это не полностью решает FOUC, но в целом стало немного лучше.
Для мобильной версии сайта у нас все стили идут инлайном в html разметку, как критический CSS. Там очень мало стилей и мы решили их просто зашить в html, чтобы не иметь никаких проблем с FOUC.
Спасибо за доклад, много интересных рекомендаций.
А подставлять в html только нужные js и css чанки на этапе серверсайд рендера ещё не пробовали?) Я примерно пол года проходил этот квест, но в итоге всё получилось..
Начинается всё примерно здесь: https://github.com/faceyspacey/react-universal-component.
И оно того стоит, да.
Мы тоже успешно прошли этот квест ;) но только у нас vue.js и готовых решений не было. Если вкратце, со стороны SSR мы отдаем:
- app.js — ядро приложения
- common.js — общие части для многих чанков
- manifest.js — тот самый рантайм вебпака из доклада
- чанк текущей страницы
- app.css
- common.css
- стили текущей страницы
- Если есть критические стили для страницы, то их вшиваем в html в тэг
<style>
, а все стили указанные в предыдущих пунктах грузим неблокирующим способом. Примерно как описано здесь
А каким образом вы определяете, какие конкретно стили нужны для текущей страницы? Просто интересно, как вы это решили без сторонних библиотек.
Все приложение поделено на модули. По сути модуль у нас это отдельная страница, например модуль главной страницы. У всех асинхронных чанков имя 1 в 1 как у модуля. Во время сборки мы собираем manifest.json, где зашит мапинг имени чанка в название ресурса.
Например:
{
"MainPage.css": "css/MainPage.d41d8cd98f00b204e9800998ecf8427e.css",
}
На стороне серверного рендеринга мы достаем из собранного манифеста по имени модуля путь до его css и вставляем соответствующий style тэг в разметку.
Сейчас должно быть куча плагинов, которые это автоматизируют, но у нас свой велосипед встроенный в другой велосипед.
Надеюсь ответил на вопрос :)
Не совсем корректно освещен вопрос минификации, а точнее то что Uglify уже мертв, но раньше работал из коробоки при mode:production
, как и Terser, что пришел ему на смену.
Ну и, конечно, отдельная сборка ESM/ES5 бандлов в вашем случае будет немного не возможна (долго). Могу порекомендовать devolution как легкое решение проблемы.
Вам достаточно было заменить moment.js на $mol_time и не плясать вокруг тришейкинга. lodash, bluebird вообще можно безболезненно выкинуть. Ну а замени вы React на $mol_view всё ваше приложение стало бы меньше, чем один только вендорный бандл.
Собираем бандл мечты с помощью Webpack