Покладіть свій додаток на дієту за допомогою набірного візуалізатора Meteor 1.5

Беручи Vulcan з 4,2 МБ до 1,98 МБ

Meteor 1.5 щойно вийшов, і великою, блискучою, новою функцією є динамічне імпортування.

свій

Але поряд із цією функцією поставляється і справді крутий інструмент: візуалізатор набору:

Це показує на графіку, які саме пакети Meteor та NPM займають найбільше місця у вашому наборі.

Щоб використовувати його, просто оновіть свій додаток до Meteor 1.5, додайте до нього пакет візуалізатора пакета, а потім запустіть додаток у виробничому режимі (meteor --production).

Візуалізатор може відкрити деякі дивовижні факти, як це було, коли я використовував його на Vulcan!

Я занадто довго відкладав фокус на розмірі пачки, і це показало! Пакет отримав величезні 4,2 ​​МБ без gzip:

Якщо ви подивитесь на помаранчеву смужку (другу від центру), ви побачите, що є один довгий суцільний сегмент, а потім він розпадається на менші шматки. Цей безперервний сегмент відповідає пакетам NPM програми (іншими словами, страшній папці node_modules), які різко переважають фактичний код Метеора (маленькі шматки).

Ось розбивка найбільших винуватців:

  • міжнародний: 935кб
  • response-intl: 341кб
  • intl-relativeformat: 331kb
  • реакція-dom: 181кб
  • graphql: 171кб
  • реакція-завантажувальний ремінь: 161 кб
  • кермо: 75,8 кб
  • core-js: 75,2 кб
  • лодаш: 72,8кб
  • еліптична: 72,5 кб
  • apollo-клієнт: 64kb
  • crypto-js: 56кб
  • intl-messageformat: 55.1kb
  • момент: 49кб
  • проста схема: 39кб

Як бачите, найбільшим шматочком на сьогоднішній день були пакети інтернаціоналізації, загалом 1,6 МБ! Іншими словами, 40% розміру пакета було зайнято функцією, яка більшості людей може бути не завжди потрібна.

Зараз я не хотів просто взагалі викинути інтернаціоналізацію. І я також не хотів змушувати людей переробляти весь свій код, щоб позбутися викликів API-інтерфейсів response-intl.

Тож я знайшов хорошу золоту середину: я створив новий спрощений пакет vulcan: i18n, який використовує ті ж самі API, що і response-intl, але включає лише найпоширеніші функції (і жодну із залежностей!).

Просто замініть будь-який імпорт з реакцією intl вулканом: i18n імпортує, і все готово! І якщо вам потрібна вся потужність реагування-intl, створення власної копії vulcan: i18n, що реекспорт реакції-intl не повинен бути занадто важким:

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

Результат: 1,6 Мб збережено!

Спускаючись по списку (вірніше, по колу), ще одним великим джерелом мертвої ваги став response-bootstrap.

Наскільки корисною є ця бібліотека, я використовував лише незначну частину компонентів, які вона надає. Я думав про те, щоб взагалі від цього позбутися, але це означало б, що потрібно кодувати власні випадаючі меню, модалі тощо. Не весело!

Натомість я знайшов набагато простіший виправлення. Виявляється, існує велика різниця між:

Перший імпортує весь вміст упаковки, тоді як другий - лише імпортувати компонент Foo та його залежності!

Я перетворив увесь свій імпорт на другий синтаксис, і результати говорять самі за себе:

Одне, що візуалізатор не повідомляє вам, - це звідки береться залежність. Наприклад, я виявив, що кермо якось комплектується на клієнті, але не міг сказати, який пакет NPM вимагає цього.

Виявляється, існує проста команда, яка дозволяє вам знати саме це:

Результат сказав мені, що кермо - це залежність простої схеми, і оскільки я майже впевнений, що це насправді не потрібно, я з нетерпінням чекаю на те, щоб видалити ще пару КБ з мого розміру пакета, який буде видалено:

Після всіх цих оптимізацій та іншого, мені вдалося зменшити розмір пакета до 1,98 МБ, іншими словами менше 50% того, з чого я почав!

Найцікавіша частина: мені навіть не доводилось використовувати динамічний імпорт, щоб отримати ці результати. Я з нетерпінням чекаю на їх реалізацію та отримання ще кращих прибутків (або збитків, мабуть?), Але я залишу це для іншого повідомлення.