Занимался сейчас оптимизацией времени старта @tramvai/cli, и самый популярный паттерн такой:
- снять CPU profile
- найти самые тяжелые CJS require вызовы
- если импортируемые пакеты не используются, заменить обычный import в начале файла на require(lib) по месту вызова

Буквально несколько тяжелых импортов зря занимали 500-1000ms на старте скрипта, очень эффективная и простая оптимизация, хоть и требует ручной работы + смешивать CJS + ESM.

Есть классный пропозал с defer import - https://github.com/tc39/proposal-defer-import-eval

Но проблема та же, что вручную надо определить, что нам требуется не сразу.

Плюс запустить это можно только на собранном через бандлер коде на данный момент - https://webpack.js.org/configuration/experiments/#experimentsdeferimport

Еще одна приятная оптимизация - замена require('date-fns') на require('date-fns/format'), минус 350ms - кажется бесполезный налог на жирный barrel файл - точку входа date-fns.

Следующий момент вдохновлен вебпаковским thread-loader, опишу сначала сам пайплайн dev сборки (трейс на вложенном изображении):
- наша cli запускает процессы сборки серверного и клиентского кода
- также она стартует воркер для фетча и запуска собранного server.js
- соответственно этот воркер простаивает зря все время пока собирается серверный код

Добавил на старте воркера прогрев самого тяжелого модуля - require('fastify') - итого минус 200ms на старт development сервера приложения.

Получаю большое удовольствие от такой работы, хоть теперь и не доверяю Chrome Devtools Performance как прежде :)