Почему встроенный JavaScript плохой?

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

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

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 и вызывать функции через inline JavaScript, мы можем вызывать только те функции, которые требуются на текущей странице:

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

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

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

Ответы

Ответ 1

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

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

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

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

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

Ответ 2

  • Избегание inline js не основано на производительности... но его больше касается ремонтопригодности и разделения уровня представления (html) на уровне контроллера (js).

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

Для inline:

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

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

Теперь существует другая теория для ex

Внешний javascript является одним из правил производительности yahoo:

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

Ответ 6

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

Ответ 7

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