Что является лучшей практикой для эффективной организации и обслуживания JavaScript - PullRequest
4 голосов
/ 22 июля 2010

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

Что меня беспокоит:

  • Быть эффективным на сервере
  • Быть эффективным в браузере
  • Поддержание управляемости кодовой базы

Предположим, что весь авторский JavaScript хранится в одном массивном файле application.js, который, в свою очередь, объединяется вместе со всеми внешними библиотеками в один файл js, который должен доставить сервер. Это должно быть наиболее эффективным на сервере, так как он должен обслуживать его только один раз, а затем браузер будет кэшировать его для каждой последующей загрузки страницы.

В нем содержится множество пользовательских функций jQuery, подключенных к таким селекторам:

$('#my_unique_selector').bellsAndWhistlesPlugin();

Если вышеупомянутый селектор присутствует только на нескольких страницах, использование методов обслуживания всего в одном пакете означает, что при каждой загрузке страницы браузер должен анализировать код плагина (который не будет использоваться), и затем интерпретировать метод bellsAndWhistlesPlugin(), даже если селектор не находит совпадения.

Так что я думаю, мой вопрос, в какой момент этот подход становится неэффективным? Есть ли аргумент для разделения JavaScript и предоставления только тех битов, которые требуются для каждой страницы? Или я ни о чем не беспокоюсь - браузеры более чем способны справиться с нагрузками избыточного кода?

Ответы [ 4 ]

4 голосов
/ 26 августа 2010

Что-то, что вы определенно НЕ должны делать, - это объединить весь ваш JavaScript в один файл.Если вы когда-нибудь внесете изменения в свою кодовую базу, этот файл будет воссоздан ... и распространен среди всех посетителей.Затраты HTTP довольно незначительны, поэтому если вы не загружаете сотни и тысячи уникальных файлов, загрузка 20 разных файлов по сравнению с загрузкой 1 большого не будет иметь большого значения, за исключением пользователей с исключительно медленными соединениями (которые будут ждать большихфайл в любом случае, поэтому они не заметят лишнюю секунду или две из-за накладных расходов HTTP).

Предложение ToonMariner использовать размещенный код (в частности, из репозитория Google Code) является хорошим - это избавляет вас от необходимостиразмещать файл, он позволяет пользователям, которые столкнулись с этим файлом, воспользоваться преимуществами кэширования (улучшая кажущуюся скорость загрузки вашего сайта), и он не будет включен в составленный файл, если вы внесете изменение.Даже если вы решите сохранить все свое приложение в одном большом файле, вы должны использовать его, поскольку вы можете избежать упаковки jQuery, и это сэкономит 50 + КБ.

Кроме того, ваша забота о интерпретации bellsAndWhistlesPlugin () правильно - функция this в функции bellsAndWhistlesPlugin - это просто пустой список (хотя я надеюсь, что плагин выполняет вызов $ (this) .each для итерации по элементам и возвращает рано, поскольку элементов нет ... в противном случаеВы можете вернуться к своим плагинам!).Вы можете устранить эту проблему, удалив специфичный для страницы код из вашего полного файла application.js и поместив его во встроенный элемент на самой странице, где он все равно принадлежит, или переписав плагин, чтобы он возвращался рано, если естьнет соответствующих элементов.

Просто убедитесь, что вы включили кэширование для ресурсов, загруженных из каталога / js, и у вас не возникнет проблем с перезагрузкой библиотек - только те, которые изменились.Вы можете использовать заголовок Expires или последний измененный заголовок;Истечение срока действия не обязательно приведет к принудительному обновлению, если пользователь не перезагружается или срок действия кэша не истек, а Last -ified вызывает HTTP-издержки для каждого файла, что проблематично для большого числа файлов.Вам придется оценить компромиссы для вашего приложения.

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

Вопрос, который вы задаетедолжен спросить себя: кто мой средний пользователь?Какой тип связи у него / нее?Нужно ли запускать мое приложение на мобильных устройствах?Если ваш обычный пользователь имеет быстрое соединение, не беспокойтесь об этом - они загрузят вашу страницу достаточно быстро, в зависимости от того, какой путь вы выберете.Если вам нужно работать на мобильных устройствах или ваша целевая аудитория имеет низкую скорость соединения, рассмотрите возможность кэширования больших библиотек, которые меняются очень редко, и использования внешних репозитариев, где это возможно (например, jQuery), а затем упакуйте оставшееся приложение в один большой файл.,Издержки HTTP для мобильных устройств и медленного интернета достаточно значительны, чтобы оправдать это.

0 голосов
/ 22 июля 2010

, если $ ('# my_unique_selector') не найдет совпадений, вызываемый метод произойдет ноль раз.Вы все еще выполняете запрос "#my_unique_selector", но bellsAndWhistlesPlugin () никогда не будет вызываться.

0 голосов
/ 22 июля 2010

Хотел опубликовать что-то действительно похожее на ваш вопрос на днях, пока я не наткнулся на это:

Есть ли JavaScript MVC (микро) фреймворк? Пока я смотрелДокументация javascriptMVC немного у меня не было времени полностью пройти через это.Похоже, что для его начала потребуется серьезная переписка.

Я полагаю, что вы, тем не менее, правильно решаете эти проблемы как можно раньше в своем проекте.

0 голосов
/ 22 июля 2010

Мой личный подход - использовать размещенный код (я использую googles jquery repo) и помещать все мои глобальные ресурсы (файлы javascript, css, изображения, используемые css) в файл gzip.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...