Филлип Уолтон недавно опубликовал статью про проблему каскадной инвалидации кэша — «Cascading Cache Invalidation».

Нежелательная инвалидация может возникнуть тогда, когда сборщик генерирует имена файлов с хэшами, которые напрямую импортируются в других файлах. Предположим, что во время сборки из всех файлов, находящихся в node_modules, создаётся файл vendor.<hash>.js. Если этот файл импортируется в других модулях, то из-за постоянно меняющегося хэша, будут изменяться хэши у всех зависимых модулей. Соответственно, браузер будет заново загружать тот код, который фактически не менялся.

Для решения этой проблемы Филлип предлагает использовать import maps (на данный момент поддержка есть только в Chrome за флагом), сервис воркеры или AMD-загрузчик (в статье разбирается пример SystemJS с Rollup.js).

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

В общем, статья полезная. Рекомендую почитать.

#performance #bundle

https://philipwalton.com/articles/cascading-cache-invalidation/

Дэвид Калхоун написал статью про влияние на производительность разных подходов к бандлингу кода — "Bundling JavaScript for Performance: Best Practices".

Самый лучший вариант отделить вендорный код от кода приложения и доставлять бандлы до пользователей с помощью CDN-провайдеров. Подключение библиотек, которые хранятся на публичных CDN (cdnjs, jsdelivr и т.п.), нежелательно. В Safari использование публичных CDN приводит к лишнему запросу даже в том случае, когда в соседней вкладке другой сайт загружал ту же самую библиотеку с того же самого сервера. Это сделано для предотвращения отслеживания пользователей. В Chrome отключение общего кеша появилось с 77-ой версии, но пока за флагом.

Статья неплохая. Стоит почитать, если хотите узнать про подходы к бандлингу, их плюсы и минусы.

#performance #bundle

https://calendar.perfplanet.com/2019/bundling-javascript-for-performance-best-practices/

Иван Акулов проанализировал js-бандлы и флоу загрузки web-приложения Notion и дал много советов по улучшению его производительности — "Case study: Analyzing Notion app performance".

Приложение загружается долго, это особенно заметно на смартфонах среднего ценового сегмента — время загрузки достигает 12 секунд. Больше всего времени уходит на парсинг и выполнение JS. В решении этой проблемы может помочь код-сплиттинг и удаление ненужного кода. Notion использует lodash, чтобы удалить из его кода неиспользуемые методы юзают babel-plugin-lodash. Notion для работы с датами использует moment, вместо этой библиотеки лучше использовать современные и оптимизированные альтернативы, например, date-fns. Также в бандле приложения было найдено три разных версии core.js — библиотеки полифиллов. Такое происходит, когда приложение и зависимости используют core.js разных версий. Для решения этой проблемы можно настроить маппинг модулей с помощью resolve.alias в конфиге wepback. В статье есть рекомендация транспилировать модули в CommonJS с помощью babel-плагина plugin-transform-modules-commonjs с опцией lazy. Такая оптимизация позволяет отложить выполнение js-кода, который можно не выполнять на этапе инициализации приложения.

Очень большая и хорошая статья. Обязательно почитайте, если разрабатываете SPA.

#performance #bundle

https://3perf.com/blog/notion/

Для того чтобы бандлер смог безопасно применить tree-shaking, он должен понимать, что можно удалить, а что нужно оставить. Серджио Гомес написал про это статью — "Everything you never wanted to know about side effects".

Во время импорта модули могут вызывать сайд-эффекты: обновлять состояние внутри других модулей, добавлять глобальные переменные, инициализировать полифиллы и т.п. Бандлеры не рискуют и не удаляют код, так как предполагают, что в модулях могут быть сайд-эффекты. Случайное удаление такого кода с большой вероятностью сломает приложение.

Чтобы tree-shaking заработал, авторы библиотек добавляют в package.json поле "sideEffects": false, если в библиотеке нет сайд-эффектов, или явно перечисляют файлы, которые нельзя удалять "sideEffects": ["a.js", "b.js"]. Также в исходном коде можно использовать хинт /*#__PURE__*/. Благодаря этому хинту бандлер понимает, что такой код не содержит сайд-эффектов, и его можно безопасно удалить.

Очень рекомендую заглянуть в статью авторам библиотек и всем, кто сталкивался с проблемами tree-shaking.

#performance #bundle

https://sgom.es/posts/2020-06-15-everything-you-never-wanted-to-know-about-side-effects/

Вчера зарелизился Webpack 5 с огромным количеством изменений.

TLDR

В новой версии была улучшена скорость сборки. Была улучшена поддержка долгосрочного кэширования бандлов. Улучшен tree shaking. Реализован новый подход для работы с ассетами. Добавлена новая фича Module Federation. Удалены полифиллы для Node.js-модулей. Код сборки может генерироваться в стандарте ES2015.

Подробнее

Улучшена скорость сборки благодаря кэшированию на диске служебных данных между разными сборками (Persistent Caching).

Было проделано много работы для улучшения tree-shaking. В новой версии Webpack использует статический анализ для построения графа зависимостей, благодаря чему удаляется больше неиспользуемого кода. Также Webpack благодаря статическому анализу определяет модули без сайд-эффектов и не включает их в бандл, если они не используются. Был улучшен tree-shaking CommonJS-модулей.

Было упрощено использование ассетов. Теперь не нужно устанавливать дополнительные загрузчики, например, file-loader, url-loader, raw-loader. Сергей Мелюков в феврале публиковал статью про ассеты в Webpack 5, рекомендую почитать.

С пятой версии стала доступна ещё одна новая фича — Module Federation. Благодаря ей приложение может прозрачно заимствовать код из других приложений. Это позволяет делать интересные вещи, например, разделить одно большое SPA на несколько небольших. Это SPA с точки зрения пользователя будет работать как одно целое, но может разрабатываться и деплоиться разными командами независимо друг от друга.

Улучшена совместимость с Web-платформой: добавлена поддержка Top Level Await, JSON Modules, WASM Modules, import.meta.

Четвёртая версия Webpack могла генерировать код сборки только в стандарте в ES5. С пятой версии код сборки может генерироваться в стандарте ES2015.

Были удалены полифиллы для Node.js ( node.Buffer, node.console, node.process, crypto и т.п.) Когда появился Webpack, npm чаще всего использовали для распространения Node.js-модулей, поэтому в то время имело смысл поставлять со сборщиком полифиллы. Сейчас ситуация изменилась — в npm есть много кода, который можно использовать и в Node.js, и в браузерах. Также очень много внимания сегодня уделяют размеру генерируемого кода, а полифиллы Node.js могут добавлять очень много кода. Но не все рады удалению полифиллов. Синдре Сорхусу — автору многих библиотек в экосистеме Node.js — это решение не понравилось. Он пишет про то, что не будет исправлять проблемы, связанные с Webpack 5.

В общем, релиз очень большой. Ребята проделали огромную работу. В статье написано, что есть вероятность появления проблем при использовании свежей версии, но начинать миграцию сборки уже можно. Разработчики ждут нашего фидбека и сообщений об ошибках.

#webpack #release #bundle

https://webpack.js.org/blog/2020-10-10-webpack-5-release/

В блоге debugbear было опубликовано исследование проблем производительности интерфейса Google Cloud — "Why is the Google Cloud UI so slow?".

Google Cloud — это SPA, написанное на Angular. Оно включает в себя несколько страниц, которые загружают по 4-5Мб сжатого JavaScript-кода. Основное содержимое страницы появляется через шесть секунд после начала загрузки страницы.

Основные идеи из статьи. Для SPA очень критично время выполнения кода. Чем больше бандл, тем больше времени требуется на его парсинг, компиляцию, инициализацию, поэтому очень важно не заставлять пользователей скачивать лишний код. В Google Cloud на момент инициализации страницы используется только 50% от всего загруженного кода. Также в разных бандлах дублируются одни и те же компоненты и конфигурационный код. Ещё в статье есть рекомендация загружать второстепенный контент (например, меню) только тогда, когда он, действительно, будет нужен.

Хорошая статья. Рекомендую почитать всем, кто интересуется темой производительности.

#performance #js #bundle

https://www.debugbear.com/blog/slow-google-cloud-ui

На прошедшем Chrome Dev Summit Хуссейн Джирде и Джейсон Миллер рассказали про использование JavaScript-кода с современным синтаксисом. По мотивам этого доклада была написана статья "Publish, ship, and install modern JavaScript for faster applications".

Многие проекты по инерции используют транспиляцию новых фич JavaScript в ES5, из-за чего страдает производительность в современных браузерах. Транспиляция в ES5 нужна только для старых браузеров, которыми пользуются 5% пользователей. Чтобы доставить разные версии бандлов для современных и старых браузеров, можно использовать паттерн module/nomodule. Для его реализации нужно собрать два бандла: лёгкий для современных браузеров (ES2017) и тяжёлый для устаревших браузеров (ES5). В статье подробно разбирается, как это сделать с помощью webpack и rollup. Ещё в статье есть советы о том, как публиковать npm-пакеты с современным синтаксисом.

Также в докладе/статье был анонсирован новый сервис EStimator.dev, с помощью которого можно оценить прирост производительности сайта от перехода на современный синтаксис.

#js #performance #bundle

https://web.dev/publish-modern-javascript/

Несколько дней назад вышла новая версия Snowpack. Фред Шотт — автор проекта — рассказал про все новинки релиза.

Snowpack — это инструмент для сборки фронтенд-приложений. В отличие от Webpack, Rollup и Parcel, приложения, использующие Snowpack, не нуждаются в пересборке бандла на каждое изменение файлов во время разработки. Snowpack транспилирует файлы точечно без бандлинга всех файлов, делегируя процесс создания графа зависимостей и его загрузки браузерам с помощью нативных JavaScript-модулей. То есть если вы пишете большое приложение и сделали изменения, например, в файле Header.tsx, то транспилироваться будет только он, тем самым уменьшая время обратной связи на каждое изменение файлов в разы по сравнению с другими бандлерами.

В Snowpack v3.0 были добавлены Streaming Imports. Благодаря им Snowpack может загружать и кэшировать npm-модули без явного использования npm install. С этой версии Snowpack может создавать оптимизированные production-билды с помощью esbuild (очень быстрый сборщик, написанный на Go). Реализован новый API, который уже используется в SvelteKit. Сгенерированные с помощью Snowpack файлы теперь можно без проблем импортировать в Node.js.

В общем, не релиз, а бомба. Рекомендую посмотреть в сторону Snowpack, если используете обычные сборщики и ждёте по несколько минут пересборки проекта при сохранении файлов.

#release #bundle #tool

https://www.snowpack.dev/posts/2021-01-13-snowpack-3-0

Несколько дней назад команда разработчиков Vue зерилизила Vite 2.0. В статье "Announcing Vite 2.0" Эван Ю рассказал о новом проекте.

Vite — это сборщик и dev server, использующий ESM, для ускорения применения изменений на этапе разработки. По своей философии он очень похож на Snowpack и WMR.

Vite создавался для улучшения разработки Vue-приложений, но команда разработчиков решила сделать его независимым от Vue (на данный момент есть поддержка Vue, React, Preact и LitElement). Из-за смены курса разработки первая версия так и не достигла стабильной версии, поэтому Vite 2.0 можно считать официальной первой стабильной версией.

Vite очень похож на Snowpack, но в нём есть несколько уникальных фич: поддержка автоматического код-сплиттинга для CSS, поддержка многостраничных приложений, есть режим для разработки браузерных библиотек, есть встроенная поддержка монорепозиториев и CSS-препроцессоров.

#tool #bundle

https://dev.to/yyx990803/announcing-vite-2-0-2f0a

Хью Хауорт написал обзор современных инструментов сборки — "Comparing the New Generation of Build Tools".

В статье рассказывается про esbuild, Snowpack, Vite и wmr. Esbuild — это очень шустрый сборщик, написанный на Go. Snowpack, Vite и wmr — сборщики нового поколения. Они полагаются на нативную модульную систему JavaScript, устраняя шаг сборки приложения во время разработки.

Snowpack позволяет подключать и гибко настраивать разные сборщики для production-сборки проекта. Vite, наоборот, исповедует принцип zero-configuration, предоставляя набор настроек, которые подойдут большинству проектов. Wmr — самое лёгкое решение, но из коробки поддерживает только React и Preact. Esbuild в этом сравнении стоит особняком, так как это обычный, но очень быстрый сборщик.

Большая и хорошая статья. Очень рекомендую почитать.

#bundle #tool

https://css-tricks.com/comparing-the-new-generation-of-build-tools/