Хороший сайт для создания простых перформанс бенчмарков на js. Не уверен, что это прям самый лучший сервис для бенчмарков, но он достаточно удобный, и если вам не нужна супер большая точность - то выглядит гуд.
Приятный интерфейс и возможность делиться ссылкой на конкретный бенчмарк без авторизации.
Очень крутая и интерактивная статья, наглядно объясняющая как работают разные retry стратегии.
В рамках статьи объяснения про то, зачем нужны retry и почему наивная реализация "повторить запрос через секунду" сопровождаются интерактивными примерами: в них визуально моделируется отправка запросов клиентами на сервера, а вы, как читатель, можете контролировать rate ошибок сервера, количество серверов и прочие параметры.
Некоторые примеры можно использовать как эталон для обучения. Мне очень сильно понравился кейс, где при переключении рейта ошибок на 100% сервера складываются, но при включении обратно в 0% они не поднимаются - клиенты отправляют слишком много запросов за раз, вновь поднятые инстансы не успевают их обработать. Но там можно добавлять новые сервера и автор ставит вопрос "как думаете, сколько нужно дополнительных серверов, чтоб система снова начала работать?", что прямо таки мотивирует сначала подумать, а потом и испытать свою догадку
Статья от 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 используются к месту или в проекте, который не живет без бандлинга - то такие файлы не будут создавать негативный эффект.
Обзор на разные метрики для оценки продуктивности команды разработки.
В статье обсуждается зачем нужны такие метрики и какие подходы есть в индустрии для сбора этих метрик
Зачем нам нужно замерять команды разработки:
Но как правильно померить команду разработки? Это нетривиальная задача и подходы к решению этой задачи менялись с течением времени
Когда то давно, достаточно было замерять строчки кода (например, в книжке "мифический человекомесяц" часто встречаются кейсы, где проекты замеряются по строчкам кода).
Затем перешли на измерение velocity и cycle time. Velocity замеряет объем поставляемых в итерацию задач. Cycle time - время от "взяли задачу в проработкуработу" до "поставили ценность клиенту". Эти метрики уже намного ближе к бизнесу, чем строчки кода. Они проверяют, насколько команда гибкая (насколько быстро она проверяет гипотезы)
Позже, DevOps движение принесло DORA (DevOps Research and Assessment) - 4 ключевых метрики, по которым можно понять эффективность команды:
Эти метрики направлены на то, чтобы команды могли поставлять изменения как можно чаще с как можно большим качеством. Метрики DORA основаны на эмпирических данных кучи команд. Эти данные были собраны и затем выделены средние, лучшие и худшие результаты. Вы всегда можете загуглить текущий отчет DORA и сравнить свои показатели метрик с табличками оттуда и сделать выводы, что вам следует развивать.
Следующий набор метрик - SPACE.
Тут уже делается акцент на уровне счастья разработчика и на эффективности процессов. Но при этом, в статье (я не понял это прям в SPACE предлагается или в статье так интерпретировали этот набор метрик) предлагается замерять скорость и эффективность Code Review, что, на мой взгляд, не очень хорошо
В этом году появился DevEx, который предлагает замерять циклы обратной связи, когнитивную нагрузку и возможность для потоковой работы в разрезе персональной работы, системы и KPI
В общем, оценивать эффективность разработки очень сложно и есть разные подходы, которые можно комбинировать.
Статья рассматривает 3 различных стандарта для сжатия файлов: gzip, brotli (решение от Google) и ZStandard (решение от Facebook). Рассматриваются эти стандарты с точки зрения распаковки npm-пакетов. В целом, неплохой обзор на разные инструменты для сжатия контента
В рамках сравнения получились следующие выводы: ZStandard эффективнее сжимает чем gzip и быстрее распаковывается. Brotli же сжимает еще эффективнее, но не так быстр в запаковке и распаковке контента.
Но при этом для сжатия npm пакетов используется gzip. Почему так, если другие форматы эффективнее? Все дело в обратной совместимости. Brotli поддерживается нативно с npm 10 (если я правильно понял статью), а значит, пока есть клиенты с более мелкими версиями npm - включать brotli как решение по умолчанию - нельзя. Так что к 2027 году можно будет переходить на brotli по-умолчанию. А поддержки ZStandard в npm пока еще нет, поэтому вряд ли стоит ожидать его применения
PS: отдельно порадовала отсылка в названии статьи к фильму "Дорогая, я уменьшил детей", который был у меня в детстве на кассете :)
Есть статьи Дэна Абрамова и Кент Си Доддса, объясняющие, как правильно композировать компоненты в React, чтобы не требовалось использование React.memo. Но в чем проблема React.memo?
Статья разбирает, почему использование React.memo приводит к усложнению кода. Если коротко, то React.memo использует для сравнения Object.is, что влечет за собой требование прокидывания стабильных ссылок на объекты и функции в пропсы. А это, в свою очередь, требует заворачивания в useMemo всех объектов, вместо простого их прокидывания, даже если они не изменяются.
Например, в коде <ExpensiveTree style={{ backgroundColor: 'blue' }} /> при каждом рендере style будет новый, поэтому, чтобы не вызывать ререндер, нужно либо вынести style в константы за компонент (что не всегда возможно), либо завернуть объект в useMemo
Также, если компонент принимает children, то JSX разметка тоже не является стабильной ссылкой, из-за чего при каждом рендере children будет отличаться
Поэтому, вместо использования мемоизации следует рассматривать другие альтернативы: правильная композиция компонентов или стейт-менеджеры
Хорошая статья, объясняющая на простых примерах практики для взаимодействия с сервером, который отдает ошибки. Наверняка, вы сталкивались с ситуацией, когда сервер иногда отвечает ошибкой, но если повторить запрос - то ответит корректно. Решение на поверхности - просто влепить retry. Что может пойти не так?
Статья как раз и объясняет что может пойти не так. Если коротко, то retry может привести к тому, что нагрузка на сервер вырастет и он перестанет справляться с обработкой запросов. После этого количество ошибок возрастет, количество retry увеличится, что приведет к еще более печальным результатам. В статье рассказывается как правильно делать обращения к нестабильному серверу
Первая практика: retry. Если все клиенты будут использовать retry с одинаковым таймаутом между запросами, то если серверу станет плохо - ретраи его добьют. Чтобы этого не случилось, используют exponential backoff retry - это когда ретраи делаются не через фиксированные отрезки времени, а эти отрезки увеличиваются. Грубо говоря, если сервер не смог ожить за первые 2 быстрых ретрая, то вряд ли он оживет в ближайшее время, поэтому есть смысл увеличивать с каждой попыткой интервал между попытками.
Если все клиенты будут ретраить с одинаковыми таймаутами, то нагрузка на сервер будет происходить волнами. Чтобы это устранить, добавляют jitter - случайную задержку к интервалам между ретраями.
Но в целом, при долгом отказе сервера, даже "умные" ретраи не спасают - они лишь откладывают пик нагрузки. Поэтому применяют и другие практики: Retry circuit breaker и Retry budget.
Практика Retry circuit breaker говорит о том, что ретраи допускается делать если количество ошибок от сервера не превышает порог. Если превышает - мы считаем что сервис немножко нездоров и долбить его ретраями - значит делать хуже
Практика Retry budget говорит о том, что ретраев не должно быть больше определенного порога от количества успешных запросов. Например, не больше 10% от запросов.
Но и это еще не все. Еще существует практика deadline propagation. Это когда клиент в запросе передает значение таймаута и сервер, получая запрос на обработку из очереди обработки, может принять решение - есть ли смысл его обрабатывать. Или прекратить обрабатывать запрос, ответ на который клиент уже не ждет.
В общем, крутая статья с хорошими примерами и графиками про основные паттерны борьбы с нагрузкой на нестабильный сервер
Короткая статья про кеширующие хедеры. При настройке заголовков ответа на сервере или CDN можно указать правила кеширования. Если их правильно настроить, это сильно поможет и пользователю и приложению.
Автор разбирает 2 простых сценария: кеширование до изменения и вечное кеширование.
Если у вас есть ресурс, который иногда меняется, то имеет смысл выставить следующее значение заголовка Cache-Control: public, max-age=0, must-revalidate. В этом случае браузер при повторном указании ресурса будет спрашивать у веб-сервера, изменился ли указанный ресурс или нет. И если не изменился - сервер ответит 304 кодом, что означает, что браузер может взять контент из кеша. В этом случае выигрывают все - пользователь не скачивает лишний трафик, не ожидает загрузки. Сервер же не тратит свои ресурсы на раздачу файла
Если у вас есть ресурс, который никогда не меняется (например, JS-статика с хешом в имени), то в заголовок можно передать public, max-age=31560000, immutable.
public означает что ресурсы может быть закеширован как на устройстве так и на посредниках
max-age=31560000 указывает, что ресурс кешируется на 1 год
immutable означает, что браузер не должен перезапрашивать ресурс, если он уже есть в кеше.
В целом эти 2 совета могут быть верны для многих случаев, но в реальности могут быть случаи между двумя этими крайностями. Разработчику следует подумать о кешировании своих ресурсах т.к. правильная стратегия кеширования является вин-вин ситуацией: и пользователь и сервер выигрывают от правильно настроенного кеширования
Статья объясняет проблему тротлинга рендера при вложенных Suspense. Не уверен что это корректно называть тротлингом, но сама проблема интересна.
Представьте, что у вас есть вложенные Suspense. React работает так, что если первый Suspense ушел в ожидание раньше, чем рендер дошел до вложенного Suspense, то как следствие когда promise, подвесивший первый Suspense выйдет из ожидания, рендер дойдет до второго Suspense и мы бы ожидали увидеть контент первого Suspense и fallback у второго. Но на практике наблюдается некоторое время, когда мы видим состояние fallback первого Suspense. Так происходит потому что React умный и не комитит изменения Virtual DOM сразу в DOM, а ждет некоторое время. Из-за чего появляется задержка, когда мы бы могли уже показать пользователю контент, но этого не происходит.
В принципе, ничего криминального React не делает, но факт интересный
Статья от 2ГИС про то, как разные агрегации по миллионам объектам на карте. 2ГИС часто радует своими статьями с интересными высоконагруженными кейсами, и эта статья - не исключение, хотя коротковата
В статье рассказывается, как можно обрабатывать огромные массивы данных в браузере. Если коротко, то решение 2ГИС в использовании следующих инструментов: WebWorkers, передача данных в бинарном виде, обработка на GPU
Статья от команды Dropbox о том, как они сменили бандлер и уменьшили размер JS статики на треть.
Dropbox - крупная компания со своими сложными вызовами и поэтому, в 2014 году они сделали свой бандлер и свою технологию Dropbox Web Server (DWS). DWS позволяет делать модульный веб - страница состоит из независимых страничных блоков (pagelet), которые разрабатываются и обрабатываются независимо друг от друга.
Кастомный бандлер сильно отстал от лидеров рынка и поэтому было принято решение переезжать на современные решения. Самые крупные проблемы предыдущей архитектуры:
Все эти проблемы давно решены текущими сборщиками, но не были решены в самописном решении. Dropbox переехал на использование rollup, но при этом миграция на него была плавная: сначала только dev сборка, затем только для сотрудников, затем раскатка на пользователей.
Во время плавной миграции были следующие трудности:
Как результат:
История про оптимизацию перформанса генератора снапшота памяти в V8.
Инженеры bloomberg пытались поймать утечку памяти в своем nodejs приложении, но снапшот памяти на 500МБ снимался полчаса - непозволительно долго. Инженеры запрофилировали работу генератора снапшота и нашли 2 проблемы, решив которые они смогли ускорить генерацию снапшота на 100МБ памяти с 10 минут до 6 секунд (ускорение в 100 раз)
Первая найденная проблема - это алгоритм хеширования строк. V8 сохраняет все строки в отдельной оптимизированной хешмапе. Для чисел, представленных как строки, используется отдельный алгоритм для вычисления ключа для хранения в хешмапе. Этот алгоритм приводил к тому, что часто возникали колизии хешей, из-за чего операции с хешмапой замедлялись. Автор поправил алгоритм, добавив небольшой побитовый сдвиг.
Вторая найденная проблема - для каждой функции хранится информация о строке и колонке, где она начинается. Однако, v8 обычно сохраняет только количество предшествующих функции символов в файле и рассчитывает строку и колонку только тогда, когда это нужно (подсчитывая, по сути, символы переноса строки). Т.к. этот расчет - дорогой, то v8 хранит эти данные в кеше. Однако, при сборе снапшота этот кеш не используется. Поэтому инженеры Блумберг добавили сбор этого кеша перед сбором снапшота.
