Когда мне следует использовать встроенный или внешний Javascript?

На момент публикации этого ответа (2008 г.) правило было простым: все сценарии должны быть внешними. И для обслуживания, и для производительности.

(Почему производительность? Потому что, если код отдельный, его легче кэшировать в браузерах.)

JavaScript не входит в HTML-код, и если он содержит специальные символы (например, <, >), это даже создает проблемы.

В настоящее время веб-масштабируемость изменилась. Уменьшение количества запросов стало допустимым соображением из-за задержки выполнения нескольких HTTP-запросов. Это усложняет ответ: в большинстве случаев рекомендуется использовать внешний JavaScript по-прежнему. Но в некоторых случаях, особенно в очень маленьких фрагментах кода, встраивание их в HTML-код сайта имеет смысл.

В вашем сценарии это звучит так, как будто запись внешнего материала в один файл, совместно используемый страницами, будет вам полезна. Я согласен со всем сказанным выше.

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

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

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

Естественно, все это становится неактуальным в тот момент, когда ваш код длиннее пары строк и не привязан к одной странице. В тот момент, когда вы захотите повторно использовать этот код, сделайте его внешним. Если нет, посмотрите на его размер и решите.

Экстернализация javascript - одно из правил производительности Yahoo: http://developer.yahoo.com/performance/rules.html#external

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

Я бы посмотрел на требуемый код и разделил его на столько отдельных файлов, сколько нужно. Каждый файл js будет содержать только один «логический набор» функций и т. д., Например. один файл для всех функций, связанных с входом в систему.

Затем при разработке сайта на каждой странице html вы включаете только те, которые необходимы. Когда вы запускаете свой сайт, вы можете оптимизировать его, объединив каждый файл js, который нужен странице, в один файл.

Три соображения:

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

я думаю, что специфично для одной страницы, короткий сценарий сценария - (единственный) оправданный случай для встроенного скрипта

Внешние скрипты также легче отлаживать с помощью Firebug. Мне нравится проводить модульное тестирование моего JavaScript и иметь все внешние подсказки. Я ненавижу видеть JavaScript в коде PHP и HTML, мне это кажется большим беспорядком.

Что касается сохранения внешнего кода JavaScript:

ASP.NET 3.5SP1 недавно представил функциональность для создания ресурса Composite script (слияние нескольких файлов js в один). Еще одно преимущество этого заключается в том, что когда включено сжатие веб-сервера, загрузка одного файла немного большего размера будет иметь лучший коэффициент сжатия, чем многие файлы меньшего размера (также меньше накладных расходов HTTP, двустороннего трафика и т. Я предполагаю, что это экономит на начальной загрузке страницы, а затем запускается кеширование браузера, как упоминалось выше.

Помимо ASP.NET, этот скринкаст более подробно объясняет преимущества: http://www.asp.net/learn/3.5-SP1/video-296.aspx

Еще одно скрытое преимущество внешних сценариев заключается в том, что вы можете легко запускать их с помощью средства проверки синтаксиса, такого как jslint. Это может спасти вас от множества душераздирающих, труднообнаруживаемых ошибок IE6.

На самом деле, есть довольно веские основания для использования встроенного javascript. Если js достаточно мал (однострочный), я предпочитаю встроенный javascript из-за двух факторов:

• Местонахождение. Нет необходимости перемещаться по внешнему файлу, чтобы проверить поведение некоторого javascript.
• AJAX. Если вы обновляете какой-то раздел страницы через AJAX, вы май теряете все ваши обработчики DOM (onclick и т. д.) Для этого раздела, в зависимости от того, как вы их связали. Например, используя jQuery, вы можете использовать методы live или delegate, чтобы обойти это, но я считаю, что если js достаточно мал, предпочтительнее просто поместить его в строку.

Единственная защита, которую я могу предложить для встроенного javascript, заключается в том, что при использовании строго типизированных представлений с .net MVC вы можете ссылаться на переменные C# в середине javascript, которые я считаю полезными.

Еще одна причина, по которой вы всегда должны использовать внешние скрипты, - это облегчить переход на Политика безопасности контента (CSP). По умолчанию CSP запрещает использование всех встроенных скриптов, что делает ваш сайт более устойчивым к XSS-атакам.

Если вы заботитесь только о производительности, большинство советов в этом потоке совершенно неверны и становятся все более и более неправильными в эпоху SPA, когда мы можем предположить, что страница бесполезна без JS-кода. Я потратил бесчисленные часы на оптимизацию времени загрузки страницы SPA и проверку этих результатов в разных браузерах. Повсеместно повышение производительности за счет повторной оркестровки вашего html может быть весьма значительным.

Чтобы добиться максимальной производительности, вы должны думать о страницах как о двухступенчатых ракетах. Эти две стадии примерно соответствуют фазам <head> и <body>, но воспринимайте их как <static> и <dynamic>. Статическая часть - это в основном строковая константа, которую вы вставляете в канал ответа так быстро, как только можете. Это может быть немного сложно, если вы используете много промежуточного программного обеспечения, которое устанавливает файлы cookie (они должны быть установлены перед отправкой содержимого http), но в принципе он просто очищает буфер ответа, надеюсь, перед тем, как перейти к некоторому шаблонному коду (razor, php, и т. д.) на сервере. Это может показаться трудным, но тогда я просто объясняю это неправильно, потому что это почти тривиально. Как вы уже догадались, эта статическая часть должна содержать весь встроенный и минифицированный javascript. Это выглядело бы примерно так

<!DOCTYPE html>
     <html>
         <head>
             <script>/*...inlined jquery, angular, your code*/</script>
             <style>/* ditto css */</style>
         </head>
         <body>
             <!-- inline all your templates, if applicable -->
             <script type='template-mime' id='1'></script>
             <script type='template-mime' id='2'></script>
             <script type='template-mime' id='3'></script>

Поскольку отправка этой части по сети почти ничего не стоит, вы можете ожидать, что клиент начнет получать ее где-то около 5 мс + задержка после подключения к вашему серверу. Предполагая, что сервер достаточно близко, эта задержка может составлять от 20 мс до 60 мс. Браузеры начнут обрабатывать этот раздел, как только они его получат, и время обработки обычно будет преобладать над временем передачи в 20 или более раз, что теперь является вашим амортизированным окном для обработки части <dynamic> на стороне сервера.

Браузеру требуется около 50 мсек (хром, отдых может быть на 20% медленнее), чтобы обработать встроенный jquery + signalr + angular + ng animate + ng touch + ng routes + lodash. Это довольно удивительно само по себе. В большинстве веб-приложений меньше кода, чем во всех этих популярных библиотеках вместе взятых, но предположим, что у вас столько же, поэтому мы выиграем задержку + 100 мс обработки на клиенте (эта задержка достигается за счет второго фрагмента передачи). К моменту поступления второго чанка мы обработали весь js-код и шаблоны и можем приступить к выполнению преобразований dom.

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

Я много работаю над оптимизацией SPA-приложений. Люди часто думают, что объем данных имеет большое значение, в то время как на самом деле задержка и выполнение часто преобладают. Минифицированные библиотеки, которые я перечислил, добавляют до 300 КБ данных, и это всего лишь 68 КБ в сжатом виде, или загрузка 200 мс на 2-мегабитный телефон 3g / 4g, что является именно той задержкой, которую потребовалось бы на том же телефоне, чтобы проверить, были ли у него те же данные. в своем кэше уже, даже если он был кэширован прокси, потому что налог на задержку мобильной связи (задержка между телефоном и вышкой) все еще применяется. Между тем, подключения к настольным компьютерам с более низкой задержкой первого прыжка в любом случае обычно имеют более высокую пропускную способность.

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

ИЗМЕНИТЬ (МАЙ 2016)

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

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

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

Всегда старайтесь использовать внешние JS, поскольку встроенные JS всегда сложно поддерживать.

Более того, профессионально требуется, чтобы вы использовали внешний js, поскольку большинство разработчиков рекомендуют использовать js извне.

Сам использую внешние js.

Наличие внутренних плюсов JS: Легче управлять и отлаживать Вы можете видеть, что происходит

Внутренние минусы JS: Люди могут все изменить, и это действительно может вас раздражать.

внешние преимущества JS: не менять Вы можете выглядеть более профессионально (по крайней мере, я так думаю)

минусы внешнего JS: труднее управлять трудно понять, что происходит.