Где мне помещать теги <script> в разметку HTML?
При встраивании JavaScript в документ HTML, где лучше всего разместить теги <script> и включить JavaScript? Кажется, я напоминаю, что вы не должны размещать их в разделе <head>, но размещение в начале раздела <body> тоже плохо, так как JavaScript нужно будет проанализировать до того, как страница будет полностью отрисована (или что-то в этом роде ). Похоже, это оставляет конец раздела <body> как логическое место для тегов <script>.
Итак, где является правильное место для размещения тегов <script>?
(В этом вопросе упоминается этот вопрос, в котором было предложено переместить вызовы функций JavaScript из тегов <a> в теги <script>. Я специально использую jQuery, но уместны и более общие ответы.)
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 20
Если вы используете JQuery, поместите javascript в любое удобное для вас место и используйте $(document).ready(), чтобы убедиться, что все загружено правильно, перед выполнением каких-либо функций.
Кстати, мне нравятся все мои теги скриптов в разделе <head>, так как это кажется самым чистым местом.
в голове ... э? <header>?
Обратите внимание, что использование $(document).ready() не означает, что вы можете поместить свой JavaScript в любом месте, который вам нравится - вам все равно нужно поместить его после <script src = ".../jquery.min.js">, где вы включаете jQuery, чтобы $ существовал.
Помещать теги скриптов в раздел <head> не оптимально - это задержит отображение видимой части страницы до загрузки скриптов.
Нет, @Dan, элемент header является частью содержимого документа HTML и должен встречаться один или несколько раз в теге элемента body. Тег . The head` предназначен для метаданных и данных, не относящихся к содержимому документа. В наши дни defer и async являются идеальным местом для тегов скриптов. Элементы header должны содержать только информацию, описывающую раздел документа, который следует за ними.
@ProfK, Дэн имел в виду исходный неотредактированный вопрос, когда опубликовал его более 4 лет назад. Как видите, вопрос отредактировали год спустя.
Непосредственно перед закрывающим тегом тела, как указано на
http://developer.yahoo.com/performance/rules.html#js_bottom
Put Scripts at the Bottom
The problem caused by scripts is that they block parallel downloads. The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won't start any other downloads, even on different hostnames.
Согласен с концепцией и ее объяснением. Но что произойдет, если пользователь начнет играть со страницей. Предположим, у меня есть раскрывающийся список AJAX, который начнет загружаться после того, как страница появится пользователю, но пока она загружается, пользователь нажимает на нее! А что, если «очень нетерпеливый» пользователь отправит форму?
@Hermant Старый комментарий, но вы можете сделать трюк, отключив поля по умолчанию, а затем включив их с помощью JS, когда DOM полностью загружен. Кажется, именно этим сейчас занимается Facebook.
Просто протестировал это с помощью хрома, чтобы проверить, остается ли это прежним. Это. Вы можете проверить разницу во времени загрузки страниц в ваших браузерах здесь. stevesouders.com/cuzillion
Если это лучшая практика, почему переполнение стека включает все свои теги скриптов в <head>? :-П
Могу ли я добавить его после закрывающего тега тела или это вызовет проблемы с производительностью?
В некоторых случаях, особенно на сайтах с тяжелым ajax, загрузка в head может фактически привести к более быстрому времени загрузки. См .: encosia.com/dont-let-jquerys-document-ready-slow-you-down (обратите внимание, что функция «live ()» устарела в jquery, но статья по-прежнему применяется с функцией «on ()» или «делегировать»). Загрузка в <head> также может потребоваться, чтобы гарантировать правильное поведение, как указано @Hermant. Наконец, modernizr.com/docs рекомендует размещать свои скрипты в <head> по причинам, изложенным на его сайте.
В вашей цитате ничего не говорится о теге body. Нельзя ли их разместить за тегом body?
Этот совет устарел с тех времен, когда контент поступал только из HTML. Начало страницы слишком сложно, чтобы делать такое общее заявление. Он по-прежнему работает, если вашей странице не нужен какой-либо код для выполнения для первоначального рендеринга, и если он не будет блокировать базовую интерактивность. Однако, если вы используете что-то вроде vue без какого-либо рендеринга на стороне сервера, размещение вашего основного скрипта в конце ставит его в приоритет ниже всех изображений и CSS, что заставляет его загружаться и запускаться намного позже, чем следовало бы.
Обычный (и широко распространенный) ответ - «внизу», потому что тогда вся DOM будет загружена до того, как что-либо сможет начать выполняться.
Есть несогласные по разным причинам, начиная с имеющейся практики намеренно начинать выполнение с события загрузки страницы.
XHTML не будет проверять, находится ли сценарий где-либо, кроме элемента head., оказывается, может быть везде.
Вы можете отложить выполнение с помощью чего-то вроде jQuery, поэтому не имеет значения, где он размещен (за исключением небольшого снижения производительности во время синтаксического анализа).
XHTML будет проверяться с помощью тегов сценария в теле, как строгих, так и переходных. Однако теги стиля могут быть только в голове.
В зависимости от сценария и его использования наилучшим возможным (с точки зрения загрузки страницы и времени рендеринга) может быть не использование стандартного тега <script> как таковой, а динамическое запускание загрузки сценария в асинхронном режиме.
Существует несколько различных методов, но наиболее простой - использовать document.createElement («скрипт») при запуске события window.onload. Затем скрипт загружается первым, когда сама страница отрисовывается, что не влияет на время, в течение которого пользователь должен ждать появления страницы.
Это, естественно, требует, чтобы сам скрипт не требовался для рендеринга страницы.
Для получения дополнительной информации см. Сообщение Связывание асинхронных скриптов Стива Содерса (создателя YSlow, но теперь в Google).
Стандартный совет, продвигаемый Yahoo! Команда Exceptional Performance должна поместить теги <script> в конец тела документа, чтобы они не блокировали рендеринг страницы.
Но есть несколько новых подходов, которые обеспечивают лучшую производительность, как описано в этот ответ о времени загрузки файла JavaScript Google Analytics:
There are some great slides by Steve Souders (client-side performance expert) about:
- Different techniques to load external JavaScript files in parallel
- their effect on loading time and page rendering
- what kind of "in progress" indicators the browser displays (e.g. 'loading' in the status bar, hourglass mouse cursor).
Для меня имеет смысл включить сценарий после HTML. Потому что в большинстве случаев мне нужно, чтобы Dom загрузился, прежде чем я выполню свой скрипт. Я мог бы поместить это в тег заголовка, но мне не нравятся все накладные расходы слушателя загрузки документа. Я хочу, чтобы мой код был коротким, понятным и легко читаемым.
Я слышал, что старые версии сафари были нестандартными при добавлении вашего скрипта вне тега заголовка, но я говорю, кого это волнует. Я не знаю никого, кто использует это старое дерьмо, не так ли?
Кстати, хороший вопрос.
В зависимости от ситуации, если вы загружаете скрипт, необходимый для стилизации вашей страницы / использования действий на вашей странице (например, щелчка кнопки), вам лучше разместить его вверху. Если ваш стиль на 100% состоит из CSS и у вас есть все резервные варианты для действий кнопок, вы можете разместить его внизу.
Или, что лучше всего (если это не вызывает беспокойства), вы можете создать модальное окно загрузки, разместить свой javascript внизу страницы и заставить его исчезнуть, когда загрузится последняя строка вашего скрипта. Таким образом вы можете избежать использования пользователями действий на вашей странице до загрузки скриптов. А также избегайте неправильной укладки.
Вот что происходит, когда браузер загружает веб-сайт с тегом <script> на нем:
- Получить HTML-страницу (например, index.html)
- Начните разбор HTML
- Парсер обнаруживает тег
<script>, ссылающийся на внешний файл сценария. - Браузер запрашивает файл сценария. Тем временем парсер блокирует и прекращает анализ другого HTML на вашей странице.
- Через некоторое время скрипт загружается и впоследствии выполняется.
- Парсер продолжает синтаксический анализ остальной части HTML-документа.
Шаг № 4 вызывает плохой пользовательский опыт. Ваш веб-сайт практически перестает загружаться, пока вы не загрузите все скрипты. Если есть что-то, что пользователи ненавидят, так это ожидание загрузки веб-сайта.
Почему это вообще происходит?
Любой скрипт может вставлять собственный HTML-код с помощью document.write() или других манипуляций с DOM. Это означает, что синтаксический анализатор должен дождаться загрузки и выполнения сценария, прежде чем он сможет безопасно проанализировать остальную часть документа. Ведь скрипт мог вставил в документ собственный HTML.
Однако большинство разработчиков JavaScript больше не манипулируют DOM пока, загружаемым документом. Вместо этого они ждут, пока документ будет загружен, прежде чем изменять его. Например:
<!-- index.html -->
<html>
<head>
<title>My Page</title>
<script src = "my-script.js"></script>
</head>
<body>
<div id = "user-greeting">Welcome back, user</div>
</body>
</html>
Javascript:
// my-script.js
document.addEventListener("DOMContentLoaded", function() {
// this function runs when the DOM is ready, i.e. when the document has been parsed
document.getElementById("user-greeting").textContent = "Welcome back, Bart";
});
Поскольку ваш браузер не знает, что my-script.js не будет изменять документ, пока он не будет загружен и запущен, синтаксический анализатор прекращает синтаксический анализ.
Устаревшая рекомендация
Старый подход к решению этой проблемы заключался в размещении тегов <script> в нижней части вашего <body>, потому что это гарантирует, что синтаксический анализатор не заблокируется до самого конца.
У этого подхода есть своя проблема: браузер не может начать загрузку скриптов, пока не будет проанализирован весь документ. Для больших веб-сайтов с большими скриптами и таблицами стилей возможность как можно скорее загрузить скрипт очень важна для производительности. Если ваш сайт не загружается в течение 2 секунд, люди перейдут на другой сайт.
В оптимальном решении браузер начал бы загрузку ваших скриптов как можно скорее, одновременно анализируя остальную часть вашего документа.
Современный подход
Сегодня браузеры поддерживают атрибуты async и defer в скриптах. Эти атрибуты сообщают браузеру, что можно безопасно продолжить синтаксический анализ во время загрузки скриптов.
асинхронный
<script src = "path/to/script1.js" async></script>
<script src = "path/to/script2.js" async></script>
Скрипты с атрибутом async выполняются асинхронно. Это означает, что скрипт запускается сразу после загрузки, при этом браузер не блокируется. Это означает, что сценарий 2 может быть загружен и выполнен до сценария 1.
Согласно http://caniuse.com/#feat=script-async, 97,78% всех браузеров поддерживают это.
отложить
<script src = "path/to/script1.js" defer></script>
<script src = "path/to/script2.js" defer></script>
Скрипты с атрибутом defer выполняются по порядку (т.е. сначала скрипт 1, затем скрипт 2). Это также не блокирует браузер.
В отличие от асинхронных сценариев, сценарии отсрочки выполняются только после загрузки всего документа.
Согласно http://caniuse.com/#feat=script-defer, 97,79% всех браузеров поддерживают это. 98,06% поддерживают хотя бы частично.
Важное замечание о совместимости браузеров: в некоторых случаях IE <= 9 может выполнять отложенные скрипты не по порядку. Если вам нужна поддержка этих браузеров, сначала прочтите это!
Заключение
Текущее состояние дел состоит в том, чтобы помещать сценарии в тег <head> и использовать атрибуты async или defer. Это позволяет загружать ваши скрипты как можно скорее, не блокируя ваш браузер.
Хорошо то, что ваш веб-сайт должен по-прежнему правильно загружаться в 2% браузеров, которые не поддерживают эти атрибуты, в то время как остальные 98% ускоряются.
Используя этот метод, как лучше всего запустить javascript после загрузки всех файлов js? В настоящее время я использую событие onload внутри открывающего тега тела.
Есть ли у кого-нибудь мысли по поводу такого подхода? feedthebot.com/pagespeed/defer-loading-javascript.html
Я не могу представить себе множество сценариев, в которых DOM не изменяется с помощью JavaScript. Может ли кто-нибудь привести пример сценария, который будет использовать async?
Также, когда на функцию ссылается обычно загружаемый JavaScript из загруженного файла JavaScript async, тогда он должен дождаться его загрузки, верно? Кажется, это дает мне неперехваченную ошибку ссылки.
Обратите внимание, что IE <10 может чередовать выполнение сценариев при использовании defer, поэтому все еще не является отказоустойчивым решением - caniuse.com/#search=defer (обновленный ответ, поскольку я думаю, что это важно)
@Jori Обычная практика - загружать ваш javascript как можно скорее (и не блокировать через async) и откладывать любые манипуляции с DOM до отправки события «DOMContentLoaded».
Я удивлен, что никто не процитировал объяснение Google ... developers.google.com/speed/docs/insights/BlockingJS
Похоже, что отсрочка не решает эту проблему в некоторых браузерах, см. stevesouders.com/hpws/rule-js-bottom.php
Я не понимаю, что касается DOM, а что нет. Вы можете уточнить? Безопасно ли выполнять асинхронную загрузку чего-то вроде jquery.js?
@Doug Например, document.write работает с домом. Вопрос не в том, что сценарий если манипулирует dom, а в когда. Пока все манипуляции с dom происходят после срабатывания события domready, все в порядке. jQuery - это библиотека, которая сама по себе не управляет (или не должна) управлять dom.
Этот ответ вводит в заблуждение. Современные браузеры не прекращают синтаксический анализ, когда достигают синхронного тега скрипта, который может повлиять на HTML, они просто прекращают рендеринг / выполнение и продолжают оптимистичный синтаксический анализ, чтобы начать загрузку других ресурсов, которые, вероятно, будут запрошены впоследствии, если HTML не будет затронут.
Возможно, у меня есть ссылка на «Если ваш веб-сайт не загружается в течение 2 секунд, люди перейдут на другой веб-сайт».
Я предполагаю, что особенно при получении скриптов из другого домена, такого как CDN или субдомен, они должны быть в порядке в <head>. Для меня это лучше (я просто использую субдомен), а липкий заголовок, например, и другие вещи работают уже во время загрузки, которая не кажется медленнее. Кстати, Facebook тоже загружает тонны скриптов из <head> ;-) Ура
Я попытался найти ссылку, показывающую, что если сценарии в голове асинхронны, голова гарантированно будет готова (они все загружены) до того, как будет загружено тело readyState. Я не могу найти такую ссылку, но на основе водопадов из Chrome, Firefox и IE11 во всех протестированных случаях тело загружается после завершения загрузки всего асинхронного javascript. Таким образом, существующие функции «выполнить в домене готовы» кажутся безопасными. Я просто не нашел ссылок, которые есть всегда.
Как вы справляетесь со случаем, когда фреймворк веб-приложения имеет «основной» файл с <head>, который загружает скрипты, полезные для всех «дочерних» шаблонов (например, JQuery), но когда отдельные файлы нуждаются в специфичном для шаблона javascript?
Почему атрибуты async и defer нигде не используются? Я имею в виду, что я просмотрел множество источников HTML из Интернета и нигде не вижу атрибутов async и defer. ...?
Как можно сравнить динамическое создание тега скрипта и его добавление? например {var se = document.createElement ('сценарий'); se.type = 'текст / javascript'; se.src = "//code.com/myscript.js"; var s = document.getElementsByTagName ('сценарий') [0]; s.parentNode.insertBefore (se, s); } Это похоже на использование defer? Кроме того, что, если я добавлю "se.async = true;" там? Я заметил, что сторонние поставщики используют такой подход.
@Bart А что, если я вставлю скрипт в голову - и он скажет, что регистрирует обработчик для нажатия кнопки. Поскольку кнопка создается в теле, смогу ли я зарегистрировать такой обработчик?
@Onato, помогают ли defer и async, если вы используете http2?
Отличный ответ. Есть ли такие рекомендации по элементу link / для таблиц стилей? Нашел вот этот codepen.io/tigt/post/async-css-without-javascript; но меня удивляет, что проблема загрузки внешних файлов будет решаться отдельно по типу / использованию файла, а не один раз для всего внешнего контента.
Хороший ответ. Могу ли я предположить, что размещение script с defer лучше поместить перед внешним тегом css style внутри головы, чтобы получить максимальную выгоду, иначе, если он будет помещен перед </body>, браузер не сможет запросить мой сценарий defer до тех пор, пока не будет загружен файл css .. Я прав ?
Этому посту уже 3 года. Полагаю, поддержка браузеров должна быть сейчас выше 90%?
этот ответ тоже устарел, использование атрибутов type в тегах скрипта считается бесполезным. Они не нужны и просто педантичны
Как я ответил ниже, «модули» ES6 во многих случаях предлагают лучшую альтернативу скриптам в современных браузерах.
HTML-руководство Введение в HTML> Что в голове? Метаданные в HTML> Применение CSS и JavaScript к HTML от Mozilla также может быть хорошим местом для того, чтобы увидеть, какие передовые практики в настоящее время установлены и фактически соблюдаются, поскольку оно должно обучать последним изменениям в стандартах, которым помогает эта организация. (Я только что отправил правку в соответствии с этим ответом. Не стесняйтесь его улучшать.)
@gman - Re: "использование атрибутов типа в тегах скрипта считается пустой тратой". Боюсь, вы действительно стали жертвой устаревшего Документ о передовой практике Google. См. Эта проблема
@SlawomirBrzezinski, все равно ставить type = "javascript" на type = "text/javascript" - пустая трата времени. Когда я вижу это, я обычно понимаю, что знания этого человека устарели. Конечно, type = "module" новый и имеет смысл, но другие нет.
@gman - я вижу, что вы добавили это до автора удалил эти атрибуты, в то время как я видел только текущее состояние, которое не использовало type на всей этой странице, кроме модулей, отсюда и мой вывод. Извинения.
Неблокирующие теги скрипта можно разместить где угодно:
<script src = "script.js" async></script>
<script src = "script.js" defer></script>
<script src = "script.js" async defer></script>
- Скрипт
asyncбудет выполняться асинхронно, как только он станет доступен - Скрипт
deferвыполняется, когда документ закончил разбор - Сценарий
async deferвозвращается к отложенному поведению, если асинхронный режим не поддерживается
Такие скрипты будут выполняться асинхронно / после того, как документ будет готов, что означает, что вы не можете этого сделать:
<script src = "jquery.js" async></script>
<script>jQuery(something);</script>
<!--
* might throw "jQuery is not defined" error
* defer will not work either
-->
Или это:
<script src = "document.write(something).js" async></script>
<!--
* might issue "cannot write into document from an asynchronous script" warning
* defer will not work either
-->
Или это:
<script src = "jquery.js" async></script>
<script src = "jQuery(something).js" async></script>
<!--
* might throw "jQuery is not defined" error (no guarantee which script runs first)
* defer will work in sane browsers
-->
Или это:
<script src = "document.getElementById(header).js" async></script>
<div id = "header"></div>
<!--
* might not locate #header (script could fire before parser looks at the next line)
* defer will work in sane browsers
-->
При этом асинхронные сценарии предлагают следующие преимущества:
- Параллельная загрузка ресурсов:
Браузер может загружать таблицы стилей, изображения и другие сценарии параллельно, не дожидаясь загрузки и выполнения сценария. - Независимость от исходного порядка:
Вы можете размещать скрипты внутри head или body, не беспокоясь о блокировке (полезно, если вы используете CMS). Однако порядок выполнения все еще имеет значение.
Проблемы с порядком выполнения можно обойти, используя внешние сценарии, поддерживающие обратные вызовы. Многие сторонние API-интерфейсы JavaScript теперь поддерживают неблокирующее выполнение. Вот пример асинхронная загрузка API Карт Google.
Это правильный ответ на сегодняшний день - использование этого подхода означает, что ваши виджеты будут оставаться самодостаточными, и нет необходимости использовать причудливую логику включения <head>.
Я не понимаю, почему вы не можете использовать async или defer при включении jQuery, как вы указываете во втором блоке: <script src = "jquery.js" async></script>. Вы можете объяснить почему? Я думал, что мне нужен тег async для повышения производительности - согласно принятому ответу - чтобы моя страница могла загружаться, даже когда jQuery все еще загружается]. Спасибо!
@elbow В 99% случаев за <script src=jquery.js> следуют блоки $(function(){ ... }) где-то на странице. Асинхронная загрузка не гарантирует, что jQuery будет загружен в тот момент, когда браузер попытается проанализировать эти блоки, поэтому это вызовет ошибку $ не определено (вы можете не получить ошибку, если jQuery был загружен из кеша). Я ответил на вопрос об асинхронной загрузке jQuery и сохранении $(function(){ ... }). Я посмотрю, смогу ли я его найти, или вы можете посмотреть на этот вопрос: stackoverflow.com/q/14811471/87015
@SalmanA Спасибо! Да, я попадаю в эти 99%. Сначала мне нужна библиотека jquery для загрузки, тогда - мои оставшиеся скрипты .js. Когда я объявляю async или defer в теге сценария jquery lib, мои сценарии .js не работают. Я думал, что $(function(){ ... }) защищает это - думаю, нет. Текущее решение: Я не добавляю defer или async в скрипт библиотеки jquery, но я добавляю async в мои последующие скрипты .js. Примечание: причина, по которой я делаю это любой, состоит в том, чтобы порадовать Google Page Speed. Еще раз спасибо за помощь! Любой другой совет приветствуется. (Или ссылку на ваш предыдущий ответ). :)
@elbow См. stackoverflow.com/a/21013975/87015, это даст вам только идею, но не полное решение. Вместо этого вы можете искать «библиотеки асинхронного загрузчика jquery».
Скрипт блокирует загрузку DOM, пока она не будет загружена и запущена.
Если вы разместите скрипты в конце <body>, вся DOM получит шанс загрузить и отобразить (страница будет «отображаться» быстрее). <script> будет иметь доступ ко всем этим элементам DOM.
С другой стороны, размещение его после запуска <body> или выше приведет к выполнению скрипта (где все еще нет элементов DOM).
Вы включаете jQuery, что означает, что вы можете разместить его где угодно и использовать .готовы()
Если вы по-прежнему очень заботитесь о поддержке и производительности в IE <10, лучше ВСЕГДА делать теги сценария последними тегами вашего тела HTML. Таким образом, вы уверены, что остальная часть DOM загружена, и вы не будете блокировать и выполнять рендеринг.
Если вас больше не волнует IE <10, вы можете поместить свои скрипты в заголовок документа и использовать
defer, чтобы гарантировать, что они запускаются только после загрузки вашего DOM (<script type = "text/javascript" src = "path/to/script1.js" defer></script>). Если вы по-прежнему хотите, чтобы ваш код работал в IE <10, не забудьте даже обернуть свой код вwindow.onload!
В принятом ответе это называется «устаревшей рекомендацией». Если вы все еще имеете в виду это, вам, вероятно, следует предоставить ссылку, чтобы поддержать это.
<script src = "myjs.js"></script>
</body>
Тег скрипта следует использовать всегда перед файлом тело близко или Внизу в HTML.
Страница загрузится с html и css, а позже загрузится js.
проверьте это, если требуется: http://stevesouders.com/hpws/rule-js-bottom.php
Это действительно ответ на вопрос. Мне было интересно, почти все опубликованные примеры никогда не давали надлежащего визуального контекста «конца страницы».
Этот ответ вводит в заблуждение и, скорее всего, неверен. Статьи в Google и MDN предполагают, что синхронный JS (как в данном случае) всегда блокирует построение и синтаксический анализ DOM, что приведет к задержке первого рендеринга. Следовательно, вы не можете видеть содержимое страницы до тех пор, пока файл JS не будет извлечен и не завершит выполнение, независимо от того, где вы помещаете свой файл JS в HTML-документ, если он синхронный.
Он также ссылается на моменты, высказанные в 2009 году и больше не актуальные.
Вы действительно имели в виду "иначе вы сможете увидеть содержимое перед загрузкой файла js, и это плохо?"
Я думаю, это зависит от исполнения веб-страницы. Если страница, которую вы хотите отобразить, не может отображаться должным образом без предварительной загрузки JavaScript, вам следует сначала включить файл JavaScript. Но если вы можете отображать / отображать веб-страницу без первоначальной загрузки файла JavaScript, вам следует поместить код JavaScript внизу страницы. Потому что он будет имитировать быструю загрузку страницы, и с точки зрения пользователя может показаться, что эта страница загружается быстрее.
Вы можете разместить большинство ссылок <script> в конце <body>,
, но если на вашей странице есть активные компоненты, которые используют внешние скрипты,
тогда их зависимость (файлы js) должна быть перед этим (в идеале в теге head).
Лучше всего писать код JavaScript в конце документа после или прямо перед тегом </body>, чтобы сначала загрузить документ, а затем выполнить код js.
<script> ... your code here ... </script>
</body>
И если вы напишете в JQuery, в главном документе может быть следующее, и оно будет выполняться после загрузки документа:
<script>
$(document).ready(function(){
//your code here...
});
</script>
выкидывает SyntaxError
Ваш ответ не был неправильным, но он остро нуждался в обновлении.
Включение скриптов в конце в основном используется там, где сначала отображается контент / стили веб-сайта.
включение сценариев в заголовок загружает сценарии раньше и может использоваться до загрузки всего веб-сайта.
если скрипты введены наконец, проверка будет происходить только после загрузки всех стилей и дизайна, что не ценится для быстро реагирующих веб-сайтов.
Современный подход в 2019 году - использование скриптов типа модуля ES6..
<script type = "module" src = "..."></script>
По умолчанию модули загружаются асинхронно и откладываются. то есть вы можете разместить их где угодно, и они будут загружаться параллельно и выполняться, когда страница завершит загрузку.
Здесь описаны различия между скриптом и модулем:
https://stackoverflow.com/a/53821485/731548
Здесь описывается выполнение модуля по сравнению со сценарием:
https://developers.google.com/web/fundamentals/primers/modules#defer
Здесь показана поддержка:
https://caniuse.com/#feat=es6-module
хорошая информация для добавления в базу знаний
Просто обратите внимание, что это не сработает, если вы просто пробуете что-то в своей локальной файловой системе без сервера. По крайней мере, в Chrome вы получаете ошибку перекрестного происхождения при попытке загрузить js из HTML, даже если они оба имеют одно и то же происхождение, вашу файловую систему.
Лучшее место для размещения тега <script> - перед закрытием тега </body>, поэтому его загрузка и выполнение не блокируют браузер для синтаксического анализа html в документе,
Также загрузка файлов js извне имеет свои преимущества вроде будет кешируется браузерами, а может ускорить загрузку страницы, это разделяет код HTML и JavaScript и помочь лучше управлять базой кода.
но современные браузеры также поддерживают некоторые другие оптимальные способы, такие как async и defer, для загрузки внешних файлов javascript.
Асинхронный и отложенный
Обычно выполнение HTML-страницы начинается построчно. Когда обнаруживается внешний элемент JavaScript, синтаксический анализ HTML останавливается до тех пор, пока JavaScript не будет загружен и готов к выполнению. Это нормальное выполнение страницы можно изменить с помощью атрибутов defer и async.
Defer
Когда используется атрибут defer, JavaScript загружается параллельно с синтаксическим анализом HTML, но будет выполняться только после завершения полного анализа HTML.
<script src = "/local-js-path/myScript.js" defer></script>
Async
Когда используется атрибут async, JavaScript загружается, как только встречается сценарий, и после загрузки он будет выполняться асинхронно (параллельно) вместе с анализом HTML.
<script src = "/local-js-path/myScript.js" async></script>
Когда использовать какие атрибуты
- Если ваш сценарий не зависит от других сценариев и является модульным, используйте
async. - Если вы загружаете сценарии 1 и 2 с помощью
async, оба будут работать с
. параллельно вместе с парсингом HTML, как только они скачиваются
и доступно. - Если ваш сценарий зависит от другого сценария, используйте
deferдля обоих: - Когда script1 и script2 загружаются в указанном порядке с
defer, тогда script1 гарантированно выполнится первым, - Затем script2 будет выполняться после того, как script1 будет полностью выполнен.
- Это необходимо сделать, если сценарий 2 зависит от сценария 1.
- Если ваш сценарий достаточно мал и зависит от другого сценария
типа
async, затем используйте свой сценарий без атрибутов и поместите его прежде всего скриптыasync.
ссылка: knowledgehills.com
Вы можете добавить код JavaScript в документ HTML, используя специальный тег HTML <script>, который обтекает код JavaScript.
Тег <script> может быть размещен в разделе <head> вашего HTML, в разделе <body> или после закрывающего тега </body>, в зависимости от того, когда вы хотите загрузить JavaScript.
Как правило, код JavaScript может находиться внутри раздела документа <head>, чтобы они содержались вне основного содержимого вашего HTML-документа.
Однако, если ваш сценарий должен запускаться в определенной точке макета страницы - например, при использовании document.write для генерации контента - вы должны поместить его в точку, где он должен быть вызван, обычно в разделе <body>.
Если вы также просто ищете простое решение и используете какой-либо генератор на стороне сервера, такой как Jekyll, я рекомендую вместо этого включить сценарий. все намного проще!