Идем дальше. На скриншоте изображен итоговый пайплайн работы со статами. Чтобы получить HTML-отчет, статы проходят несколько стадий: - нормализация (Да, статоскоп умеет нормализовывать статы. До нормализации, статы весят 1.5гб, а после - 250мб. Подробнее описывал здесь) - сжатие с binary JSON - сжатие с gzip - пилим gzip-стрим на чанки (зачем это делать подбробно описывал тут) - энкодинг чанков в base64 (чтобы можно было хранить чанки с бинарными данными в HTML) - запись в файл Всё, отчет готов. Таков путь сырых статов в 1.5гб до HTML-отчета в 5мб (и это несмотря на то, что base64 дает оверхед в ~33% от размера декодируемых данных). Когда мы открываем такой отчет в браузере, все происходит в отбратном порядке: - декодируем чанки из base64 - разжимаем из gzip - разжимаем binary JSON - денормализуем статы - отправляем статы в UI Итого, самая медленная часть статоскопа - это денормализация статов и их подготовка к использованию в UI. А все потому, что webpack генерит статы, не особо заворачиваясь с форматом. И тут мы плавно переходим к Statoscope 6, над которым я работаю уже довольно давно, с переменной активностью. Вот его основные фичи: - собственный формат статов - расширяемость как у vscode 😇 Зачем: чтобы любой человек мог написать плагин (если его еще нет), в котором реализован UI для его любимого сборщика. Сейчас же статоскоп сильно завязан на webpack и мне это не нравится. Будет классно, если напишете какая у вас разница в размерах статов получилась, очень интересно. PS: Я тут заглянул в OpenCollective статоскопа и выяснилось, что там уже 413$ накапало. Это конечно не webpack с миллионным бюджетом, но все равно приятно ☺️