14

Всегда рекомендуется избегать встроенных кодов Javascript, помещая все коды в файл JS, который включен во все страницы. Интересно, если это не вызовет проблемы с производительностью на тяжелых страницах.Почему встроенный JavaScript плохой?

Например, представьте, что у нас есть десятки функций, как этот

function function1(element){ 
var el=document.getElementsByClassName(element); 
var size=el.length; 
if(size==0) return; 
for(i=0;i<size;i++){ 
// the process 
} 
} 

на каждой странице, нам нужно выполнить функции, чтобы узнать, есть ли соответствующие элементы в HTML или нет.

window.onload = function(){ 
function1('a'); 
.... 
function26('z'); 
}; 

но если держать все функции во внешнем JS файле, и вызов функций через инлайн JavaScript, мы можем назвать только функции, которые требуются в данной странице:

<script type="text/javascript"> 
window.onload = function(){ 
function6('f'); 
}; 
</script> 

Безразлично Не выгодно ли с точки зрения производительности вызывать функции через встроенный Javascript (что, конечно, не самая лучшая практика), чтобы избежать вызова множества функций, которые не нужны на странице?

Конечно, это не ограничивается только функциями, так как у нас есть много addEventListener с для всего сайта, которые открыли огонь по каждой странице, где они не нужны.

+1

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

+0

Никто никогда не говорил, что каждая функция всего вашего сайта должна быть в одном файле Javascript ... почему должна быть какая-либо разница в количестве кода в вашем внешнем JS-файле по сравнению с ваш «встроенный» Javascript? – devnull69

+0

@ RoryPicko92 главное преимущество всех JS-кодов в одном файле заключается в том, что он будет кэшироваться и не нужен для загрузки через просмотр. – Googlebot

ответ

4

Вы должны прочитать о ненавязчивом javascript, http://en.wikipedia.org/wiki/Unobtrusive_JavaScript.

Существуют и другие решения, не загружающие все файлы javascript в вашем каталоге ресурсов для каждой веб-страницы, которая называется requirejs, которая должна быть проверена, http://requirejs.org/.

Кроме того, как правило, вы не должны добавлять всех слушателей событий при загрузке страницы, а что о объектах dom, которые не существуют? Это вызовет ошибки javascript и сломает ваш код больше, чем обычно.

25

Это не рекомендуется встраивать статические ресурсы (в вашем случае, встроенный JavaScript) так вы не можете кэшировать их.

Кэширование статического ресурса уменьшает размер загружаемых страниц - тем самым увеличивая скорость загрузки страницы - для возвращения посетителей. Однако это связано с дополнительным HTTP-запросом which should be avoided.

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

Обычно рекомендуется хранить библиотеки javascript во внешних (кэшируемых) документах, сохраняя при этом небольшое количество скриптов.

Итак, в ответ на ваш заголовок - встроенный javascript не является плохим per-se. Это баланс того, стоит ли HTTP-запрос кэшировать ресурс.

+2

Хотя есть много других актуальных проблем, это правильный ответ на вопрос, и, безусловно, самая влиятельная проблема при выборе inline vs external. –

+0

Это действительно хороший ответ. У меня была только дискуссия с кем-то об этом, и я рассуждал о том, что речь идет о балансе. Существует много блогов, в которых говорится, что inline - это плохо, но я не мог согласиться с их рассуждениями. Я использую множество встроенных фрагментов, которые будут работать только на одной странице. Более общие фрагменты, которые более многократно используются, помещаются в один файл js, который включен для каждой страницы. –

+0

В этом случае внешнего файла он может быть загружен в параллел и подан через кэш-память, например облачный. Таким образом, влияние производительности не встраивается в достаточно пренебрежительное, чтобы сказать, что его редко бывает хорошей идеей с ее беспорядочной. – max

16
  • Избегание встроенных js не зависит от производительности ...но в большей степени об обслуживании и разделении уровня представления (html) с уровня контроллера (js).

  • Наличие встроенных js на разных страницах будет затруднять обслуживание для вас и других при увеличении масштаба проекта.

  • Кроме того, используя отдельные файлы js, вы можете поощрять повторное использование и модульный дизайн кода.

  • сохраняет ваш html в чистоте, и вы знаете, где искать, когда возникает какая-либо ошибка js вместо нескольких шаблонов.

+0

Вы можете встроить JS в процесс сборки так же, как объединить несколько JS-файлов в один для развертывания. – Mark

1

Возможно, запуск ненужного JavaScript на странице приведет к медленной загрузке этой страницы. Это зависит от запуска JavaScript.

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

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

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

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

  1. Браузер извлекает страницу из кэша, или посылает запрос HTTP, чтобы увидеть, если страница изменилась, поскольку она была кэшируются , и/или отправляет HTTP-запрос для самой страницы.
  2. Браузер анализирует и отображает страницу, делая паузу для извлечения и запуска любого внешнего JavaScript, а также выборки таблиц стилей и изображений одновременно с разбором и рендерингом.
  3. Браузер запускает любой установленный JavaScript для работы с готовым документом.
  4. Браузер запускает любой JavaScript-код, который запускается при загрузке страницы.

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

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

+0

getElementsByClassName - это ленивое перечисление ... (или «живое», как они его называют), это не какая-то работа, чтобы просто называть его. – Esailija

1

Существуют различные варианты, которые необходимо учитывать при размещении js-кода.

Для инлайн:

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

  2. , если вы используете AJAX в некоторых элементах вашей страницы вы может освободить весь элемент dom onclick и т. д. для этого раздела, что, очевидно, зависит от того, как вы их связали. например, вы можете использовать live или delegate в случае, если вы используете jQuery, чтобы избежать вышеупомянутой проблемы ... но я нахожу, что если js достаточно мал, желательно просто вставить его в строку.

Теперь другая теория для экс

экстернализующего JavaScript является одним из правил производительности Yahoo:

http://developer.yahoo.com/performance/rules.html#external

0

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

+0

Зависит от JavaScript, правда, не так ли. Например, на запущенном сайте я использую этот скрипт внутри строки сразу после тега body: ' '. Это 141 байт, и это до gzipping.Не особенно тяжело, и я думаю, что это самый быстрый способ изменить класс на теле, так как нет никакого события JavaScript, которое срабатывает после визуализации тега body. –

+0

Также: «который включает в себя требования к страницам, которые помогут нам использовать код js для каждой функциональности» - я не знаю, что это значит. –

+0

Если нам нужен большой js-расчет с ajax, тогда мы потребовали, чтобы мы могли добавить небольшую функциональность js на странице ofcourse. –

0

Встроенные стили/скрипты запутаны с содержимым html и могут сильно различаться. Один из ключей к содержанию кода в веб-разработке - это код, который легко читается кем-то, кто его не написал. Смешивание сценариев скриптов в ваш html может очень затруднить поиск функции, которая влияет на остальную часть кода. Включение Javascript в файлы .js и стили в файлах CSS делает код более понятным.

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