Если вы заботитесь только о производительности, большинство советов в этой теме совершенно неверны и становятся все более и более неправильными в эпоху 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 + сигнализатор + угловой + ng animate + ng touch + ng route + lodash. Это довольно удивительно само по себе. Большинство веб-приложений имеют меньше кода, чем все эти популярные библиотеки, вместе взятые, но, скажем, у вас их столько же, поэтому мы выиграли бы задержку + 100 мс обработки на клиенте (эта задержка получается из второго блока передачи). К тому времени, когда прибудет второй блок, мы обработаем весь код и шаблоны js и сможем начать выполнять преобразования dom.
Вы можете возразить, что этот метод ортогональн к встраиваемой концепции, но это не так. Если вы вместо встраивания ссылаетесь на cdns или ваши собственные серверы, браузер должен будет открыть другое соединение (я) и задержать выполнение. Поскольку это выполнение в основном бесплатное (поскольку сервер взаимодействует с базой данных), должно быть ясно, что все эти переходы будут стоить дороже, чем вообще без переходов. Если бы была какая-то особенность браузера, в которой говорилось, что внешний js выполняется быстрее, мы могли бы измерить, какой фактор доминирует. Мои измерения показывают, что дополнительные запросы снижают производительность на этом этапе.
Я много работаю с оптимизацией приложений SPA. Люди часто думают, что объем данных имеет большое значение, хотя в действительности задержка и исполнение часто доминируют. Упомянутые минимизированные библиотеки добавляют до 300 КБ данных, и это всего лишь 68 КБ в разархивированном виде, или загрузка 200 мс на 2-мегабитный телефон 3g / 4g, что в точности соответствует задержке, которую потребуется на том же телефоне, чтобы проверить, если бы у него были те же данные в своем кеше уже, даже если он был кеширован по доверенности, потому что налог на мобильную задержку (телефон до башни) все еще применяется. Между тем, подключения к рабочему столу, которые имеют меньшую задержку при первом переходе, обычно в любом случае имеют более высокую пропускную способность.
Короче говоря, сейчас (2014) лучше всего встроить все скрипты, стили и шаблоны.
РЕДАКТИРОВАТЬ (МАЙ 2016)
Поскольку приложения JS продолжают расти, и некоторые из моих полезных нагрузок теперь складывают до 3+ мегабайт минимизированного кода, становится очевидным, что по крайней мере общие библиотеки больше не должны быть встроенными.