Ненавязчивый JavaScript: <script> вверху или внизу HTML-кода?


90

Недавно я прочитал манифест Yahoo " Лучшие методы ускорения работы вашего веб-сайта" . Они рекомендуют по возможности помещать включение JavaScript в конец HTML-кода.

Но где именно и когда?

Ставить перед закрытием </html>или после? И прежде всего, когда мы все же должны поместить его в <head>раздел?


Ответы:


87

Есть два варианта создания действительно ненавязчивых сценариев:

  • включение внешнего файла сценария через тег сценария в разделе заголовка
  • включение внешнего файла сценария через тег сценария в нижней части тела (до </body></html>)

Второй вариант может быть быстрее, поскольку исходное исследование Yahoo показало, что некоторые браузеры пытаются загрузить файлы сценариев, когда они попадают в тег сценария, и поэтому не загружают остальную часть страницы, пока не закончат работу. Однако, если в вашем скрипте есть «готовая» часть, которая должна выполняться, как только DOM будет готова, вам, возможно, понадобится держать ее в голове. Другая проблема - это макет - если ваш скрипт будет изменять макет страницы, вы хотите, чтобы он загружался как можно раньше, чтобы ваша страница не тратила много времени на перерисовку себя на глазах у пользователей.

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

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


13
По поводу сценария, имеющего «готовую» часть. Помещение этого скрипта в нижнюю часть тела гарантирует, что DOM готов к манипулированию, если вы поместите его в голову, вы должны обернуть его так, чтобы он ждал события DOMReady (или аналогичного)
Хуан Мендес,

4
@Juan Да, есть, но, помещая скрипт внизу, вы задерживаете событие DOMReady на время, необходимое браузеру для анализа документа и обработки элементов заголовка (200-500 мс), прежде чем он запросит этот скрипт. . В основном при загрузке первой страницы (при условии, что оттуда ее можно кэшировать). А если вложить в голову. Скорее всего, он будет готов намного быстрее. Итак, имея в виду HTML5, если скрипт должен изменить макет, когда DOM будет готов, вам теперь лучше с «асинхронным» или «отложенным» скриптом в голове.
hexalys 01

31

Никогда не бывает так резко - Yahoo рекомендует размещать сценарии непосредственно перед закрывающим </body>тегом, что создаст иллюзию того, что страница загружается быстрее при пустом кеше (поскольку сценарии не будут блокировать загрузку остальной части документа). Однако, если у вас есть код, который вы хотите запустить при загрузке страницы, он начнет выполняться только после загрузки всей страницы. Если вы поместите скрипты в <head>тег, они начнут выполняться раньше, поэтому в загруженном кэше страница будет загружаться быстрее.

Также не всегда доступна привилегия размещения скриптов внизу страницы. Если вам нужно включить встроенные скрипты в ваши представления, которые зависят от библиотеки или какого-либо другого кода JavaScript, загруженного ранее, вы должны загрузить эти зависимости в <head>тег.

В целом рекомендации Yahoo интересны, но не всегда применимы, и их следует учитывать в каждом конкретном случае.


1
Если у вас ненавязчивый javscript, у вас не будет встроенных сниппетов, в вопросе конкретно упоминается ненавязчивый.
Хуан Мендес

1
встроенные <script>теги не подразумевают навязчивого javascript.
Эран Гальперин

@ Эрик Гальперин: Что хорошего в использовании встроенных тегов скрипта, если они не навязчивы?
Хуан Мендес

4
@Juan навязчивый Javascript означает, что пользовательский интерфейс не работает без него или что он встроен в разметку. <script>Теги отделены от разметки и могут использоваться с кодом, улучшающим интерфейс, но не обязательным. Так что во встроенных <script>тегах нет ничего навязчивого .
Эран Гальперин

4
1. Меня зовут Эран, а не Эрик. 2. Если вы хотите передать данные в Javascript с серверного языка, например, в цикле, если элементы, вы можете использовать <script>теги для кодирования этих значений в переменные javascript, для использования, возможно, с встроенное редактирование или другое подобное поведение.
Эран Гальперин

22

Как уже говорили другие, поместите его перед закрытием тела HTML - теги.

На днях к нам поступило множество звонков от клиентов, которые жаловались, что их сайты работают очень медленно. Мы посетили их локально и обнаружили, что им требуется 20-30 секунд для загрузки одной страницы. Думая, что серверы работают плохо, мы вошли в систему, но и веб-серверы, и серверы sql были активны примерно на 0%.

Через несколько минут мы поняли, что не работает внешний сайт, на который мы ссылались для тегов отслеживания Javascript. Это означало , браузеры были ударять сценарий тег в головной части сайта и ждать , чтобы скачать файл сценария.

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


10
Классная история, братан :) А если серьезно, это самый убедительный аргумент, который я видел в пользу размещения тегов скриптов внизу страницы.
user271608

16

Подводя итог, основываясь на предложениях выше:

  1. Для внешних скриптов (Google Analytics, сторонние маркетинговые трекеры и т. Д.) Поместите их перед </body>тегом.
  2. Скрипты, влияющие на макет страницы, помещайте в заголовок.
  3. Для сценариев, которые полагаются на «готовность к dom» (например, jquery), рассмотрите возможность размещения раньше, </body>если у вас нет особых причин для размещения сценариев в заголовке.
  4. Если есть встроенные скрипты с зависимостями, поместите необходимые скрипты в заголовок.

6

Если вы хотите повозиться с положением своих скриптов, YSlow - отличный инструмент, который даст вам представление о том, улучшит ли он или снизит производительность. Размещение javascript в определенных положениях документа может действительно сократить время загрузки страницы.

http://developer.yahoo.com/yslow/


5

Нет, это не должно быть после, </html>поскольку это было бы недействительным. Лучшее место для размещения скриптов - прямо перед</body>

Это в основном связано с тем, что большинство браузеров перестают отображать страницу, пока проверяют предоставленный вами сценарий. Так что можно размещать неблокирующий код в любом месте страницы (в основном я думаю о вещах, которые присоединяют функции к onLoadсобытию, поскольку привязка событий происходит настолько быстро, что фактически становится бесплатной). Большой убийца здесь заключается в том, что в начале страницы вставляется некоторый скрипт рекламного сервера, который может предотвратить загрузку любой страницы до полной загрузки рекламы, что увеличивает время загрузки вашей страницы.


Знаете, если вас действительно волнует скорость, то не будет </body> или </html> - закрывающие теги для этих типов элементов необязательны. Поместите <script> в самый конец и забудьте об использовании </body> и </html> вообще.
Джим

9
Надеюсь, Джим саркастичен - во всяком случае, не прислушивайтесь к его советам. Правильно сформированный XHTML требует закрывающих тегов для каждого элемента, включая теги body и html. Если ваш код недействителен XML, вы делаете это неправильно.
Мэтт Лохкамп,

6
Нет, я не саркастичен. Взгляните на вопрос. Он определяет HTML, а не XHTML. Верно, что действительный XHTML требует этих вещей, а действительный HTML - нет. Нет абсолютно ничего плохого в том, чтобы выбрать HTML и опустить закрывающие теги для этих типов элементов.
Джим

2

Если вы поместите его внизу, он загружается в последнюю очередь, что увеличивает скорость, с которой пользователь может увидеть страницу. Он должен быть до финала, </html>иначе он не будет частью DOM.

Если же код нужен моментально, то вставьте его в голову.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.