Есть ли готовый конфиг вебпака для битрикса?

Question

[Марти Макфлай]

Приветствую!
Нет ли у кого готового конфига вебпака для сборке фронта для битрикса?
Хотелось бы так, чтобы scss/js компонентов собирались в style.css/script.js в корень шаблона компонента, то есть не в один бандл, а в свой для каждого компонента.
А стили самого шаблона в свой общий бандл.
Может у кого есть под рукой или есть ссылочка на гит?

Comments

[Марти Макфлай]

VicTHOR, но ведь тогда будет грузится сразу всё, даже если этих компонентов нет на странице. А так Битрикс сам склеет свой собственный бандл для каждой страницы. Я отстал от жизни?

[Марти Макфлай]

VicTHOR, что ж, тогда это заметно проще. Спасибо за совет.

[Дмитрий]

Марти Макфлай, не стоит верить всему, что говорят в инернете (c) В.И.Ленин

грузить все в одном большом файле было выгодно во времена http/1.0
причины, по которым сейчас стоит разбивать бандл:
1. большой файл дольше качается чем маленький - поэтому код из большого файла выполняется позже кода в маленьком
2. большой размер бандла дольше парсится
3. если в имена мелких файлов пихать их хэш, при обновлении одного файла пользователю не нужно будет перекачивать весь банлд
и тп

Обычно большой блокирующий js аццки тормозит, такая страница давет меньше гуглопопугаев в гуглотесте скорости, что сильно расстраивает некоторых сеошников

Но в некоторых случаях и сейчас использование большого бандла оправдано. Нужно смотреть конкретно ваш проект и уже там решать, как стоит поступать с бандлом

Я бы рекомендовал разбить.
А если хочеццо, чтоб "один раз загрузил сайт и пользуется кэшем при переходе по страницам", ничего не мешает использовать prefetch/preload и подгружать файло динамически

[Дмитрий]

VicTHOR,

prefetch/preload влияет только на этапы отображения страницы

пятница, вечер, работа, ответил неправильно.
поправлю комментарий

особенно когда prefetch/preload влияет только на этапы отображения страницы, а кэширование встроено в браузеры и отключить можно его только специально.

prefetch/preload действительно влияют на очередность загрузки для текущей страницы.
Но есть еще и prefetch, которое позволяет грузить ресурсы для следующей страницы
Плюс, все так же не понимаю, что мешает подгружать оставшееся файло динамически после загрузки минимального набора файлов?

обычно тормозят картинки,

да ну?
а гугл говорит, "Оптимизируйте JavaScript"
https://developers.google.com/web/fundamentals/per...

[Дмитрий]

VicTHOR, ну ок, вот статья-интервью с инженером гугла
https://www.techrepublic.com/article/want-better-j...

Osmani says large bundles of JS scripts can slow the loading of a page and long JS execution times can cause a site to hang, due to monopolizing the page's UI thread.

Osmani advises web developers to improve download times by keeping JavaScript bundles small and by splitting large bundles, upwards of 50kB, into separate smaller bundles that can be handled in parallel.

сам перевести сможешь?

[Дмитрий]

VicTHOR, ну так я выше и написал
"грузить все в одном большом файле было выгодно во времена http/1.0"

[Дмитрий]

VicTHOR, и чо? мы о преимуществах протокола спорим? или все же про размер бандла?

но если упорно хочешь поспорить, давай рассмотрим такую ситуацию:
"обновили цвет на странице 'контакты', повторный визит пользователя с медленным соединением на главную страницу"

1. сайт на http/1, один большой бандл, грузим везде -> будет "быстро" перекачивать весь файл
2. сайт на http/2, много мелких файликов, грузим нужное на нужных страницах, после загрузки догружаем оставшееся -> все возьмет из кэша, пока пользователь смотрит страницу, в фоне "медленно" докачает маленький файлик

что будет быстрее для пользователя?