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

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

какова общая практика для этого?

Real-world-scenario - у меня есть несколько html-страниц, которые нуждаются в проверке формы на стороне клиента. Для этого я использую плагин jQuery, который я включаю на всех этих страницах. Но вопрос в том, хочу ли я:--1-->

  • напишите биты кода, которые настраивают этот скрипт инлайн?
  • включить все биты в один файл, который является общим для всех этих html-страниц?
  • включить каждый бит в отдельный внешний файл, по одному для каждой HTML-страницы?

спасибо.

18 ответов


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

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

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

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


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

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


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

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


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

чтобы получить максимальную производительность, вы должны думать о страницах, как двухступенчатые ракеты. Эти две стадии примерно соответствуют <head> и <body> фазы, но думайте о них вместо этого как <static> и <dynamic>. Статическая часть-это в основном строковая константа, которую вы запихиваете в трубу ответа так быстро, как только можете. Это может быть немного сложно, если вы используете много промежуточного программного обеспечения, которое устанавливает куки (они должны быть установлены перед отправкой содержимого 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 мс + задержка после подключения к серверу. Предполагая, что сервер разумно близко эта задержка может быть между 20ms до 60ms. Браузеры начнут обрабатывать этот раздел, как только они его получат, и время обработки обычно будет доминировать время передачи в 20 или более раз, что теперь является вашим амортизированным окном для серверной обработки <dynamic> часть.

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

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

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

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

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

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


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


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

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

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


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

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


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


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

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

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


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

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

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


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


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


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

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


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


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


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

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

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