Хороший сайт для создания простых перформанс бенчмарков на js. Не уверен, что это прям самый лучший сервис для бенчмарков, но он достаточно удобный, и если вам не нужна супер большая точность - то выглядит гуд.
Приятный интерфейс и возможность делиться ссылкой на конкретный бенчмарк без авторизации.
Статья от Vercel про вред от паттерна barrel file. В статье vercel рассказывают, как они оптимизировали импорты в next.js чтобы избежать обработки таких файлов и как ускорили сборку и старт приложения на 30-40%
barrel-file - это когда, например, в корне библиотеки лежит index.js, который ре-экспортит кучу сущностей из других вложенных файлов. Проблема в том, что не смотря на то, что в коде используется всего лишь 1 ре-экспортируемая сущность, бандлерам и некоторым тулам, например jest, приходится сначала обработать все файлы. Что снижает скорость работы инструмента
Каноничный пример
export { default as module1 } from './module1';
export { default as module2 } from './module2';
export { default as module3 } from './module3';
Некоторые библиотеки имеют около десяти тысяч ре-экспортящихся сущностей, что значительно влияет на скорость импорта такой библиотеки.
Команда next.js ввела новую опцию в конфиг: optimizePackageImports, которая заставляет фреймворк просканировать barrel-file и в рамках сборки поменять импорты на более точечные. Это изменение позволило ускорить сборку на 15-70%. Например, импорт @material-ui/icons ускорился с 10 секунд до 2.9 секунды.
Также в статье указана ссылка на eslint-плагин, который умеет оптимизировать импорты barrel-файлов
Новая статья про ускорение JS экосистемы. На этот раз автор не разбирает какой-то конкретный кейс, а в целом рассказывает об одном паттерне, который замедляет исполнение кода.
Паттерн сегодняшней статьи - это index-файлы с ре-экспортами. В сообществе есть консенсус большинства, что у библиотек или модулей должен быть index.js, который содержит все публичное API, и дальше лезть никому не нужно. А если вы используете не все из этого API, то tree-shaking вырежет все лишнее.
В целом, это так и есть, но не всегда. Tree-shaking актуален только для кода, который был обработан бандлером. Если же код не обрабатывается бандлером, то рантайм вынужден все import'ы обработать, что увеличивает время выполнения кода.
Например, если код не бандлить и просто поставлять модулями в браузер, то браузеру придется обработать все дерево зависимостей index.js файла, даже если вам нужна одна простая утилка.
Также это проблема, с которой я сталкиваюсь при написании тестов в jest. Код импортирует 1 утилку, но она импортируется из index.js файла, поэтому jest тратит 5-10 секунд на резолв всех зависимостей, и 100мс на запуск самих тестов.
При этом index.js файлы - это не анти-паттерн. Да, у него есть минусы, но они проявляются только если они используются в окружениях, где код запускается без бандлинга и если таких файлов неприлично много. Если index.js используются к месту или в проекте, который не живет без бандлинга - то такие файлы не будут создавать негативный эффект.
Статья от 2ГИС про то, как разные агрегации по миллионам объектам на карте. 2ГИС часто радует своими статьями с интересными высоконагруженными кейсами, и эта статья - не исключение, хотя коротковата
В статье рассказывается, как можно обрабатывать огромные массивы данных в браузере. Если коротко, то решение 2ГИС в использовании следующих инструментов: WebWorkers, передача данных в бинарном виде, обработка на GPU
Статья от команды Dropbox о том, как они сменили бандлер и уменьшили размер JS статики на треть.
Dropbox - крупная компания со своими сложными вызовами и поэтому, в 2014 году они сделали свой бандлер и свою технологию Dropbox Web Server (DWS). DWS позволяет делать модульный веб - страница состоит из независимых страничных блоков (pagelet), которые разрабатываются и обрабатываются независимо друг от друга.
Кастомный бандлер сильно отстал от лидеров рынка и поэтому было принято решение переезжать на современные решения. Самые крупные проблемы предыдущей архитектуры:
Все эти проблемы давно решены текущими сборщиками, но не были решены в самописном решении. Dropbox переехал на использование rollup, но при этом миграция на него была плавная: сначала только dev сборка, затем только для сотрудников, затем раскатка на пользователей.
Во время плавной миграции были следующие трудности:
Как результат:
