Что лучше всего подходит для эффективного и эффективного обслуживания JavaScript

Question

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

вещи, которые касаются меня являются:

• Будучи эффективным на сервере
• Будучи эффективным в браузере
• Сохраняя кодовую управляемой

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

Содержится в нем много пользовательских функциях JQuery подвешен селекторы, как это:

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

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

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

Answer 1

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

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

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

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

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

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

Последний вопрос

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.

 Смежные вопросы

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.