Уменьшение размера пакета производственного приложения

Question

Уменьшение размера пакета производственного приложения

Я получил производственное приложение, размер пакета которого составляет 8,06 МБ.

# Console log from npm build
File sizes after gzip:

  1.67 MB    build/static/js/3.73cf59a2.chunk.js
  794.29 KB  build/typescript.worker.js
  131.13 KB  build/css.worker.js
  104.68 KB  build/html.worker.js
  104.02 KB  build/static/css/3.01bcafd3.chunk.css
  67.03 KB   build/static/js/main.6acf560d.chunk.js
  49.64 KB   build/json.worker.js
  25.12 KB   build/editor.worker.js
  7.99 KB    build/static/js/54.afc981d1.chunk.js
  ...

На сборке приложения и запуске source-map-explorer

npm run build
source-map-explorer 'build/static/js/*.js'

Я получаю предупреждение от build:

Размер пачки значительно больше рекомендованного.

Вы можете проверить исходную карту.

Я хотел бы уменьшить размер пакета, исходя из проведенного мною исследования:

Поиск альтернатив для больших библиотек.
- Создание "тонкой" версии библиотеки для моих нужд.
Импорт отдельных компонентов по запросу:

import Button from 'antd/es/button'; 
import { Button } from 'antd'; // Imports all library

Код расщепления.
Перемещение библиотек в devDependencies

У меня есть вопрос относительно:

Почему важно иметь маленький размер пакета?
Каков рекомендуемый размер пакета, почему?
Я понимаю, что разделение кода разбивает ваш код на различные пакеты, которые затем могут быть загружены по требованию или параллельно. Как это помогает в уменьшении размера пакета?
Как мне решить, должна ли библиотека быть частью devDependencies
Есть ли другие подходы?

11

javascript npm webpack-production

Источник

user7882470 18 авг '19 в 11:08

1 ответ

Решение

Другие вопросы по тегам javascript npm webpack-production

user1445636 18 авг '19 в 15:58 2019-08-18 15:58 · Accepted Answer · 2019-08-18 15:58

Почему важно иметь маленький размер пакета?

Потому что это сократит время, необходимое пользователям для загрузки вашего приложения / сайта, за счет уменьшения объема данных, которые они должны передавать. Это особенно важно для пользователей, использующих соединения с низкой пропускной способностью, в том числе нестабильные сотовые соединения.

Каков рекомендуемый размер пакета, почему?

Как можно меньше. Я не думаю, что здесь действительно можно дать точный ответ, так как каждое приложение отличается, но обычно вы хотите, чтобы ресурсы на "критическом" пути были как можно меньше, чтобы вы сократили начальное время загрузки, и затем загружайте больше ресурсов по мере необходимости на лету.

Я понимаю, что разделение кода разбивает ваш код на различные пакеты, которые затем могут быть загружены по требованию или параллельно. Как это помогает в уменьшении размера пакета?

Хотя это не может уменьшить общий размер пакета, оно может уменьшить объем данных, требуемых отдельным пользователем. Например, если вы используете только monaco-editor в определенной части вашего приложения может иметь смысл лениво загружать его только тогда, когда пользователь активирует эту функцию.

Как мне решить, должна ли библиотека быть частью devDependencies

devDependencies должны включать любые зависимости, которые требуются только при разработке проекта. Это будет включать в себя инструментарий (например: webpack, eslint, gulp) и тестовые среды (mocha, chai, sinon).

Однако это в большей степени относится к проектам на стороне сервера, поскольку истинные devDependencies не должны попадать в ваш связанный код, даже если вы по ошибке поместили их в раздел зависимостей.

Есть ли другие подходы?

В первую очередь вы должны сосредоточиться на дрожании дерева и разделении кода / отложенной загрузке.

Например, moment-timezone занимает почти 1 Мб - вам это действительно нужно? Для многих приложений достаточно просто работать в часовом поясе браузера и UTC, что не нужно moment-timezone

Для antd библиотека, убедившись, что все ваши импорты могут быть в виде дерева (например, импортировать отдельные компоненты, как в вашем примере), может значительно уменьшить размер импортируемого кода (другие библиотеки, такие как lodash, могут быть похожей историей, хотя, если у вас есть зависимости, которые не т использованный древовидный импорт все это будет включено в любом случае)

За vis а также monaco-editor подумайте, могут ли они быть загружены по требованию, а не всегда загружаться при запуске. Рассмотрим, если вам нужно codemirror также как и monaco-editor - с первого взгляда кажется, что они удовлетворяют аналогичным целям.

ссылка: https://webpack.js.org/guides/tree-shaking/
https://webpack.js.org/guides/lazy-loading/