Сколько скорости достигается с помощью RequireJS/AMD в JS?

Насколько быстрее требуется requireJS на большом веб-сайте?

Кто-нибудь делал какие-либо тесты на скорости больших сайтов, использующих асинхронную загрузку, а не?

Например, используя Магистраль с большим количеством просмотров ( > 100), лучше просто иметь объект представлений, который одновременно загружается всеми представлениями и всегда доступен, или все они должны быть загружены асинхронно, как необходимо?

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

Ответ 1

Я не считаю, что цель require.js заключается в том, чтобы асинхронно загружать все ваши скрипты в процессе производства. В процессе разработки асинхронная загрузка каждого script удобна, потому что вы можете вносить изменения в свой проект и перезагружать без шага "компиляция". Однако в производстве вы должны комбинировать все ваши исходные файлы в один или несколько более крупных модулей, используя оптимизатор r.js. Если ваш большой webapp может отложить загрузку подмножества ваших модулей до более позднего времени (например, после определенного действия пользователя), эти модули могут оптимизироваться отдельно и загружаться асинхронно в процессе производства.

Что касается скорости загрузки одного большого JS файла и нескольких меньших файлов, обычно:

"Сокращение HTTP-запросов" стало общей целью ускорения производительности интерфейса, и это проблема, которая еще более актуальна в сегодняшнем мире мобильных браузеров (часто работает в сетях, которые на порядок медленнее, чем широкополосные), [ссылка]

Но есть и другие соображения, такие как:

Мобильные кеши: iPhones ограничивают размер файлов, которые они кэшируют, поэтому большие файлы, возможно, придется загружать каждый раз, что делает многие небольшие файлы лучше.
Использование CDN. Если вы используете обычную стороннюю библиотеку, например jQuery, лучше не включать ее в большой JS файл и вместо этого загружать ее из CDN поскольку пользователь вашего сайта может уже иметь его в своем кеше с другого веб-сайта (ссылка). Для получения дополнительной информации см. Обновление ниже
Lazy Evaluation: модули AMD могут анализироваться и оцениваться с лёгкостью, что позволяет загружать нагрузку на приложение, откладывая затраты на parse + eval до тех пор, пока модуль не понадобится. См. эту статью и серию других старых статей, которые она ссылается.
Целевой браузер. Браузеры ограничивают количество одновременных загрузок на имя хоста. Например, IE 7 будет загружать только два файла с данного узла одновременно. Другие ограничивают 4, а другие - 6. [ссылка]

Наконец, вот хорошая статья Стива Соудерса, в которой суммируется куча методов загрузки script.

Обновление: Re CDN: Steve Souders опубликовал подробный анализ использования CDN для сторонних библиотек ( например jQuery), который идентифицирует многие соображения, плюсы и минусы.

Ответ 2

Этот вопрос немного устарел, но я подумал, что могу добавить свои мысли.

Я полностью согласен с rharper в использовании r.js, чтобы объединить весь ваш код для производства, но есть также случай для разделения функций.

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

Подход, который я использовал несколько раз,

определить основные модули (необходимые для всех страниц для их правильной работы), это объединяется в один файл.
создать загрузчик модуля, который понимает зависимости DOM и пути к модулям.
на doc.ready прокрутите модуль загрузчика модуля и асинхронные модули загрузки, необходимые для улучшения функциональности по мере необходимости на определенных страницах.

Преимущество здесь заключается в том, что вы сохраняете исходный вес страницы, а при загрузке дополнительных скриптов async после загрузки страницы воспринимаемая производительность должна быть быстрее. Тем не менее, все функциональные возможности, загруженные таким образом, должны выполняться как прогрессивное улучшение (например, ajax в формах), так что в случае медленной загрузки или ошибок базовые функции все еще доступны.