Когда следует использовать Inline vs. External Javascript?

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

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

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

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

Спасибо.

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

EDIT (МАЙ 2016)

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

Ответ 16

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

Ответ 17

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