Какой хороший подход для разделения плагинов и конфигураций на основе JavaScript для повышения производительности

Question

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

В настоящее время некоторые плагины объединены в монолитный файл plugins.js, в то время как другие загружаются как отдельные файлы. Конфигурации выполняются в виде встроенных блоков сценариев внутри файлов шаблона. Я считаю, что управление плагинами выходит из-под контроля, влияя на время загрузки страницы и производительность.

Я подумал о следующем подходе: разделять плагины в отдельных файлах, а затем записывать конфигурации для конкретных страниц (например, назначать обработчики событий или прикреплять теги) также в отдельных файлах. Затем я намереваюсь создать сценарий, возможно основанный на Sprockets , который выполняется во время развертывания и объединяет несколько плагинов с их файлами конфигурации, а затем выводит один файл.

Мой ввод будет:

• plugin1.js
• plugin1.conf.js
• plugin2.js
• plugin2.conf.js

Вывод будет включать все необходимые файлы для конкретной страницы.

• page1.js = plugin1.js + plugin1.conf.js + ...

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

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

Это разумный подход? Видите ли вы какие-либо проблемы с этим?

Кто-нибудь еще решал такую ​​проблему?

Answer 1

Краткий ответ

Измерьте текущий сайт и определите узкие места.

Длинный ответ

Будем надеяться, что некоторые люди с опытом будут давать более полезные ответы, но:

Как сказал в своем блоге какой-то Yahoo по имени Джефф Этвуд Computer Performance Shell Game , оптимизация производительности позволяет выяснить, какой ресурс является узким местом, и устранить узкое место. Ресурсы:

• Процессор
• Память
• Диск
• Сеть

Создавая различные конфигурации файлов JavaScript для каждой страницы, я думаю, вы хотите сэкономить:

1. Процессор (меньше JavaScript для запуска на каждой странице)
2. Сеть (меньше JavaScript для загрузки на каждой странице)

По второму вопросу, вы могли бы лучше обслуживать, если бы весь ваш JavaScript для всего сайта был в одном большом файле.

• Файл можно загрузить один раз, а затем кэшировать, вместо того, чтобы загружать разные файлы для каждой страницы
• Один большой файл может сжиматься лучше при минимизации и архивации

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

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

Answer 2

Будьте осторожны с кэшированием в браузере page1.js, либо называйте его динамически при упаковке, например. page1-1002231846.js или убедитесь, что кэши недействительны с правильными заголовками.

Не создавайте слишком много вариантов, скорее обобщайте, кэширование в браузере, вероятно, сэкономит больше времени, чем несколько килобайт, для загрузки.

Определите сценарии и модули, которые являются общими для большинства страниц, и объедините их вместе в common.js

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

Используйте Chrome Speed ​​Tracer, чтобы выяснить узкие места рендеринга.

Answer 3

Можете ли вы попробовать это ? Он отлично работает с плагинами, потоками и т. Д.

Answer 4

Я в основном объединяю все это во время сборки до

• js3rdparty.js
• js3rdpartyplugins.js
• configurations.js
• bootstrapper.js

js3rdparty.js содержит, скажем, jQuery и ExtJs. Это очень вряд ли изменится со временем и имеет значительные размеры. js3rdpartyplugins.js все плагины / расширения, которые я извлек из интернета или написал сам, этот файл значительно меньше и несколько более подвержен изменениям. Я просто загружаю все свои конфигурации в configurations.js для всех моих страниц одновременно. В моем приложении это сводится к загрузке конфигураций сетки и полей формы, но после упаковки и минимизации этот файл очень мал. bootstrapper.js - это, по сути, комбинированный скрипт всего поведения сайта (слушатели событий, создание элементов управления, анимация и т. Д.).

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