JQuery: переместить JavaScript в нижнюю часть страницы?
Мы разрабатываем большие приложения ASP.NET с множеством динамически создаваемых страниц, содержащих элементы управления ASCX. Мы везде используем jQuery.
Я читал, что имеет смысл переместить встроенный код JavaScript в нижнюю часть страницы, так как это может задержать загрузку страницы, если она включена «слишком рано».
Мой вопрос сейчас: Есть ли в этом смысл при работе с jQuery?
Большая часть кода выполняется в обработчике готовности, поэтому я ожидаю, что это не замедлит загрузку страницы. В моем случае несколько битов и частей У ASCX есть собственный jQuery Usercontrols, и было бы нелегко переместить все это вниз на отображаемой странице.
Есть ли что-нибудь еще, что вы надеялись увидеть в ответах? Похоже, стыдно оставлять такую нить ... :-)
Когда я нашел эту тему, я искал, как заставить ASP.NET ScriptManager разместить ссылки js внизу страницы. Похоже на то, что вам нужно, если у вас есть код, использующий это.
После публикации моего последнего комментария я нашел этот omaralzabir.com/…, где у него есть решение, использующее фильтр, чтобы вытащить теги сценария из ответа и добавить их в конце. Нужно было бы увидеть, является ли это практическим решением. Страницы, загруженные ViewState, могут работать медленнее.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 4
Вы можете смоделировать различные способы упорядочивания JavaScript в Cuzillion, чтобы увидеть, как это влияет на загрузку страницы.
Смотрите Примеры и это сообщение в блоге для примеров того, как порядок элементов страницы может повлиять на скорость.
В большинстве случаев причина перемещения JavaScript в нижнюю часть страницы состоит в том, чтобы убедиться, что любые элементы DOM, на которые может ссылаться JavaScript, были созданы до запуска JavaScript. Это также гарантирует, что у страницы будет время для рендеринга перед запуском любого JavaScript.
В этом случае я бы не стал беспокоиться о перемещении JavaScript вниз по странице.
это не правда. Причина, по которой он находится внизу, заключается в том, чтобы содержимое страницы могло загружаться первым, и вы не оставляете пользователя, смотрящего на пустой экран, пока загружается 200 КБ скриптов.
Скотт, это самая очевидная (и, следовательно, самая распространенная) причина - правда. Однако, как указано на плакате, доступность обработчиков document.ready делает это не проблемой. Остается проблема с производительностью загрузки страницы. Никф совершенно прав.
Вы не можете манипулировать DOM в любом случае (безопасно) до того, как страница OnLoad будет запущена, поскольку она вызовет исключения в некоторых браузерах ... Так что это полностью ложное утверждение ... (извините, -1, мой первый ...)
Хммм, тогда есть аргумент в пользу сжатия скриптов и связывания с ними, вместо того, чтобы помещать их в строку.
Рекомендуется размещать сценарии в конце HTML, поскольку загрузка и выполнение сценариев происходит последовательно (по одному сценарию за раз) и при этом полностью блокирует загрузку и анализ изображений и файлов CSS.
Большие / запаздывающие / медленно работающие скрипты в верхней части страницы могут вызывать ненужную задержку при загрузке и рендеринге содержимого / макета страницы.
Размер скрипта (время загрузки) и сложность (время выполнения (обход dom и т. д.)) Имеют значение, но, что более важно, гораздо большее значение имеет количество отдельных HTTP-запросов <script> (чем меньше запросов, тем лучше).
Использование обработчика «document.ready» уменьшает задержку, вызванную медленным выполнением, но по-прежнему оставляет проблему последовательных накладных расходов HTTP.
Рекомендуемая литература: Высокопроизводительные веб-сайты Нейта Кекли.
Напомним, что параллелизм - это нормально. Скрипты не обязательно лежат на том же сервере, что и HTML, CSS и изображения. Кроме того, если браузер чувствует, что трубки забиты, он просто не может запросить скрипт. Чем раньше браузер получит информацию о скрипте, тем быстрее он сможет поставить его в очередь / потеснить.
Скрипты блокируют загрузку других объектов - вне зависимости от того, на каком сервере они лежат. Прочтите перформанс-литературу. Я возражаю против голосования, кстати.
@strager: «если браузер чувствует, что трубки забиты, он просто не может запросить скрипт». Хотите уточнить? Я никогда не видел этой функции ни в одном браузере. (Браузер должен проанализировать страницу и составить список дополнительных ресурсов (изображений, стилей, скриптов) для загрузки. НЕТ решать браузеру: «О, мне просто Чувствовать не нравится загружать который». )
@Piskvor, под этим, я думаю, я имел в виду (это было '08 ...) браузер может задерживать запрос до более позднего времени (в очереди) из-за слишком большого количества запросов.
@strager: Действительно, в большинстве браузеров есть ограничения на одновременную загрузку; но затем выполнение скрипта (и во многих браузерах рендеринг страницы) также откладывается (как говорится в ответе @Már Örlygsson и в связанной статье).
Когда вы включаете JS, загрузка страницы с этого момента будет отложена из-за того, что файл JS может содержать оператор «document.write».
Это означает, что вся страница перестанет отображаться с момента, когда вы включаете свои файлы JS и заставляете браузер становиться «белым» или что-то в этом роде (по крайней мере, не отображать остальную часть страницы), поэтому короткий ответ - Определенно да ...!
(Более длинный ответ - «вероятно» с вероятностью 99%)
Как и в случае с перемещением включения JS (а также встроенного JS, который вы не должны использовать BTW) в самый низ ...
При этом сказано, что если вы используете ASP.NET, вам следует использовать не jQuery, а Ра-Аякс, в который, кстати, включены все эти «лучшие практики», автоматически включенные для вас ...
Я знаю, что на данный момент это старый пост, и он мог быть действительным в то время, но, судя по тому факту, что проект веб-сайта шаблона в Visual Studio 2010 включает jQuery, нет никаких причин препятствовать использованию jQuery в сочетании с. СЕТЬ.
Есть ли причина, по которой ваши готовые звонки тоже не во внешнем файле? Это гораздо более управляемо, чем иметь встроенные вызовы.