Как увлеченный программист, я всегда ищу возможности оптимизировать свою кодовую базу с последующим дополнительным исследованием и обучением. Недавно у меня была возможность поработать над существующим проектом angular, работать над которым было довольно интересно. В качестве первого шага я просмотрел кодовую базу и все функции, связанные с клиентским приложением.
Я обнаружил, что это довольно старый проект, основанный на angular 7, и кодовая база была беспорядочной, поскольку все компоненты загружались напрямую в модуль приложения. Кодовая база вообще не была модульной.
Изначально меня беспокоило количество времени, которое уйдет на его оптимизацию в одиночку. В то же время я начал исследовать шаги, которым я мог бы следовать, чтобы оптимизировать его очень грамотно.
Я сосредоточился на следующих моментах, чтобы оптимизировать его.
- Узнайте, какая библиотека отвечает за большой размер блока
- Модуляризуйте беспорядочную кодовую базу за очень ограниченное время, основываясь на пункте 1.
- Ленивая загрузка необходимых модулей
- Используйте механизм сжатия, чтобы уменьшить размер блока.
1. Узнайте, какая библиотека отвечает за большой размер блока.
Я наткнулся на инструмент анализатор пакетов веб-пакетов, с помощью которого мы можем эффективно измерять размеры пакетов. Основываясь на размере пакета js-фрагментов, мы сможем решить, что библиотека должна выйти из основного пакета, который отвечает за начальное долгое время загрузки страницы.
Я установил его с помощью следующей команды.
npm i -g webpack-bundle-analyzer
Затем я создал производственную сборку с именованными фрагментами для создания stats.json с помощью следующей команды.
npm run build —-prod --named-chunks --stats-json
Затем я запустил анализатор пакетов веб-пакетов, используя следующую команду.
webpack-bundle-analyzer dist/*name-of-project*/stats.json
Теперь анализатор пакетов webpack открывает новую веб-страницу в другом порту, которая показывает обзор размеров пакетов, связанных с существующим приложением angular.
В приведенном ниже сравнении показан основной пакет с тремя типами размеров.
Статический размер - размер файла пакета до сжатия
Разобранный размер - размер файл пакета после компиляции
Размер Gzip - Размер файла пакета после сжатия с помощью gzip
Ниже вы можете увидеть тяжелые библиотеки, которые загружаются во время запуска приложения и замедляют загрузку приложения.
Из приведенной выше визуализации подтверждается, что библиотека devextreme является самой большой библиотекой, которая имеет больший размер пакета и замедляет загрузку страницы при запуске.
Кроме того, pdf.js кажется ненужной библиотекой, которая загружается на странице входа в систему. Ух ты, теперь это облегчило мою работу по выбору модулей, которые нужно загружать лениво. Следующим шагом является перемещение библиотеки devextreme из основного пакета, чтобы значительно уменьшить размер основного пакета.
2. Модуляризация запутанной кодовой базы.
Я проверил различные компоненты в существующей кодовой базе и, основываясь на функциях, создал несколько модулей и соответственно связал компоненты. Это то, что все делают в качестве шага по оптимизации кодовой базы, чтобы сделать ее более масштабируемой и удобной в обслуживании.
3. Ленивая загрузка необходимых модулей
Я искал в кодовой базе импорт, связанный с пакетом «devextreme», и обнаружил, что он загружается на определенную страницу отчетов после того, как пользователь успешно вошел в систему.
Я создал новый модуль, который лениво загружается сразу после входа пользователя в систему и выводит пользователя на панель управления. Это приводит к удалению ненужных пакетов при запуске приложения.
Затем создал другой модуль из только что созданного функционального модуля панели инструментов, чтобы лениво загружать его, когда пользователь посещает раздел отчетов на панели инструментов.
Это связано с тем, что пакет devextreme импортируется в этот раздел, и он загрузка занимает много времени из-за большого размера блока.
Затем я запустил инструмент анализатора пакетов веб-пакетов , чтобы сравнить размеры пакетов до и после ленивой загрузки.
Здесь вы можете видеть, что файл main-main-module.js берет на себя всю нагрузку и делает файл main.js легким, который будет загружен во время запуска.
Его размер был уменьшен с 4,76 МБ до 768 КБ.
4. Используйте механизм сжатия, чтобы уменьшить размер блока.
В рамках дальнейших исследований я наткнулся на сжатие gzip, которое может уменьшить размер пакета до 30%.
Я установил инструмент gzipper, используя следующую команду.
npm i gzipper -g
Я добавил следующую модификацию в раздел «скрипты» package.json.
“build:prod”: “ng build — prod && gzipper compress ./dist/**Project Name **”
Затем я выполнил приведенную ниже команду, чтобы создать производственную сборку вместе с gzip-версией всех файлов js в целевой папке.
npm run build:prod
Теперь я снова запустил команду анализатора пакетов webpack и получил следующие идеи.
Окончательный размер основного пакета становится 193 КБ с 768 КБ после сжатия gzip. ПРЕВОСХОДНО!
Заключение:
В этой статье мы выяснили, как уменьшение размера пакета имеет решающее значение для производительности и как это корень всех зол. Мы также изучили такие инструменты, как анализатор пакетов Webpack, gzipper и механизм отложенной загрузки, вместе взятые могут создать волшебство, которое приводит к удалению ненужного кода из основного пакета.
Спасибо, что прочитали эту статью. Если у вас есть вопросы, пожалуйста, оставьте комментарии ниже. Вы можете связаться со мной через Linkedin или Twitter.
