Я хотел бы знать, когда мне следует включать внешние скрипты или писать их встроенными в HTML-код с точки зрения производительности и простоты обслуживания.
Какова общая практика для этого?
Реальный сценарий - у меня есть несколько html-страниц, которым требуется проверка формы на стороне клиента. Для этого я использую плагин jQuery, который я включаю на все эти страницы. Но вопрос в том, могу ли я:
- написать фрагменты кода, которые настраивают этот скрипт встроенным?
- включить все биты в один файл, который используется всеми этими HTML-страницами?
- включать каждый бит в отдельный внешний файл, по одному для каждой HTML-страницы?
Спасибо.
javascript
html
performance
frontend
Дэн Бурзо
источник
источник
Ремонтопригодность, безусловно, является причиной сохранения их внешними, но если конфигурация однострочная (или, как правило, короче, чем накладные расходы HTTP, которые вы получили бы, сделав эти файлы внешними), с точки зрения производительности лучше сохранить их встроенными. Всегда помните, что каждый HTTP-запрос создает некоторые накладные расходы с точки зрения времени выполнения и трафика.
Естественно, все это становится неактуальным в тот момент, когда ваш код длиннее пары строк и не привязан к одной странице. В тот момент, когда вы захотите повторно использовать этот код, сделайте его внешним. Если нет, посмотрите на его размер и решите.
источник
Экстернализация javascript - одно из правил производительности Yahoo: http://developer.yahoo.com/performance/rules.html#external
Хотя жесткое правило, согласно которому вы всегда должны экстернализировать скрипты, обычно будет хорошим выбором, в некоторых случаях вы можете захотеть встроить некоторые скрипты и стили. Однако вам следует встраивать только те вещи, которые, как вы знаете, улучшат производительность (потому что вы это измерили).
источник
Если вы заботитесь только о производительности, большинство советов в этом потоке совершенно неверны и становятся все более и более неправильными в эпоху SPA, когда мы можем предположить, что страница бесполезна без кода JS. Я провел бесчисленное количество часов, оптимизируя время загрузки страницы SPA и проверяя эти результаты в разных браузерах. Повсеместно повышение производительности за счет повторной оркестровки вашего html может быть весьма значительным.
Чтобы добиться максимальной производительности, вы должны думать о страницах как о двухступенчатых ракетах. Эти две стадии примерно соответствуют
<head>и<body>фазы, но думать о них вместо того, чтобы, как<static>и<dynamic>. Статическая часть - это в основном строковая константа, которую вы вставляете в канал ответа так быстро, как только можете. Это может быть немного сложно, если вы используете много промежуточного программного обеспечения, которое устанавливает файлы cookie (их необходимо установить перед отправкой содержимого http), но в принципе он просто очищает буфер ответа, надеюсь, перед тем, как перейти к некоторому шаблонному коду (razor, php, и т. д.) на сервере. Это может показаться трудным, но я просто объясняю это неправильно, потому что это почти тривиально. Как вы уже догадались, эта статическая часть должна содержать весь встроенный и минифицированный javascript. Это будет выглядеть примерно такПоскольку отправка этой части по сети почти ничего не стоит, вы можете ожидать, что клиент начнет получать ее где-то около 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+ мегабайт минифицированного кода, становится очевидным, что по крайней мере общие библиотеки больше не должны быть встроены.
источник
Я думаю, что конкретный случай для одной страницы, короткий сценарий является (единственным) оправданным случаем для встроенного сценария
источник
На самом деле, есть довольно хороший случай использовать встроенный javascript. Если js достаточно мал (однострочный), я предпочитаю встроенный javascript из-за двух факторов:
jQueryвы можете использовать методыliveили,delegateчтобы обойти это, но я считаю, что, если js достаточно мал, предпочтительнее просто поместить его в строку.источник
Еще одна причина, по которой вы всегда должны использовать внешние сценарии, - это упрощение перехода на политику безопасности контента (CSP) . По умолчанию CSP запрещает все встроенные скрипты, что делает ваш сайт более устойчивым к XSS-атакам.
источник
Я бы посмотрел на требуемый код и разделил его на столько отдельных файлов, сколько нужно. Каждый файл js будет содержать только один «логический набор» функций и т. Д., Например. один файл для всех функций, связанных с входом в систему.
Затем при разработке сайта на каждой странице html вы включаете только те, которые необходимы. Когда вы запускаете свой сайт, вы можете оптимизировать, объединив каждый файл js, который нужен странице, в один файл.
источник
Единственная защита, которую я могу предложить для встроенного javascipt, заключается в том, что при использовании строго типизированных представлений с .net MVC вы можете ссылаться на переменные С # в середине javascript, которые я нашел полезными.
источник
Три соображения:
источник
Внешние скрипты также легче отлаживать с помощью Firebug. Мне нравится модульное тестирование моего JavaScript и иметь все внешние подсказки. Я ненавижу видеть JavaScript в коде PHP и HTML, мне это кажется большим беспорядком.
источник
Что касается сохранения внешнего кода JavaScript:
ASP.NET 3.5SP1 недавно представил функциональность для создания ресурса Composite script (слияние нескольких файлов js в один). Еще одно преимущество этого заключается в том, что когда сжатие веб-сервера включено, загрузка одного файла немного большего размера будет иметь лучший коэффициент сжатия, чем многие файлы меньшего размера (также меньше накладных расходов HTTP, двустороннего трафика и т. Д.). Я предполагаю, что это позволяет сэкономить на начальной загрузке страницы, после чего включается кеширование браузера, как упоминалось выше.
Помимо ASP.NET, этот скринкаст более подробно объясняет преимущества: http://www.asp.net/learn/3.5-SP1/video-296.aspx
источник
Еще одно скрытое преимущество внешних скриптов заключается в том, что вы можете легко запускать их с помощью средства проверки синтаксиса, такого как jslint . Это может спасти вас от множества душераздирающих и труднообнаруживаемых ошибок IE6.
источник
В вашем сценарии это звучит так, как будто запись внешнего материала в один файл, совместно используемый страницами, будет вам полезна. Я согласен со всем сказанным выше.
источник
Во время раннего прототипирования держите свой код встроенным, чтобы ускорить итерацию, но обязательно сделайте его внешним к тому моменту, когда вы дойдете до производства.
Я бы даже осмелился сказать, что если вы не можете разместить весь свой Javascript извне, значит, у вас в руках плохой дизайн, и вам следует реорганизовать свои данные и скрипты.
источник
Google включил время загрузки в свои измерения ранжирования страниц, если вы много встраиваете, паукам потребуется больше времени, чтобы сканировать вашу страницу, это может повлиять на рейтинг вашей страницы, если вам нужно много включить. в любом случае разные стратегии могут повлиять на ваш рейтинг.
источник
хорошо, я думаю, что вы должны использовать встроенный при создании одностраничных веб-сайтов, поскольку скрипты не нужно будет совместно использовать на нескольких страницах
источник
Всегда старайтесь использовать внешние JS, так как встроенный JS всегда сложно поддерживать.
Более того, профессионально требуется, чтобы вы использовали внешний js, поскольку большинство разработчиков рекомендуют использовать js извне.
Сам использую внешние js.
источник