Почему люди всегда поощряют одиночный JS для веб-сайта? - PullRequest
2 голосов
/ 15 июля 2010

Я читаю некоторые материалы по разработке веб-сайтов в Интернете, и каждый раз, когда кто-то просит организовать js, css, html и php файлы веб-сайта, люди предлагают один js для всего сайта. И аргумент - это скорость.

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

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

Есть ли критика / согласие на мой аргумент? Я ошибся? Спасибо за ваше предложение.

Ответы [ 5 ]

4 голосов
/ 15 июля 2010

Функция выполняет 0, если не вызывается.Таким образом, 9 пустых функций - это 0 работ, только немного точного пространства.

Клиенту нужно только сделать 1 запрос на загрузку 1 большого файла JS, затем он кэшируется при каждой другой загрузке страницы.Меньше работы, чем делать небольшой запрос на каждой странице.

2 голосов
/ 15 июля 2010

Я дам вам ответ, который я всегда даю: это зависит.

Объединение всего в один файл имеет много преимуществ, в том числе:

  1. меньше сетевого трафика - возможно, вы получаете один файл, но вы отправляете / получаете несколько пакетов, и каждая транзакция имеет серию сообщений SYN, SYN-ACK и ACK, отправленных через TCP. Большую часть времени передачи составляет сеанс, и в заголовках пакетов много служебных данных.

  2. одно местоположение / управляемость - хотя у вас может быть только несколько файлов, функции (и объекты классов) могут легко расти между версиями. Когда вы используете многофайловый подход, иногда функции из одного файла вызывают функции / объекты из другого файла (например, ajax в одном файле, а затем арифметические функции в другом - ваши арифметические функции могут вырасти до необходимости вызывать ajax и иметь определенный тип переменной возвращается). В итоге получается, что ваш набор файлов должен рассматриваться как одна версия, а не как отдельный файл. В будущем дела пойдут не так, как надо, если у вас нет хорошего управления, и легко выйти из строя с помощью файлов Javascript, которые постоянно меняются. Наличие одного файла облегчает управление версией между каждой из ваших страниц на ваших (от 1 до многих) веб-сайтах.

Другие темы для рассмотрения:

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

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

Почему это зависит?

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

Это также зависит от размера. Некоторые программисты встраивают закодированные изображения как ASCII в свои файлы, чтобы уменьшить количество отправляемых файлов. Они могут раздуть файлы. Конечно, вы не хотите упаковывать все в 1 50MB файл. Особенно, если для загрузки страницы необходимы основные функции.

Итак, чтобы завершить мой ответ, нам потребуется больше информации о вашей настройке, потому что это зависит. Конечно, 3 файла приемлемы независимо от размера, объединяя, где вы посчитаете нужным. Вероятно, это не повредит сетевому трафику, но 50 файлов - это более неразумно. Я использую правило раздачи (не более 5), но вы наверняка увидите преимущество, объединяющее эти 5 файлов по 1 КБ в файл размером 1 5 КБ.

1 голос
/ 15 июля 2010

Две причины, по которым я могу придумать:

Меньше задержки в сети.Каждый .js требует другого запроса / ответа на сервер, с которого он загружен.

Больше байтов на проводе и больше памяти.Если это один файл, вы можете удалить ненужные символы и минимизировать все это.

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

Мое мнение таково, что у вас меньше запросов.Когда вы делаете запрос в заголовке страницы, он останавливает вывод остальной части страницы.Пользовательский агент не может отобразить остальную часть страницы, пока не будут получены файлы javascript.Также javascript-файлы загружаются синхронно, они ставятся в очередь, а не сразу (по крайней мере, в теории).

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

Javascript должен быть спроектирован так, чтобы дополнительные функции вообще не выполнялись, если они не нужны.

Например, вы можете определить набор функций в вашем скрипте, но только вызывать их в (очень короткий) встроенные <script> блоки на самих страницах.

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