chunk vendors что это
Еще один способ использования Webpack 4 и разделение кода
Ни для кого не секрет, что с выходом Webpack 4 стратегия разделения кода сильно поменялась. Тут даже лучше сказать, что она была заново придумана, т.к. старый подход просто перестал работать, а новый не понятно как использовать.
Для тех, кто все еще не в курсе, плагина webpack.optimize.CommonsChunkPlugin больше нет. Совсем. Вместо этого предлагается в конфиге писать следующее:
Это должно работать как магия. Т.е. теперь не мы говорим webpack’у что сделать общим чанком, а он сам все сделает, да еще может даже и лучше нас.
И наступит счастье. Шутка. На самом деле нет.
Базовые приготовления
Вот пример из документации:
Результатом сборки будут 3 файла: another.bundle.js, index.bundle.js, vendors
Теперь, для того, чтобы запустить наши веб приложения, мы, в одном случае, должны подключить vendors
index.bundle.js и index.bundle.js, а во втором vendors
index.bundle.js и another.bundle.js.
В чем проблема?
Проблема в имени vendors
index.bundle.js. Пока у нас меньше трех точек входа, ничего страшного не происходит. Здесь все кажется логичным — бандл содержит npm модули (они же vendors) и общие модули для index и another. На каждую из страниц мы подключаем 2 файла и не имеем проблем.
Однако если у нас три и более точки входа, то новых бандлов (они же чанки) может быть куда больше и мы уже не знаем ни их количества, ни имен. Все становится еще веселее, если мы еще и css извлекаем в отдельные файлы. И это проблема.
Как решить эту проблему?
После завершения работы webpack у нас нет никаких файлов, которые содержали бы в себе информацию о том, какие именно бандлы на той или иной странице надо подключать. И в какой последовательности.
Однако в output’е мы можем найти вот такие строки:
На самом деле это почти то, что нам надо. Т.е. webpack прекрасно знает какие бандлы нужны для каждой точки входа, но почему-то сам не хочет этой информацией с нами делиться.
Манифест нам здесь не помогает. Да, мы знаем что такой (vendors
index.bundle.js) бандл есть. Мы знаем где он лежит. Но кому он нужен не знаем. Т.е. манифест бесполезен.
Тогда я решил что раз webpack знает нужную информацию, то ее возможно получится достать с помощью плагинов. Готовых я не нашел и решил написать свой. И, только ради демонстрации этого плагина, я и пишу эту статью.
В файле webpack.config.(ts|js) добавим новый плагин:
и дождемся результата. Результатом будет файл entrypoints.json с вот таким содержанием:
Если используется extract-css, то кроме секции js будет еще и css.
Оптимизация производительности приложения Vue.js: часть 2 — Отложенная загрузка маршрутов и анти-паттерн использования vendors.js.
В предыдущей статье мы узнали, что такое разбиение кода, как оно работает с Webpack и как его использовать с отложенной загрузкой в приложении Vue. Теперь мы немного углубимся в код и изучим наиболее полезные шаблоны для разбиения кода в приложениях Vue.js.
Часть 4 — Отложенная загрузка библиотек
Часть 5 — Использования кеша Service Worker
Часть 6 — Предзагрузка
Проблема с большими приложениями
Vue-router — это библиотека, которая позволяет разделить веб-приложение на отдельные страницы. Каждая страница представляет собой маршрут, связанный с определенным URL
Зная это, представьте, что у нас есть простое приложение для портфолио со следующей структурой:
Как вы, вероятно, заметили, в зависимости от того, какой маршрут мы посещаем, нам может не понадобиться ни Home.vue, ни About.vue (у которой есть зависимость от lodash). Но тем не менее оба они будут находиться в одном пакете app.js и будут загружаться независимо от того, какой у пользователя будет маршрут посещения. Какая трата времени на загрузку страницы!
Это не имеет большого значения, если у вас маленькое приложение, но представьте, что приложение будет становится все больше и больше, и любое новое дополнение будет означать загрузку большего пакета при первом посещении.
Это недопустимо, когда пользователю достаточно всего 2 — 5 секунд ожидания загрузки что бы покинуть ваш веб-сайт!
Разделение кода на основе маршрутов с помощью vue-router
Чтобы не ухудшать наше приложение при наращивание функционала, нам просто нужно создать отдельные пакеты для каждого маршрута, используя синтаксис динамического импорта, который мы изучили в предыдущей статье.
Как и все остальное в Vue.js — это чрезвычайно просто. Вместо того, чтобы импортировать компоненты непосредственно в объекты маршрута, нам просто нужно передать туда динамическую функцию импорта. Компонент маршрута будет загружен ТОЛЬКО после задействование данного маршрута.
Таким образом, вместо обычного статического импорта компонента маршрута:
Нам нужно импортировать его динамически, что создаст новый пакет с этим маршрутом в качестве точки входа:
Давайте посмотрим, как теперь будут выглядеть наши пакеты и маршрутизация с динамическим импортом:
С помощью этой настройки webpack создаст три пакета:
*Имена пакетов не являются такими которые сгенерирует webpack. Имена выбраны такими только для облегчения понимания. Webapck генерирует что-то вроде 0.js 1.js и т. д. В зависимости от конфигурации вашего веб-пакета.
Разделение кода на основе маршрутов во многих случаях может решить все проблемы связанные с производительностью и может быть применено практически к любому приложению менее чем за несколько минут!
Разделение кода в экосистеме Vue
Возможно вы, используете Nuxt или vue-cli для создания своего приложения. Если это так, важно знать, что у них есть свои нюансы поведение в отношении разделения кода:
Теперь давайте взглянем на очень популярный и часто используемый анти-шаблон, который может сделать воздействие разделения кода на основе маршрутов менее полезным.
Анти-шаблон использования пакета vendor.js
Пакет vendor.js обычно используется в виде отдельного js-файла, содержащего все модули из node_modules.
Хотя может показаться заманчивым поместить все зависимые библиотеки в один файл, чтобы иметь возможность кэшировать их, этот подход представляет ту же проблему, что при объединении всех маршрутов:
Видно проблему? Даже если нам нужен lodash (который является одной из зависимостей) только в одном маршруте, он включен в vendor.js вместе со всеми другими зависимостями, и поэтому он всегда будет загружен.
Объединение всех зависимостей в одном файле звучит заманчиво, но это увеличивает время загрузки приложения.
Для того чтобы быть уверенным в том, что будет загружен только необходимый код, можно разделить зависимости по модулям на основе маршрутов. Но это приведет к некоторому дублированию кода.
Предположим, Home.vue также нуждается в lodash.
В этом случае переход от /about (About.vue) к / (Home.vue) приведет к загрузке lodash дважды.
Это все же лучше, чем загружать тонны избыточного кода, но если у нас уже есть эта зависимость, бессмысленно ее не использовать, верно?
В свойстве chunks мы просто сообщаем webpack, какие куски кода следует оптимизировать. Установка этого свойства для всех, как вы, вероятно, догадались, означает, что оно должно оптимизировать их все.
Вы можете прочитать больше об этом процессе в документации по Webpack.
Заключение
Разделение кода по маршрутам — один из лучших (и самых простых) способов сохранять размер первоночально загружаемого пакета небольшим. В следующей части мы узнаем обо всех других частях (хранилищах Vuex и отдельных компонентах), которые можно отделить от основного пакета и загружать отложено.
Русские Блоги
vue 【vue-cli3】 Оптимизация проекта
Глоссарий
Недостатки Время загрузки первого экрана очень велико. SEO не дружелюбен. В основном потому, что SPA использует хеш-фрагменты для реализации маршрутизации, а хеш-фрагменты не отправляются на сервер как часть HTTP-запроса. Целью использования хеш-фрагментов в SPA является: ** При изменении содержимого фрагмента браузер не будет инициировать новый сетевой запрос, как при изменении URI. ** Таким образом, вы можете запрашивать только данные, необходимые для рендеринга страницы или представления, вместо получения и анализа всего документа для каждой страницы.
статус-кво
И соответствующий дистрибутив основного файла:
Оптимизация скорости загрузки первого экрана
1 Уменьшите количество запросов
Настройте асинхронную загрузку всех маршрутов. Он просто разделяет подфункции и загружает их при вызове. Но это не уменьшит общий размер. Измените синхронную загрузку на асинхронную. В маршрутизации написано: component: () => import (‘../ components / dynamic / secondaryMarket / secondaryMarket.vue’),
2 Удаление правил предварительной выборки и предварительной загрузки
Сначала разберитесь с предварительной выборкой и предварительной загрузкой
Этот код сообщает браузеру, что этот ресурс будет использоваться в определенной навигации или функции в будущем, но вес порядка загрузки этого ресурса относительно невелик. Другими словами, предварительная выборка обычно используется для ускорения следующей навигации, но не в этот раз. Ресурсы, помеченные как предварительная выборка, будут загружены браузером во время простоя.
Предварительная загрузка обычно используется для ключевых ресурсов, которые будут использоваться на этой странице, включая ключевые js, шрифты и файлы css. Предварительная загрузка увеличит порядок загрузки ресурсов, так что ключевые данные можно будет загрузить заранее и оптимизировать скорость открытия страницы. Закрыть предварительную выборку
Тест: общая скорость загрузки первого экрана среды разработки составляет около 10,6 с. Отправьте 102 запроса. Среди них: максимальное время загрузки chunk-vendors.xxx.js достигло 7,71 с;
3 Разделение больших файлов
Слишком много ссылок на Jquery.js, и невозможно очистить Core.js один раз. Я не знаю, почему я его загрузил. Удалить. Вместо этого Vue-cookie использует собственную инкапсулированную функцию. Element-ui слишком велик. Цитата по запросу. Файл Element-ui-common.js слишком велик.
Общая скорость загрузки первого экрана среды разработки составляет около 9,9 с. Отправьте 102 запроса. Среди них: время загрузки chunk-vendors.js составляет до 6,91 с; эффект оптимизации этого шага не очень удовлетворительный, потому что даже если конфигурация element-ui будет разобрана, она принесет element-ui-common. js, этот файл слишком велик. Остальные пропорции не очень очевидны. Ссылка на JQuery изменила слишком много кода, и нет возможности быстро его удалить.
Установите и используйте компонент Compression-webpack-plugin. Добавлен в файл конфигурации webpack для сжатия данных размером более 10 КБ.
Затем выполните npm run build
Загрузка статических ресурсов на первом экране среды разработки занимает около 3,2 секунды. Отправьте 102 запроса. Среди них: время загрузки chunk-vendors.js до 2,63 с; эффект значительный
Ввиду неудовлетворительной оптимизации предыдущего шага 3, есть оптимизация шага 5. Мы будем ссылаться на большие компоненты, в основном vue element-ui и echart, jquery. Включите запрос ресурсов на CDN. Вместо того, чтобы упаковать его в нашу сумку. Установить в index.html
Задайте стратегию настройки configureWebpack в файле конфигурации webpack
Время загрузки статических ресурсов на первом экране среды разработки составляет около 1,89 с. Отправьте 102 запроса. Среди них: время загрузки chunk-vendors.js до 0,49 с, эффект значительный, здесь тест использует ресурсы cdn.bootcss.com. Также протестируйте некоторые другие бесплатные ресурсы узла CDN. Примечание. Бесплатная CDN может потерпеть крах. Здесь можно рассмотреть самостоятельно построенные или коммерческие узлы CDN.
Объем сборки и эффективность анализа
1 динамический полифилл
2 Современный режим
С Babel мы можем учесть все новейшие языковые функции ES6 и 7, но это также означает, что нам нужно доставлять транспилированные и полифилированные пакеты для поддержки старых браузеров. Эти переведенные пакеты обычно более подробны и медленнее, чем исходный код ES6 и ES7. Большинство современных браузеров теперь поддерживают встроенные функции ES6,7. Vue-cli на самом деле предоставляет современный режим, который, по сути, загружает полифиллы по условию и проверяет их поддержку во время выполнения.
Поиск правильного способа разделения материалов сайтов с помощью Webpack
Поиск наилучшего способа организации материалов веб-проектов может оказаться непростой задачей. Существует множество различных сценариев работы пользователей с проектами, множество технологий и других факторов, которые нужно принимать во внимание.
Автор материала, перевод которого мы сегодня публикуем, говорит, что хочет рассказать здесь обо всём, что нужно знать для грамотной подготовки материалов веб-проектов к работе. Во-первых, речь пойдёт о том, как подобрать такую стратегию разделения файлов сайта, которая наилучшим образом подойдёт для конкретного проекта и для его пользователей. Во-вторых — будут рассмотрены средства реализации выбранной стратегии.
Общие сведения
В соответствии с глоссарием Webpack, существуют две стратегии разделения файлов. Это — разделение бандла (bundle splitting) и разделение кода (code splitting). Эти термины могут показаться взаимозаменяемыми, но таковыми они не являются.
Однако мне хотелось бы сказать, что для многих сайтов гораздо более ценным оказывается именно первая стратегия — разделение бандлов. И, пожалуй, от её внедрения способны выиграть буквально все веб-проекты.
Поговорим об этом подробнее.
Разделение бандлов
В основе методики разделения бандлов лежит весьма простая идея. Если у вас имеется один огромный файл и вы меняете в нём одну единственную строчку кода, постоянному пользователю придётся, при очередном посещении сайта, загрузить весь этот файл. Однако если разделить этот файл на два файла, тогда такому же пользователю нужно будет загрузить лишь тот из них, в который внесены изменения, а второй файл будет взят из браузерного кэша.
Стоит отметить, что так как оптимизация материалов сайта путём разделения бандлов завязана на кэшировании, пользователям, посещающим сайт впервые, в любом случае, придётся загружать все материалы, поэтому для них нет разницы — будут ли эти материалы представлены в виде одного файла или в виде нескольких.
Мне кажется, что слишком много разговоров о производительности веб-проектов посвящено пользователям, которые посещают сайт впервые. Возможно, это так, отчасти, из-за важности первого впечатления, которое проект произведёт на пользователя, а также от того, что объёмы данных, передаваемые пользователям при первом посещении сайта, просто и удобно измерять.
Когда же дело доходит до регулярных посетителей, может оказаться сложным измерить воздействие на них применяемых техник оптимизации материалов. Но мы просто обязаны знать о том, к каким последствиям приводят подобные оптимизации.
Для анализа таких вещей потребуется нечто вроде электронной таблицы. Также нужно будет сформировать строгий перечень условий, в которых мы можем протестировать каждую из исследуемых стратегий кэширования.
Вот сценарий, подходящий под общее описание, данное в предыдущем абзаце:
▍Исходные условия
В соответствии с вышеописанным сценарием, когда мы, каждую неделю, вносим в код сайта какие-то изменения, строка contenthash пакета меняется. В результате, посещая еженедельно наш сайт, Алиса вынуждена загружать новый файл размером 400 Кб.
Если сделать симпатичную табличку (с бесполезной пока строкой итогов), содержащую данные о еженедельном объёме загрузки данных, приходящихся на этот файл, то у нас получится следующее.
Объём данных, загруженных пользователем
В результате оказывается, что пользователь, за 10 недель, загрузил 4.12 Мб кода. Этот показатель можно улучшить.
▍Отделение пакетов сторонних разработчиков от основного кода
Webpack 4 старается максимально облегчить жизнь разработчику, поэтому он делает всё, что может, и при этом не требует, чтобы ему сообщали о том, как именно нужно разбивать бандлы на части.
Такое вот автоматическое поведение программы приводит к немногочисленным восторгам, вроде: «Ну что за прелесть этот Webpack», и к множеству вопросов в духе: «А что это тут делается с моими бандлами?».
В любом случае, добавление в конфигурацию конструкции optimization.splitChunks.chunks = ‘all’ сообщает Webpack о том, что нам надо, чтобы он взял всё из node_modules и поместил бы это в файл vendors
После того, как мы провели такое вот базовое разделение бандла, Алиса, регулярно посещающая наш сайт еженедельно, будет загружать при каждом визите файл main.js размером 200 Кб. А вот файл vendor.js она загрузит лишь три раза. Произойдёт это во время визитов в первую, пятую и восьмую недели. Вот соответствующая таблица, в которой, волею судьбы, размеры файлов main.js и vendor.js в первые четыре недели совпадают и равняются 200 Кб.
Объём данных, загруженных пользователем
В результате получается, что объём загруженных пользователем за 10 недель данных составил 2.64 Мб. То есть, в сравнении с тем, что было до разделения бандла, объём уменьшился на 36%. Не такой уж и плохой результат, достигнутый добавлением нескольких строк в конфигурационный файл. Кстати, прежде чем читать дальше — сделайте то же самое в своём проекте. А если вам надо обновиться с Webpack 3 на 4 — делайте это и не беспокойтесь, так как процесс это довольно простой и всё ещё бесплатный.
Мне кажется, что рассматриваемое тут улучшение выглядит несколько абстрактно, так как оно растянуто на 10 недель. Однако если считать объём данных, отправленных лояльному пользователю, то это честное сокращение этого объёма на 36%. Это очень хороший результат, но его можно улучшить.
▍Выделение пакетов в отдельные файлы
В документации можно найти отличное разъяснение использованных здесь конструкций, но я, всё же, посвящу немного времени рассказу о некоторых вещах, так как для того, чтобы правильно ими воспользоваться, у меня ушло немало времени.
Ниже показана новая версия таблицы со сведениями об объёмах еженедельных загрузок данных. По странному стечению обстоятельств размер каждого файла с npm-пакетами составляет 20 Кб.
Объём данных, загруженных пользователем
Теперь объём загруженных за 10 недель данных составляет 2.24 Мб. Это значит, что мы улучшили базовый показатель на 44%. Результат это уже весьма приличный, но тут возникает вопрос о том, можно ли сделать так, чтобы добиться результата, превышающего 50%. Если подобное получится — это будет просто здорово.
▍Разбиение кода приложения на фрагменты
Выше я говорил о том, что на нашем сайте имеется два самостоятельных раздела. Первый — это список товаров, второй — страница с подробными сведениями о товаре. Размер кода, уникального для каждого из них, составляет 25 Кб (а 150 Кб кода применяется и там и там).
Страница со сведениями о товаре не подвергается изменениям, так как мы уже довели её до совершенства. Поэтому, если мы выделим её код в отдельный файл, этот файл, большую часть времени работы с сайтом, будет загружаться в браузер из кэша.
Кроме того, как оказалось, у нас имеется огромный встроенный SVG-файл, используемый для рендеринга значков, который весит целых 25 Кб и изменяется редко.
С этим надо что-то делать.
Мы вручную создали несколько входных точек, сообщая Webpack о том, что ему нужно создать отдельный файл для каждой из этих сущностей.
То, что мы только что сделали, позволит Алисе экономить почти каждую неделю по 50 Кб трафика. Обратите внимание на то, что файл с описанием значков мы отредактировали на шестой неделе. Вот наша традиционная таблица.
Объём данных, загруженных пользователем
Теперь за десять недель загружено всего 1.815 Мб данных. Это означает, что экономия трафика составила впечатляющие 56%. В соответствии с нашим теоретическим сценарием постоянный пользователь всегда будет работать с таким уровнем экономии.
Всё это сделано за счёт изменений, внесённых в конфигурацию Webpack. Код приложений мы для достижения таких результатов не меняли.
Выше я говорил о том, что конкретный сценарий, по которому проводится подобный тест, на самом деле, особой роли не играет. Сказано это из-за того, что, вне зависимости от используемого сценария, вывод из всего, о чём мы говорили, будет одним и тем же: разбиение приложения на небольшие файлы, имеющие смысл в применении к его архитектуре, позволяет снизить объёмы данных сайта, загружаемых его постоянными пользователями.
Совсем скоро мы перейдём к разговору о разделении кода, но сначала мне бы хотелось ответить на три вопроса, над которыми вы, наверняка, сейчас размышляете.
▍Вопрос №1. Разве необходимость выполнения множества запросов не вредит скорости загрузки сайта?
На этот вопрос можно дать простой короткий ответ: «Нет, не вредит». Подобная ситуация выливалась в проблему в былые времена, когда в ходу был протокол HTTP/1.1, а при использовании HTTP/2 это уже неактуально.
Хотя, надо отметить, что в этом материале, опубликованном в 2016 году, и в этой статье Khan Academy 2015 года делаются выводы о том, что даже при использовании HTTP/2, использование слишком большого количества файлов замедляет загрузку. Но в обоих этих материалах «слишком большое количество» означает «несколько сотен». Поэтому стоит помнить о том, что если вам приходится работать с сотнями файлов, на скорость их загрузки могут повлиять ограничения на параллельную обработку данных.
Если интересно, поддержка HTTP/2 имеется в IE 11 в Windows 10. Кроме того, я проводил всестороннее исследование среди тех, кто пользуется более старыми системами. Они единодушно заявили, что их скорость загрузки веб-сайтов особенно не заботит.
▍Вопрос №2. В Webpack-бандлах есть вспомогательный код. Создаёт ли он дополнительную нагрузку на систему?
▍Вопрос №3. При работе с множеством маленьких файлов ухудшается уровень их сжатия, не так ли?
Да, это тоже так. На самом деле, мне хотелось бы сказать вот что:
Только что я провёл испытание, в ходе которого код из файла размером 190 Кб был разбит на 19 частей. Это добавило примерно 2% к объёму данных, отправляемых в браузер.
В итоге получается, что при первом посещении сайта пользователь загрузит на 2% больше данных, а при последующих — на 60% меньше, и продолжаться это будет очень и очень долго.
Так стоит ли об этом беспокоиться? Нет, не стоит.
Когда я проводил сравнение системы, использующей 1 файл, и системы с 19 файлами, я испытал её с использованием различных протоколов, в том числе и HTTP/1.1. Нижеприведённая таблица очень сильно поддерживает идею о том, что больше файлов — значит лучше.
Данные о работе с 2 версиями сайта, размещённого на статическом хостинге Firebase, код которого имеет размеры 190 Кб, но, в первом случае, упакован в 1 файл, а во втором — разбит на 19
При работе в 3G и 4G-сетях на загрузку варианта сайта с 19 файлами ушло на 30% меньше времени, чем на загрузку сайта с одним файлом.
В данных, представленных в таблице, много шума. Например, один сеанс загрузки сайта по 4G (Run 2 в таблице) занял 646 мс, ещё один (Run 4) — 1116 мс, что на 73% дольше. Поэтому возникает ощущение, что говорить о том, что HTTP/2 «на 30% быстрее» — это несколько нечестно.
Я создал эту таблицу для того, чтобы посмотреть, что даёт использование HTTP/2. Но, на самом деле, единственное, что тут можно сказать, заключается в том, что применение HTTP/2, вероятно, не особо заметно влияет на загрузку страниц.
Настоящим сюрпризом стали две последних строчки в этой таблице. Тут представлены результаты для не самой новой версии Windows с IE11 и HTTP/1.1. Я, если бы заранее пытался предсказать результаты испытания, точно сказал бы, что такая конфигурация будет загружать материалы гораздо медленнее других. Правда, тут использовалось очень быстрое сетевое подключение, и мне, для подобных испытаний, вероятно, стоит пользоваться чем-то более медленным.
А теперь расскажу вам одну историю. Я, чтобы исследовать мой сайт на совсем уж древней системе, загрузил виртуальную машину Windows 7 с сайта Microsoft. Там был установлен IE8, который я решил обновить до IE9. Для этого я пошёл на страницу Microsoft, предназначенную для загрузки IE 9. Но сделать этого мне не удалось.
Кстати, если говорить об HTTP/2, хочется отметить, что этот протокол интегрирован в Node.js. Если вы хотите поэкспериментировать — можете воспользоваться написанным мной небольшим HTTP/2 сервером с поддержкой кэша ответов, gzip и brotli.
Пожалуй, о методике разделения бандлов я сказал всё, что хотел. Думаю, что единственный минус такого подхода, при использовании которого пользователям приходится загружать очень много файлов, на самом деле, не является таким уж «минусом».
Теперь поговорим о разделении кода.
Разделение кода
Основная идея методики разделения кода звучит так: «Не загружайте ненужный код». Мне говорили, что использование этого подхода имеет смысл лишь для некоторых сайтов.
Я предпочитаю, когда речь идёт о разделении кода, использовать правило 20/20, которое я только что сформулировал. Если есть какая-то часть сайта, которую посещают лишь 20% пользователей, и её функционал обеспечивают более 20% JavaScript-кода сайта, тогда этот код нужно загружать только по запросу.
Это, конечно, не абсолютные цифры, их можно подстроить под конкретную ситуацию, и в реальности существуют гораздо более сложные сценарии, чем вышеописанный. Самое важное тут заключается в балансе, и совершенно нормально совсем не пользоваться разделением кода, если для вашего сайта это не имеет смысла.
▍Разделять или нет?
Как найти ответ на вопрос о том, нужно вам разделение кода или нет? Предположим, у вас имеется интернет-магазин, и вы размышляете о том, надо ли отделить от остального кода тот код, который используется для приёма оплаты от покупателей, так как лишь 30% посетителей у вас что-то покупают.
Что тут сказать? Во-первых — вам стоило бы поработать над наполнением магазина и продавать что-то такое, что окажется интересным большему количеству посетителей сайта. Во-вторых — нужно понять то, какой объём кода совершенно уникален для того раздела сайта, где принимается оплата. Так как перед «разделением кода» следует всегда выполнять «разделение бандла», и вы, надеюсь, так и делаете, то вы, вероятно, уже знаете о том, какие размеры имеет интересующий нас код.
Возможно, этот код может оказаться меньше, чем вы думаете, поэтому, прежде чем радоваться новой возможности оптимизации сайта, стоит всё спокойно посчитать. Если у вас, например, имеется React-сайт, тогда хранилище, редьюсеры, система маршрутизации, действия, будут совместно использоваться всеми частями сайта. Уникальный для разных частей сайта код будет, в основном, представлен компонентами и вспомогательными функциями для них.
Итак, вы выяснили, что совершенно уникальный код раздела сайта, используемого для оплаты покупок, занимает 7 Кб. Размер остального кода сайта — 300 Кб. В подобной ситуации я не стал бы заниматься разделением кода по нескольким причинам:
А теперь рассмотрим пару примеров применения этой технологии.
▍Полифиллы
Я начинаю именно с этого примера, так как то, что мы тут рассмотрим, просто реализуется и применимо к большинству сайтов.
Я использую на своём сайте множество полезных штуковин в виде полифиллов. Поэтому у меня имеется файл, в котором всё это подключается. Он состоит из следующих восьми строчек:
Благодаря использованию конфигурации Webpack из предыдущего раздела, материалы полифиллов будут автоматически разделены на четыре файла, так как для их реализации используются четыре npm-пакета. Их размер составляет примерно 25 Кб, 90% браузеров они не нужны, поэтому имеет смысл загружать их динамически.
Благодаря применению Webpack 4 и использованию конструкции import() (не путайте её с ключевым словом import ), организовать условную загрузку полифиллов очень просто:
Кстати сказать, для использования import() вам понадобится плагин Babel dynamic-import. Кроме того, как сказано в документации к Webpack, команда import() использует промисы, поэтому полифилл для данной возможности нужно загружать отдельно от других полифиллов.
Как я и говорил, это очень просто. Рассмотрим теперь пример посложнее.
▍Динамическая загрузка материалов в React, основанная на маршрутах
Вернёмся к примеру с Алисой. Предположим, теперь на нашем сайте есть закрытый раздел для администраторов магазинов, куда они могут входить для того, чтобы управлять своими товарами.
В этом разделе имеется множество замечательных возможностей, куча графиков и здоровенная npm-библиотека для работы с ними. Так как на сайте уже применяется разделение бандлов, я могу понять, что всё это занимает более 100 Кб.
Причём, для этого не нужно заниматься конфигурированием.
Итоги
Полагаю, я рассказал всё, что хотел (хотя, надо отметить, мы не говорили тут о CSS). Подведём краткие итоги: