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