Как я уменьшил размер нашего пакета React с 40 МБ до менее 1 МБ
Недавно перед нашим инженерным отделом была поставлена задача добавить новые функции в наше приложение, что потребовало серьезного пересмотра всей нашей кодовой базы внешнего интерфейса. Хотя сами по себе функции не были очень сложными, объем технического долга в нашем коде не позволял нам легко их реализовать. В результате мы решили воспользоваться возможностью изменить архитектуру наших клиентских приложений, погасить большую часть нашего технического долга и реализовать эти важные функции таким образом, чтобы их было легко поддерживать в будущем. Конечный результат оказался лучше, чем ожидалось. Мы реализовали функции, которые стали важной частью значительного роста бизнеса, и в процессе этого мы уменьшили размер пакета нашего клиента React более чем на 90 процентов!
Так как же нам удалось уменьшить размер пакета настолько? Вот пять принципов, которые я применил, руководя интерфейсом во время этого проекта. Справедливости ради следует отметить, что наша первоначальная кодовая база была немного запутанной, с много возможностей для улучшения. Применение этих принципов обычно не приводит к 90-процентному уменьшению размера пакета, но определенно приводит к созданию более чистой, удобной в сопровождении и более производительной кодовой базы.
Удалить ненужные пакеты
Один из самых простых способов уменьшить размер пакета — удалить избыточные или неиспользуемые зависимости. Если вы проведете аудит того, какие пакеты вы фактически используете в своем приложении, вы можете быть удивлены, увидев, сколько пакетов никогда не используются или используются только в нескольких файлах. Когда дело доходит до уменьшения размера пакета, это самый простой плод.
В дополнение к проверке пакетов, которые никогда/редко не используются, определите, есть ли у вас какие-либо избыточные зависимости. Например, есть ли у вас несколько библиотек компонентов (MUI, Bootstrap и т. д.), когда вы действительно можете (и должны) обойтись одной? У вас есть несколько пакетов, которые используются для стилизации? Несколько пакетов, обрабатывающих сетевые запросы? Все эти избыточности складываются, и их наличие не приводит ни к чему, кроме как к увеличению размера пакета и ухудшению опыта разработчиков. Ни одна команда не решает использовать несколько пакетов для выполнения одной и той же задачи. Скорее, команда может принять решение перейти на другой пакет, но никогда полностью не переключиться. Выберите один пакет для использования и реорганизуйте весь код, в котором используются другие параметры. Когда вы закончите, удалите пакет (или, что еще лучше, удалите его сначала, чтобы у вас не было другого выбора, кроме как завершить рефакторинг). У вас останется более короткий список зависимостей, меньший размер пакета и более удобная кодовая база, с которой будет приятнее работать.
Удалить мертвый код
Удаление мертвого кода — это искусство. Может быть трудно найти то, что действительно мертво. Есть несколько инструментов, которые могут помочь в этом, например, неимпортировать, но я всегда изо всех сил пытаюсь использовать их по максимуму. Иногда самый простой способ узнать, используется ли файл, — это закомментировать его и посмотреть, не сломается ли что-нибудь! Если все хорошо, удалите файл. Вы будете удивлены, узнав, сколько мертвого кода вы можете удалить, просто делая это время от времени.
Скриншот выше взят из моего личного лучшего коммита. Я обнаружил целый каталог неиспользуемого кода после того, как очистил наш список зависимостей. Этот каталог был нужен только для одного лишнего пакета, и я смог его удалить, что привело к удалению более полумиллиона строк кода!
Дедупликация зависимостей
Одна хитрость, которой я недавно научился, заключалась в том, чтобы запускать npm dedupe в моем проекте после внесения любых изменений в зависимости. Это встроенная команда из npm, которая просматривает дерево зависимостей вашего проекта, как определено в файле package-lock.json, и ищет возможности для удаления повторяющихся пакетов. Например, если package A имеет зависимость package B, но package B также является зависимостью вашего проекта (и, следовательно, находится на верхнем уровне вашего node_modules), выполнение npm dedupe удалит package B как зависимость package A в вашем package-lock.json, поскольку package A уже будет иметь доступ к package B, когда он просматривает дерево.
Это, вероятно, не окажет существенного влияния на размер вашего пакета. Но какой-то эффект точно будет. Кроме того, почему бы не использовать встроенный инструмент из npm для упрощения и очистки вашего package-lock.json?
Используйте полезные пакеты и обновленные инструменты сборки
Вероятно, именно здесь мы увидели самое большое улучшение размера нашего пакета. Наше предыдущее внешнее приложение было построено с использованием пользовательской конфигурации веб-пакета с использованием версии веб-пакета, которая была на 2 основные версии ниже последней версии. Никто из нас в команде не был экспертом по веб-пакетам/DevOps, поэтому нам не нужно было пытаться поддерживать пользовательскую конфигурацию веб-пакета для нашего относительно простого приложения React. С переходом на новый create-react-app нам больше не нужно было беспокоиться о поддержке конфигурации веб-пакета. Кроме того, конфигурация в пакете react-scripts уже была оптимизирована для нашего варианта использования. Вместо того, чтобы быть героем, ищите пакеты, которые уже хорошо делают одну вещь. Используйте их, когда это уместно, особенно когда речь идет о сборке инструментов. Это означает меньше работы для вас, меньше кода для поддержки и часто более оптимизированный процесс сборки.
Используйте разделение кода
Честно говоря, это не уменьшит ваш общийразмер пакета. Но ленивая загрузка может привести к тому, что сборка будет гораздо более равномерно распределена между фрагментами сборки. Мы внедрили шаблон ленивой загрузки, который соответствовал нашей маршрутизации верхнего уровня на стороне клиента. Поскольку пользователи уже ожидают загрузки страниц при переходе на разные страницы, разделение сборки на фрагменты, соответствующие основным маршрутам в приложении, обеспечивает более равномерное распределение фрагментов сборки, не влияя на UX.
Заключение
Приведет ли применение этих 5 принципов к вашему приложению к уменьшению размера пакета на 90%, как это произошло в моем случае? Возможно нет. Но они определенно приведут к некоторому сокращению. И, по крайней мере, применение этих принципов поможет вашей команде получить хорошо поддерживаемую кодовую базу, с которой будет приятнее работать.
