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

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

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

Реальный сценарий - у меня есть несколько html-страниц, которые требуют проверки формы на стороне клиента. Для этого я использую плагин jQuery, который я включаю на всех этих страницах. Но вопрос в том, могу ли я:

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

Спасибо.

117 голосов | спросил Dan Burzo 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 26 Sep 2008 15:31:10 +0400 2008, 15:31:10

15 ответов


0

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

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

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

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

ответил Konrad Rudolph 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 26 Sep 2008 15:33:08 +0400 2008, 15:33:08
0

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

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

ответил Horst Gutmann 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 26 Sep 2008 15:38:24 +0400 2008, 15:38:24
0

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

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

ответил Joeri Sebrechts 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 26 Sep 2008 15:41:02 +0400 2008, 15:41:02
0

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

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

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

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

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

РЕДАКТИРОВАТЬ (МАЙ 2016)

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

ответил Gleno 8 +04002014-10-08T05:17:37+04:00312014bEurope/MoscowWed, 08 Oct 2014 05:17:37 +0400 2014, 05:17:37
0

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

ответил Gene T 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 30 Sep 2008 22:55:20 +0400 2008, 22:55:20
0

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

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

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

ответил chiborg 2 +04002013-10-02T14:05:14+04:00312013bEurope/MoscowWed, 02 Oct 2013 14:05:14 +0400 2013, 14:05:14
0

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

ответил Austin_G 1 MarpmFri, 01 Mar 2013 18:01:34 +04002013-03-01T18:01:34+04:0006 2013, 18:01:34
0

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

  • Сколько кода вам нужно (иногда библиотеки - первоклассный потребитель)?
  • Специфичность: этот код работает только в контексте этого конкретного документа или элемента?
  • Каждый код внутри документа стремится сделать его длиннее и, следовательно, медленнее. Кроме того, из соображений SEO становится очевидным, что вы минимизируете внутренние сценарии ...
ответил roenving 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 29 Sep 2008 07:02:38 +0400 2008, 07:02:38
0

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

ответил Clutch 8 +04002008-10-08T09:44:36+04:00312008bEurope/MoscowWed, 08 Oct 2008 09:44:36 +0400 2008, 09:44:36
0

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

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

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

ответил Brendan Kowitz 8 +04002008-10-08T11:09:12+04:00312008bEurope/MoscowWed, 08 Oct 2008 11:09:12 +0400 2008, 11:09:12
0

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

ответил mattlant 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 26 Sep 2008 15:35:22 +0400 2008, 15:35:22
0

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

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

ответил Robert Gould 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 26 Sep 2008 15:36:05 +0400 2008, 15:36:05
0

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

ответил Kees Hessels 14 J0000006Europe/Moscow 2015, 08:04:48
0

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

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

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

ответил 26 PMpThu, 26 Apr 2018 21:31:55 +030031Thursday 2018, 21:31:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132